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

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

> Clarification. I do not make any such assumption, and am fully aware that
> many Internet services do not have any authoritative bodies. But let's be
> realistic, if nobody is going to step up to modernize the service, then it
> doesn't really need fixing does it? How hard is it to write an update to
> finger and get it passed?

finger is associated with an over-the-wire procotol, so this might make sense.

But what about nslookup, dig, the addresses logged by inetd in a logfile?
I read your note as assuming that some authoritative body would make
decisions for such things as well, which might be associated with
one or more protocols, but unlike finger, isn't the embodiment of the
protocol or the main implementation of the protocol.

> On the contrary, I am clinging to the robustness principle. Be
> conservative in what you SEND. We're in heavy and deep violation of that
> principle when we say it's okay to transliterate any data that looks like
> a domain name.

The robustness principle makes sense in many places, but the IETF 
(primarely) cares about it being applied to protocols and not APIs or 
user interfaces.

I think the situation is rather analogous to the IPv6 transition.
In that space many vendors made user-interfaces (such as netstat, or
telnet printing "Trying 1.2.3.4 ...") start outputting IPv6 addresses
to the unsuspecting user.
The IETF provided no recommendations in this space.
To the extent that piping netstat output to an application which barfs on
the IPv6 addresses, this is a vendor problem and not an IETF problem.

In the IDNA space the document at least point out that implementors should
consider the effect of outputting non-ASCII at the user interface.
Having the specification mandate UI behavior seems out of place to me.

   Erik