Subject: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs)

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Oct 2006 09:32:26 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> RFC 4690
>
>> URL:        http://www.rfc-editor.org/rfc/rfc4690.txt
>
> Pointer for info, it has references to RFCs 4645 and 4646.

I wonder why they chose RFC 4645 as an example of "the most recent IETF 
work in this area" instead of 4647.  We should be relieved that the 
initial LSR contents were removed from 4645.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 01 Oct 2006 22:07:10 +0200

Doug Ewell wrote:
 
> I wonder why they chose RFC 4645 as an example of "the most
> recent IETF work in this area" instead of 4647.

4647 doesn't help with IDN, 4645 is the implementation of 4646.

John reviewed 4645, he knows what's what, and Mark apparently
also contributed to 4690 (maybe Mark doesn't like it, abusing
my crystal ball).

Frank
-- 
Honk for 4234 to STD

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 1 Oct 2006 14:09:29 -0700

While very much in favor of the goals of
http://www.rfc-editor.org/rfc/rfc4690.txt, the document itself is flawed.

Some of the concerns are were voiced in
https://datatracker.ietf.org/documents/LIAISON/file304.pdf. There were some
changes in the published version, but unfortunately many new problems were
introduced at the same time. Most unsettling in my view is that there was no
process of engagement -- none of the kind of dialog such as what we have
seen in LTRU -- to get the proponents of particular positions to to present
evidence for positions and correct or refine those positions based on open
discussion of the issues.

Of course, the Unicode Standard is hardly perfect; for such are large,
complex standard, with so many issues of compatibility with previously
existing systems, that would hardly be possible. Those of us who have worked
on it and with it for so many years are well aware of that -- but also aware
of the techniques used to work around problems. But the style of the
document is not helpful, such as innuendo that certain Unicode formats or
features are not well-defined, like "...NFKC does not appear to tell
us, nor does
the definition of U+0307 appear to tell us what happens when it is
combined...". Such statements present a misleading picture to those
unfamiliar with the details of the Unicode Standard, when the standard is
very explicit about the definition and result of NFKC, and the use of
unusual characters like U+0307.

Most worrisome is that the overall conclusion seems to be providing an
excuse for IDN to stay at Unicode 3.2 ("may leave us "stuck" at Unicode 3.2"),
when the arguments for that position are based on a house of cards.

(These are my own opinions - the UTC has yet to take a position on the
document, not having met since the document was issued.)

Mark

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Oct 2006 01:59:45 +0200

Mark Davis wrote:

> https://datatracker.ietf.org/documents/LIAISON/file304.pdf. 

Yes, I read this some weeks ago when I learned that there is
now an Unicode liaison statement.  "Let's get rid of combining
characters in DNS labels" is an attractive idea, but doesn't
solve the problem of applications knowing Unicode version X
confronted with code points assigned in version Y > X.  With
nameprep they also need to know more than the combining class.

Reserving a plane for 256 future combining characters in 255
classes was my first idea, but unfortunately it doesn't help.

An algorithm to predict the relevant properties of unknown
code-points without tables would be nice (assuming they are
assigned in a later version), but probably somebody tried it
already and run out of available bits:

1: a bit for "is mixed case" 
2: a bit for "is upper case" (toggles case if bit 1 is ON)
3: a bit for "is letter or digit" (no additional hyphen)
4: a bit for "never changes under NFC after version X"

So far it could work, but adding 8 bits for combining classes
kills it.  Maybe you could limit it to say at most 16 future
combining characters per class, 16*255 starting at u+E0200 or
similar.  Dividing the other unassigned points into 16 equal
pieces is probably also no option.

That could be reduced - bit 3 OFF or bit 4 OFF are both bad
for applications trying to predict what a future version does,
With that I'd arrive at four sets:

a: stable lower case
b: stable upper case (same size as "a")
c: digit or stable caseless letter
d: forbidden in domain labels forever

> Most unsettling in my view is that there was no process of
> engagement -- none of the kind of dialog such as what we
> have seen in LTRU -- to get the proponents of particular
> positions to to present evidence for positions and correct
> or refine those positions based on open discussion of the
> issues.

For that you'd need a WG or another open mailing list.  It's
only an informational RFC, and the IAB can post their view as
informational RFC.  In that case the RFC apparently asks the
IETF to do what you want.  

Which won't help.  Unless Unicode and ICANN are willing to play
along the only possible outcome are a 3454bis, 3490bis (etc.)
using the most recent Unicode version, freezing it again.  And
with objections / appeals by disgruntled RFC 3454 implementors
I fear that we're not more talking about this decade.  Another
frozen version is arguably pointless.

> "...NFKC does not appear to tell us, nor does the definition
> of U+0307 appear to tell us what happens when it is
> combined...". Such statements present a misleading picture to
> those unfamiliar with the details of the Unicode Standard,

