Lower casing

John C Klensin klensin at jck.com
Sat Jan 29 17:39:09 CET 2011


The problem here is that there is no "transition" for those four
characters.  If browsers and other client systems provide the
IDNA2003/ TR46 mapping there are only:

	-- IDNA2003 behavior forever
	-- Rolling flag day now
	-- Rolling flag day at some indefinite point in the

By "rolling flag day" I mean that a client computer has one
behavior or the other on a given day but that not all client
systems will convert on the same day (or even in the same month
or year).

IMO, the reason why the WG was willing to make the change was
because of significant input that the ability to distinguish
between the characters that are, under UTS#46, source and
targets of mappings was important on both input and output
(remember that there is a display issue here too because an
IDNA2008 A-label that encodes the four characters is essentially
invalid under IDNA2003).  

For those groups for whom the distinction among one or more of
those character pairs (including "ignore" as the pair for the
Joiner set) actually is important, "register both" is not
meaningful: "we are applying the UTS#46 rules, including those
for 'deviation' characters" is equivalent to "you lose; we know
what your language needs better than you do".  It is telling
that all of the registries who are focused on those strings and
from whom we've received reports (other than the
somewhat-conflicting reports about Greek) have basically said
"ok, let's do it and get it over with".

There is another element of this depending on when the mapping
is applied: the "native UTF-8 in lookups outside the public DNS"
situation that is addressed in draft-iab-idn-encoding is, in
general, UTF-8 without even any normalization, much less
encoding.  By applying UTS#46 mappings, you compound the problem
of having to support two lookup encodings by having strings that
are fully-valid and accessible under IDNA2008 _and_ the internal
databases/ directories but that are not accessible from your
browser (at all for the public DNS and maybe not from the
private databases if you guess wrong about when to apply the
mapping.   That is also another way to look at the "incompetible
change" problem, which is that this is either about maintaining
compatibility with the public DNS names that were registered or
used assuming the IDNA2003 rules and restoring compatibility
with the strings that are valid and sensible in those internal
databases that you support and encourage.

As long as you understand all of those tradeoffs, you should
make whatever decisions make sense to you.   I'm glad I don't
have to make the decision.



--On Saturday, January 29, 2011 1:35 AM +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> (& I've been describing that behavior, including UTS#46
> transitional behavior and mappings, as IDNA2008 + UTS#46 to
> make it clear).
> -Shawn
> From: Shawn Steele
> Sent: Friday, January 28, 2011 5:34 PM
> To: 'Mark Davis ☕'; John C Klensin
> Cc: Simon Josefsson; idna-update at alvestrand.no
> Subject: RE: Lower casing
> It is worth mentioning that our code will follow the
> transitional guidelines, as we will otherwise break existing
> IDNA2003 users.  Presumably people who want both versions to
> work will register both versions.

More information about the Idna-update mailing list