Re: I-D ACTION:draft-ietf-idn-idna-08.txt
John C Klensin <[email protected]>
| Newsgroups | gmane.ietf.idn |
|---|---|
| Message-ID | <13564057.1023751610@localhost> |
--On Tuesday, 11 June, 2002 02:06 +0000 "Adam M. Costello" <[email protected]> wrote: > John C Klensin <[email protected]> wrote: > >> Instead, what is needed is one very clear paragraph in the >> IDNA document (I think). That paragraph should say that IDNA >> is to be used (with nameprep, etc.) for the representation of >>... > But IDNA has to work with more than just DNS, it has to work > with the wide variety of other protocols that carry domain > names. By logical extension, your proposed paragraph needs to > list every field/argument of every protocol/interface where > IDNA may/should-not/must-not be used. > > Isn't that too much trouble (or even impossible)? Isn't it > simpler to design IDNA so that it can safely be used for any > (textual) domain label anywhere? That was our intention. In that instance (see other note(s)), the section should be put in another document, and the IDNA one should say something a bit closer to: This protocol is an isolated piece of work that only coincidentally has anything to do with domain names. Its use with the DNS, or elsewhere, requires that a standards-track specification be written and approved by the IESG that specifies that it may be used with that other protocol and specifies the profile of stringprep to be used with it. Now, that is further than I think it is useful to actually go (in addition to making IDNA outside the charter of the IDN WG), but maybe it illustrates the point. I think you can't have it both ways. Either this is a DNS protocol, in which case it needs to specify applicable RRs and fields and may reasonably specify a <foo>prep profile --even if it can also be used for names (domain and otherwise) in other contexts-- or it is a generic internationalization protocol, in which case applicability to the DNS and domain names needs to be specified somewhere else. It seems to me that there are huge advantages to the latter. However, if we adopt that approach, we haven't completed any work on domain name internationalization until that other document is written and moved through the system. john