Lookup for reserved LDH labels

John C Klensin klensin at jck.com
Wed Nov 7 15:42:01 CET 2012



--On Wednesday, 07 November, 2012 08:34 -0500 Andrew Sullivan
<ajs at anvilwalrusden.com> wrote:

> On Wed, Nov 07, 2012 at 02:18:37PM +0100, Marcos Sanz wrote:
>> 
>> Then it will not be difficult for somebody to point us to the
>> relevant  part in the spec that allegedly states that the
>> lookup algorithm must fail  for reserved LDH-labels that are
>> not XN-labels (e.g. "ad--acta"). I'd  really appreciate if
>> somebody did that.
> 
>    Definitions document [RFC5890].  Putative U-labels with any
> of the    following characteristics MUST be rejected prior to
> DNS lookup:
> 
>    o  Labels that are not in NFC [Unicode-UAX15].
> 
>    o  Labels containing "--" (two consecutive hyphens) in the
> third and       fourth character positions.
> 
> This is in section 5.4.  Because of the way that section is
> structured, those labels are (at the time of evaluation given
> the protocol definition) actually putative U-labels.

Andrew,

Thanks, and yes.

Marcos,

It seems to me that the hair-splitting (or protocol lawyering)
you are trying to do is productive.  IETF Standards are
voluntary.  If you can convince implementers to do things in a
way that makes domain names that contain labels with odd
prefixes accessible, the Protocol Police won't come out and
arrest either you or them.  The responses you have gotten are,
IMO, reasonably consistent about what was intended.

FWIW, if I were writing a diagnostic or testing tool, rather
than a lookup one, I'd look up all sorts of things that the
standard says to not look up, if only to make sure I could
deliver as much useful information in an error/ diagnostic
messages as possible.

Simon and Andrew,

Yes about Section 3.2.  I'm often criticized for writing too
much text and going into too much detail.  This time I obviously
could have written more, but I thought (and think) the intent
was clear, especially given other text such as the text in the
Definitions document. 

Everyone,

RFC 5890-5893 were published over two years ago.  Is there
interest in reviewing them and trying to advance them to Full
Standard (I assume that 5894 and 5895 would have to be updated
as well, but haven't studied that issue)?  Doing so would
obviously provide an opportunity to insert the sort of text that
Andrew proposes.  Speaking very personally, I would be willing
to do the work after the first of the year -- especially if
people feel that some clarifications are needed-- but only if
the discussion topic is simply about places where the specs can
be made more clear.  If people are going to take it as an
opportunity to revisit old decisions -- such as the restrictions
on what gets looked up-- then I think trying to do a revision
would cause more harm (and wasted energy) than good.

Again, just my opinion; YMMD.

  best,
    john



More information about the Idna-update mailing list