[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Re: Document Status?



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" <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?
>

--
Time to apologize, president Bush
--
/*------------------------------------------------
  Ko, YangWoo / a human / yw@mrko.pe.kr
------------------------------------------------*/