Re: 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" <[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
------------------------------------------------*/