Re: Re: idn-uri document
John C Klensin <[email protected]>
| Newsgroups | gmane.ietf.idn |
|---|---|
| Message-ID | <64525620.1036502633@localhost> |
--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark <[email protected]> wrote: >> If IDNA says that their preparation of ascii-only labels is >> the identity operation, then we recommend that you apply that >> (i.e. do nothing), and not something else. If you see a way >> to make this clearer, please tell me. > > It is the identity operation for ASCII-only labels (plus some > checks that will reject certain labels). > > If you want to do that part, but not apply the Punycode step > then I think you need to explicitly state that one should > apply ToASCII without the punycode step (and other steps that > don't make sense if there are any). Erik, I tried to raise this argument in some of my remarks about IDNA, but, as with many other things, it was apparently ignored by the IESG. Let me repeat it, in a different way, in this context. One of the things that many of us feel is key to the success of the Internet protocol suite is a minimum of profiling and options for variations within a protocol. That is obviously a principle, not a hard rule: the stringprep-nameprep separation arose as the better choice relative to having different protocols make up their own mapping variations. But, even in that case, we haven't permitted profile variations _within_ IDNA: a user, site, or registry cannot select a different stringprep profile, and that is a Good, probably necessary, thing. But much the same argument applies to the type of use Martin contemplates. IDNA, as written, is _one_ protocol. It is not a toolkit for building other protocols, nor is it a a set of profiles that other protocols can adopt. Those two may be much the same thing in practice. As soon as we say "you should use that operation from IDNA, but without some particular step" we head down a slippery slope. That is especially true because IDNA contains (or appears to contain) a good deal of normative text outside the particular of, e.g., ToASCII. It is not clear whether "...explicitly state that one should apply ToASCII without the punycode step (and other steps..." includes some, all, or none of those textual specifications. And, whatever choice is made, "do just what is done over there, except..." is a poor way to do protocol specification and introduces some of the worst properties of profiling without any of the benefits of being explicit about what can, and cannot, be profiled. john