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/
