referencing IDNA2008 (and IDNA2003?)

John C Klensin klensin at jck.com
Mon Oct 25 08:33:06 CEST 2010



--On Sunday, October 24, 2010 11:36 +0900 "\"Martin J. Dürst\""
<duerst at it.aoyama.ac.jp> wrote:

> It looks like from the viewpoint of a protocol using IDNA,
> what is missing in IDNA2008 (don't know about IDNA2003) is
> that there is nothing for the 'usual' case where:
> - You want to say that you have either an NR-LDH or an U-Label
> - You want to say that you have either an NR-LDR or an A-Label
> - You want to say that you covert U-Labels to A-Labels, but
> leave NR-LDH alone
> - You want to say that you covert A-Labels to U-Labels, but
> leave NR-LDH alone

Martin,

One of the other (very deliberate) differences between IDNA2003
and IDNA2008 is that IDNA2003 appears to specify a specific
algorithm for handling IDNs while IDNA2008 specifies behavior of
the IDNA procedure itself.  For IDNA2003, I say "appears to"
because it is not clear whether implementation of the pseudocode
is required to conform.

As indicated in my note to which you are responding, an
implementation or API that took either an NR-LDH label, or a
U-label as input and returned the NR-LDH label or an A-label as
appropriate would be a perfectly conforming IDNA2008
implementation.  So would an implementation or API that accepted
an NR-LDH label, U-label, or A-label and returned the NR-LDH
label for the first case an an A-label for the other two.  

Such implementations would be appropriate for some
circumstances.  For others --including any application that
tried to be sensitive (or narrowly conforming) to the intent of
the DNS's handling of case-insensitive ASCII strings-- such an
implementation might obscure or require retesting to preserve
important information.  I don't believe there really is a
"usual" case except on an application-specific basis: the
question goes too much into implementation design and UI
considerations. 

So, while I think this might well be worth a note in any update
to RFC 5894, I don't believe anything is "missing" from the
current protocol specification.

> If and when we are going to update the IDNA2008 texts, I think
> we should carefully look at this.

Reexamination of design decisions like the one above is always
in order when documents are revised.   But we should keep in
mind that it was a design decision, not some sort of accident or
omission.

     john






More information about the Idna-update mailing list