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

["Eric A. Hall" <ehall@ehsco.com>]

on 6/10/2002 7:50 PM John C Klensin said the following:

> The rephrase, much abbreviated, would be a list of RRs for which
> IDNA is applied, with the prep method used for each.  I think I
> would do that as a small table, e.g.,
> 
>    RR       IDNA yes/no    Prep method

I think we mean we're in agreement on this. I would definitely expect such
a list to be the output from the effort to classify each of the current
RRs, although such a list should not be a part of IDNA specifically, but
instead would be part of the classification effort. Yes?

> And, again, we need to be explicit that anything new, anything
> out of Class=IN, and anything not in the table, requires
> explicit standards-track action to be used with IDNA.  If you
> don't do that, we recycle in the recent interactions, in which
> people insist that "undefined" has some very specific (i.e.,
> defined) meaning for processing.

I agree with the CLASS=IN part but I'm not sure about the standards-track
requirement. Letting Apple or Microsoft or whoever make use of this stuff
without political interference from antis in the IETF seems like the best
way to make sure it gets used. I really want to give MS a reason to stop
using STD13 high-value codes and if that means they need to come up with
an NBT-A4 addressing resource record then so be it. There are other
requirements they will have to comply with such as maximum names and
stringprep compliance and that should be enough.

> You are proposing to put those declarations where?

My plan is to define the valid i18n usage of the existing RRs in the
DM-IDNS-01 spec, and to provide guidelines for the creation of new RRs
there as well (use nameprep if possible, must define stringprep profile if
otherwise, etc).

> strong opinion as to where the specification goes, as long as it
> is written down very clearly.

Does the above suit your requirements?

>>AMC and paf seem to be intimating that the IDNA labels may not
>>be reversible, which may require an additional fixup if so,
>>and if it is possible. If it isn't possible then the
>>discussion is moot. We might as well stick with STD13 labels
>>for i18n domain names at that point.
> 
> I don't think this changes that answer above, nor do I know what
> you mean by "reversible".  Certainly, to the extent to which
> nameprep discards case, information is lost in getting to those
> labels.

That's nameprep in particular, however. What I am asking about is the IDNA
encoding output, once it is separated from nameprep. The profile in use
should dictate the canonical label format, not the codec.

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