mappings-01

John C Klensin klensin at jck.com
Wed Jul 8 21:08:52 CEST 2009


Shawn,

A comment or three on a small part of your note...

--On Wednesday, July 08, 2009 18:32 +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> Mapping MUST NOT be expected of a DNS server, eg: on the wire.
> That's completely inappropriate.  (On the wire being
> restricted to DNS lookup.  The body of this email shouldn't
> count even though numerous wires, and perhaps some radio waves
> were involved.)

I think we agree about this, but I note that one of the things
that makes it hard to get discussions about this exactly right
is that the DNS does case independent matching for octets that
appear to represent ASCII characters.  

> Mapping MAY happen somewhere between on the wire and the UI
> layer.
> 
> Mapping SHOULD happen at the UI layer.  Otherwise users get
> confused.  Despite what draft-protocol says, we can't
> reasonably expect to train users to enter URLs in lower case
> and Unicode Normalization Form C.

That isn't what draft-...-protocol is intended to say.  What it
is intended to say is that, by the time a string arrives at the
IDNA protocol layer, it is expected to be in a form that does
not require further mapping _and_ to be in NFC form.   If that
isn't clear, I would really welcome suggestions or at least
exact identification of the unclear text.

> Given that the "MAY"
> areas is a big gray area where we have a hard time getting
> agreement, and given that the actual mappings themselves will
> likely cause many more months of discussion even if we solve
> this issue, I think that dropping the mappings document
> unblocks the protocol document.

As a straw man (i.e., I'm not sure that I would recommend this,
but am interested in the opinions of others), we could modify
Protocol more or less as follows:

	(i) Section 5.2 ("Conversion to Unicode") and Section
	5.3 ("Character changes...") could be merged.  The
	Mapping document covers the conversion to Unicode
	question at least as well, if not better, and we really
	don't need to repeat ourselves.
	
	(ii) The combined section could pick up some of the text
	that is now in 5.3, but its main thrust would be to say
	that some mapping at the UI level will be a necessity in
	many cases, that additional mapping may be desirable in
	others, and that the issues and a possible set of
	mapping conventions appear in [Mapping].

That would preserve the general tone of Protocol 5.3, refer to
Mapping for additional details and suggestions as desired, but
avoid saying anything normative about mapping other than to
specify the "no further mapping needed or permitted, NFC"
requirement for any string being further processed by IDNA2008.

If that seems sensible, I can try to draft text and circulate it
to the list for comment before trying to generate Protocol-13.
 
> I think part of our problem is a fuzzy definition of the UI
> layer.  I think some people read that as "pressing a key" and
> others read "something that may have come from a user/human
> once apon a time, perhaps last year."

Indeed.  That gets even more confused when some of us talk about
presentation layers.

    john




More information about the Idna-update mailing list