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

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




Erik Nordmark wrote:

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

Well, a better choice is WHOIS, but I don't want to go there because of
there are current activities which murk up the issues. Finger has the same
kind of issues though.

There are domain names for input (user@domain@proxy), domain names for
output (last logged into hostname), and domain names in the protocol
message (the input and output). The default condition as specified in IDNA
is for the input and output mechanisms to perform conversion, but for the
protocol to reuse the legacy format. This is a fine and dandy solution for
this particular application, but it should be stated in a standards-track
update to the Finger spec, not by us.

> But what about nslookup, dig, the addresses logged by inetd in
> a logfile?

Whatever position we take will bleed over to these other applications.
They will look at the spec and say "SHOULD do conversion" and break
everything that depends on them. If we embraced the robustness principle,
they would look at the spec and say "MUST NOT do conversion" and they
would break nothing. To be fair, additional wording about treatment of
connection identifiers, structured data and unstructured data is probably
required if we want to be thorough.

> Having the specification mandate UI behavior seems out of place to me.

That is exactly what it does now: SHOULD transliterate anything that looks
like an ACE domain name.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/