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/
