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

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

--On Monday, 10 June, 2002 15:27 -0500 "Eric A. Hall"
<ehall@ehsco.com> wrote:

>...
> Allowing <fooprep> FOO <barprep> isn't any different.

>> Would that meet your needs?   Is that what we are really
>> talking about?
> 
> I'm not sure I understand the suggestion. Can you rephrase it?
> I'm not sure that itemizing the RRs which IDNA can/cannot be
> used with (as is your suggestion, I think) will accomplish the
> ultimate goal, since the whole idea is to be able to use IDNA
> for any owner name which requires conversion, regardless of
> the profile used with that owner name.

Sorry, right idea (probably), wrong focus and point of
attachment.

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

where the third column could be "n/a" or some-prep.  Actually, I
presume that we would either need more columns or something like
   RR  LOC   IDNA y/n      Prep
    A  label   y          nameprep
  TXT  label   y          nameprep
  TXT  data    y          ???
  foo  label   y          fooprep
  foo  data    y          barprep
  baz  label   n           n/a

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.

Is that more clear?

> The only change that I think needs to be made is the existing
> ~"must be used with nameprep" statement be replaced with
> ~"this specification is specifically intended to be used with
> domain names which have processed through nameprep, but it may
> be used with any profile of stringprep which specifies a
> domain name". 

But I'm not sure that will be true for all time.  And pretending
that we know that, now, doesn't really buy us any marginal
future value (which I can see, at least) and invites trouble.
That said, I'm not sure the table suggested above needs to be
part of the nameprep or IDNA documents.  But I do think that
document, if separate, needs to exist, and that the IDNA and/or
nameprep docs need to normatively reference it.

> The specific usage rules for profiles and their
> IDNA interaction can be detailed in the RR-specific
> declarations.

You are proposing to put those declarations where?  Certainly we
should not claim that 1035, by some stretch of prescient magic,
specifies application of nameprep to the legacy RRs.  In case it
isn't obvious, that is really a question -- I don't have a
strong opinion as to where the specification goes, as long as it
is written down very clearly.

> 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.

     john