[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Re: Document Status?
"Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord> writes:
> Simon Josefsson <jas@extundo.com> 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?