Dear all, Why should IETF WG handle implementation issues of specific OS/GUI ? What about just let others handle them ? Is it possible to remove every application-related features out of IDNA document except IDN being ACE encoded somewhere and somehow outside of DNS ? Does it help or harm ? Regards
On Mon, Sep 02, 2002 at 06:07:23AM +0200, Simon Josefsson wrote: > "Adam M. Costello" <[EMAIL PROTECTED]> writes: > > > Simon Josefsson <[EMAIL PROTECTED]> wrote: > > > >> At least in X11 cut'n'paste works by transfering charset tagged but > >> otherwise opaque character arrays. > > > > Cut & paste in X11 works fine when everything is ASCII. Otherwise, in > > my experience, it is quite broken already, even before IDNs enter the > > picture. > > Recent versions of X11 and various utilities work better (e.g., in the > Unicode based RedHat Linux beta), but there are still applications > that doesn't work fully. Latin-1 cut'n'paste has worked for me for > years. > > >> > Even if MUTT would become IDNA-aware in the future, copy & paste > >> > operations grab the IDN-like strings directly from the xterm, not > >> > from the MUTT. So, the MUTT cannot have any opportunity to toss > >> > ACE-encod the IDN into the receiving applications or the clip board > >> > area. Text-based MUA does not have any copy&paste support to/from > >> > it. Xterm does all the job. > >> > >> The specifications seems quite clear on what should happen here -- if > >> there is no negotiation, ACE should be used. TTY MUAs therefore must > >> display ACE strings as there is no negotiation between xterm and the > >> MUA that an IDNA string is being displayed. > > > > That conclusion does not follow from the IDNA spec. ASCII forms are > > required only in IDN-unaware domain name slots. The tty is not a domain > > name slot, it's just a generic text terminal. > > > > It would be silly to forbid all tty-based applications from displaying > > non-ASCII domain names, just because cut&paste might fail sometimes. > > IDNA does not make such a prohibition. > > You are right, I trusted the simplified explanation given earlier. In > the particular example of a MUA running in XTERM (or a Unicode unix > console, for that matter), it will likely not work out as I'm not > aware of any API between a TTY application and the terminal to query > which unicode characters it can display, and whether it supports bidi, > and in that case it seems this paragraph from 6.4 would apply, > suggesting that MUAs should use ACE anyway: > > ,---- > | If an application decodes an ACE name using ToUnicode but cannot show > | all of the characters in the decoded name, such as if the name contains > | characters that the output system cannot display, the application SHOULD > | show the name in ACE format (which always includes the ACE prefix) > | instead of displaying the name with the replacement character (U+FFFD). > `---- > > Or is that section only applicable to domain-name slots? It is not > clear. > > Whether section 6.4 must be followed or not at all seems a bit unclear > after reading the following in section 6.1: "The optional use, > especially during a transition period, of ACE encodings in the user > interface is described in section 6.4.". Is section 6.4 optional? > -- /*------------------------------------------------ Ko, YangWoo : [EMAIL PROTECTED] / SPSoft ------------------------------------------------*/
