Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

> The delineation between transport and display data is normally clear
> within a single constrained function or service. The problems occur when
> display data is used to feed another function. The only way that we can
> reduce these risks is for the specification to take the safest, most
> conservative stance -- no default conversions -- and then let the
> authoritative bodies implement overrides when they know it will be safe,
> or where *they* are willing to risk any problems which may result from a
> looser stance. It is beyond the authority of this WG to impose these risks
> on the rest of the Internet community.

Eric,

The way I take this is that *if* we believe there is a strict line between
protocols and user-interfaces the document presents a reasonable compromise:
No implicit change to the protocols i.e. an authoriative body needs to
make an explicit decision to change the protocol, but user-interfaces
are changed so that the user sees the friendlier name.

It turns out that there isn't such a strict line - one can debate 
forever e.g. whether the output of a Unix command line tool that can be piped
to another tool is a protocol or a user interface; same for the cut&paste
buffer.

Given this blurring we have the choice between your conservative approach
and what the document says. The conservative approach assumes that there
are authoritaive bodies for all applications and their user-interfaces, which
in many (most?) cases do not exist. 
So the likely effect of the conservative approach is either that no application
user interface is converted to display non-ACE forms (because of wide-spread
concern), or that folks do it all over the place because they do not see the
concern. Neither would be a good result.

So I don't see how the document can provide any more useful advise to
developpers with user-interface issues than it does by e.g. saying:
> 3) ACE labels obtained from domain name slots SHOULD be hidden from
> users except when the use of the non-ASCII form would cause problems or
> when the ACE form is explicitly requested. 

Any more informative advise would have to try to enumerate places (such 
as cut&paste, Unix commands using stdout, etc) where implementors should think 
more carefully about this issue. But such a list would by its nature be
incomplete, and I don't see how it can say anything more than "think more 
carefully". Thus I think we need to defer to the judgement of the user
interface designers/implementers for this issue in all cases.

   Erik