Well, I certainly don't know how the details of combining a
dotless i differ from combining a normal i with something else.
Apparently dotless i + diaeresis survives under NFKC (?), and
that would be not good for IDNA or SASLPREP or similar cases.

> the standard is very explicit about the definition and result
> of NFKC, and the use of unusual characters like U+0307.

In a (mostly futile) attempt to identify "irrelevant" combining
characters (= never doing anything under normalization) I got
apparently 47 cases where u+0307 does "something".  Some weeks
ago, I'm not exactly sure what I counted.

> the overall conclusion seems to be providing an excuse for
> IDN to stay at Unicode 3.2 ("may leave us "stuck" at Unicode
> 3.2"), when the arguments for that position are based on a
> house of cards.

Breaking backwards compatibility for something as important as
nameprep / salsprep needs a compelling reason, like a guarantee
that it will be never again necessary (fixing minor errors not
withstanding).  If that's impossible keeping Unicode 3.2 as is
makes sense.  There should be a better solution, if Unicode
can't provide the required predictable sets, then maybe IDNA
could roll its own and define mappings.  Limited to relevant
scripts, not stuff like Shavian / Fraktur / etc, nobody needs
that in passwords or DNS labels in the foreseeable future.

Frank
-- 
Honk for 4234 to STD

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Oct 2006 18:30:36 +0900

Hello Frank, Mark,

>nameprep they also need to know more than the combining class.

Your "thinking out loud" about how to be forward-compatible
with combining characters is an interesting intellectual
exercise, but totally unnecessary.

IDN (stringprep/nameprep) uses NFKC rather than NFC mainly
because of the fullwidth/halfwith problem for East Asian Languages.
[Being extremely often very frustrated with Japanese Web sites
that require input in exactly one of these, I understand the
idea but don't see why we needed this for DNS when it's not
used in (below) average Web sites.]

There are, as far as I know, not too many new characters with
compatibility mappings since Unicode 3.2 (Mark, any numbers?),
and those that have been added can probably be just forbidden
rather than mapped.

For NFC, the situation is even easier, except for a few errata
for purely clerical errors(*), because NFC was designed to be
stable in certain well-defined respects, and the Unicode Consortium
is very careful to make sure this stays that way.

[(*) These clerical errors have some people wonder whether the
sky will fall on our heads if they get corrected. But it's easy
to see that nobody will go ahead to register a domain name
"foo" if they get asked, in a confirmation message: Please
confirm your registration of "bar". And it's exactly such
a change from "foo" to "bar" that happens as long as some of
these clerical errors are not corrected.]

So the only thing a new version of stringprep/nameprep, based
on a newer Unicode version, would bring is a larger repertoire
of characters. What that means for DNS software is 0 (ZERO)
upgrades, because of the way IDN was designed. What it means
for registration software is some upgrades, but then registration
software is concentrated at a few points and easy to upgrade,
in particular for those registries/registrars that are interested
in providing the new codepoints. What it means for clients
(browsers and so on, or the relevant libraries) is that
maybe, some casing functions have to be extended. (But how
many new characters with case have been added after Unicode 3.2?
The prohibition on decomposable precomposed characters will
have kept these to a rather low number.) Other than that,
nothing need to upgrade clients, because according to the
IDN spec, clients are not supposed to complain about
unregistered codepoints, a provision that was carefully
designed for forwards-compatibility but now seems to have
gone mostly forgotten.

How much the authors of RFC 4690 agree with the stuff in the
document is unclear to me. A lot of it, when I read it last
time, seemed to be of the type of "let's collect all the FUD
(fear, uncertainty, doubt) out there so that nobody can
complain we didn't listen to them".

>frozen version is arguably pointless.

No. Given that the main thing that's frosen are the codepoint
restrictions, and these only apply to registrars, a new frozen
version every five years, or even more often, is not a big
problem at all.

The only problem is that last time there was an IDN WG, there
were so many requests from special interests ("language X can't
possibly exist without this special mapping"; "language Y will
be at a great disadvantage with regards to language Z unless
we introduce some special provisions in the compression scheme",
and so on) that it was very difficult to find a consensus.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Oct 2006 14:49:41 +0200

Martin Duerst wrote:

> What that means for DNS software is 0 (ZERO) upgrades,
> because of the way IDN was designed. What it means
> for registration software is some upgrades, but then
> registration software is concentrated at a few points
> and easy to upgrade
[...]
> What it means for clients (browsers and so on, or the
> relevant libraries) is that maybe, some casing functions
> have to be extended.

SASLPREP is a non-IDN case (user names + passwords), the
u+00AA case surprised me.

> "let's collect all the FUD (fear, uncertainty, doubt) out
> there so that nobody can complain we didn't listen to them".

Maybe Mark and/or you could post another informational RFC,
the dotless i example is apparently no FUD.  Taking the "R"
in RFC literally is something John might like... :-)  

Frank