Touchstones for "Mapping"

Andrew Sullivan ajs at shinkuro.com
Fri Apr 3 03:19:13 CEST 2009


On Thu, Apr 02, 2009 at 05:03:54PM -0400, John C Klensin wrote:

> the standard and hence get second-rate treatment".   Getting
> from a U-label to an A-label is a lot more reliable than getting
> from something that is not a U-label to a U-label, but still not
> as reliable as having an A-label in the file.

Even though it was in the PS, I think the above is the really key
point: the A-label is what we have the strongest reason to believe
is a candidate for actual DNS resolution.  If we're trying to preserve
ways of finding data on the Internet, then the form that is most
likely to get any user to the hoped-for resource is what we should
recommend that people store.

That said, I completely grasp Mark Davis's points about the meaning of
"storage" and the applicability of a given storage format to the
problem domain.  (As a database geek, I have to say that I found the
examples slightly troubling -- most of them seemed to me to be
candidates for useful decomposition -- but that's a common experience
for those of us who find SQL a perfectly natural way of expressing
things.)  I similarly understand the user-interface worries many have
mentioned.

This is why I think the text ought to be along the lines of "SHOULD
store as an A-label" and "if storing Unicode strings, an application
SHOULD store the U-label."  I'd go futher, in fact.  "If an IDNA-aware
application stores raw input of a label, it MUST NOT store that input
without also storing either the (canonicalized) U-label or,
preferably, the A-label."  (Yes, yes, I know about the tendency of the
protocol police never to show up.  This is a bit of language that can
help those writing RFPs to specify completely what they want.)

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the Idna-update mailing list