> 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
