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

[John C Klensin <klensin@jck.com>]

--On Tuesday, 11 June, 2002 02:06 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> John C Klensin <klensin@jck.com> 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