Mappings

John C Klensin klensin at jck.com
Sat Jul 18 18:38:30 CEST 2009



--On Friday, July 17, 2009 10:10 +1000 Chris Wright
<chris at ausregistry.com.au> wrote:

> Shawn,
> 
> Exactly, the rules say the registry doesn't do mapping, but
> someone has to map somewhere, and they need to know what
> everyone else will do when they map, otherwise how will they
> know what to map and to what?

Chris,

The "to what" is absolutely unambiguous.  If you think
otherwise, please point out the relevant text and, if possible,
suggest changes.  The idea is that the registrant needs to
understand what she is getting registered, and what she is
getting is the U-label (or, if you prefer IDNA2003 terminology,
the string recovered by applying ToUnicode to what is actually
stored in the DNS). 

Now, what goes on between the registrar and the user to identify
the relevant U-label is, well, between the registrar and the
user.  My personal recommendation is that registrars stay as
close to expecting U-labels from users as possible, but I expect
that "as possible" would include NFC mapping and possibly width
mapping in cases where the width form that is PVALID is hard to
type.   But, if a registrar wants to accept something that
requires either the mappings of the mapping document, or NFKC,
or something else, that is fine as long as the would-be
registrant is presented with the U-label and asked to verify
that is what is being asked for before anything goes off to the
registry.   The documents don't say more about this because it
raises issues of registrant interfaces and business
relationships that are far out of the WG's scope... and on which
registrars ought to be able to compete if the relevant
registrar-registry agreements permit that (more business
relationships).   

Again, if the documents aren't clear, please make suggestions.
But I think, from your notes and maybe Shawn's, that you may be
confused about one bit of intent: the "real" label is the
canonicalized form, i.e., what IDNA2008 refers to as a U-label
or its A-label equivalent.  Either of those can be obtained from
the other by a transformation that does not lose _any_
information.  That is pretty important and, if I've correctly
understood what the WG has said several times, we have agreement
on it.  It also isn't much different from IDNA2003 except for
terminology and clarity: only the A-label can be stored in a
zone (under either version) and applying ToUnicode to a valid
A-label yields what is now called a U-label.   

The registry requirement of the IDNA2008 spec is that you put
only A-labels into zones (nothing new) and that you "register"
only U-labels or A-labels (which, with adjusted terminology, is
exactly how some registries read IDNA2003).  The change is only
the explicit expectation that you not accept something that
requires mapping for registration without performing the mapping
and and verifying it with the registrar or registrant.  Whether
you require registrars to provide you only with U-labels,
A-labels, or pairs of them is another business matter. I know
what advice I'd give in order to head off complex error and race
conditions, but it isn't something this WG thinks it can or
should reasonably standardize.

Conversely, if a registrar or registrant decides to submit only
U-labels and A-labels, there is no issue about mapping (or much
of anything else unless you are also applying variant
processing, which is also outside the WG's scope).

    john




More information about the Idna-update mailing list