Subject: Re: [idn] IDN rechartering rev 3

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 2 Nov 2001 14:16:35 +0800

> > Could you provide a schedule for changes so that those of us who are
> still
> > working on alternatives per your last guidance on this subject know
> what
> > our timeframe is?
>
> As long as it takes to reach clear consensus but no more.

s/clear/rough/

> Personally, I am looking somewhere in the next 2 week.
>
> -James Seng
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Nov 2001 16:08:59 -0800

There has been no further discussion about the revised charter, for more 
than one week.  That suggests that it is time to adopt it and send it to 
the IESG.

d/

> > Personally, I am looking somewhere in the next 2 week.

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: David Hopwood <[email-masked]>
Date: Tue, 13 Nov 2001 00:32:08 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> Goal & Milestone:
> Nov 2001        domain name identifiers normalization draft last call

This is completely unrealistic. There are many unresolved issues concerning
normalisation.

Here is one of them: the current nameprep draft doesn't always produce
identical results for two canonically equivalent names.

For example, "\u1F70\u0345" and "\u1FB2\u0300" are canonically
equivalent strings representing 'alpha with varia and ypogegrammeni'.
However:

  NFKC(fold("\u1F70\u0345")) = "\u1F70\u03B9" (alpha-varia, iota)
  NFKC(fold("\u1FB2\u0300")) = "\u1F70\u1F76" (alpha, iota-varia)

This could be fixed by using the "simple" versions of case foldings for
characters that include ypogegrammeni or prosgegrammeni, and removing
the folding for U+0345. (It isn't actually important to consider
ypogegrammeni to be equivalent to iota, but uniform treatment of
canonically equivalent strings is definitely important.)

Other issues relating to normalisation are:
 - whether to use NFKC or NFC
 - what set of characters to disallow (the current spec arguably
   allows too much)
 - treatment of Hangul compatibility Jamo
 - the point raised by Kent Karlsson about Jamo clusters
 - the definition of "stored" and "request" strings in stringprep

I frankly don't see how normalisation can be finalised without knowing
which protocol proposal will be used, or why it's necessary to finalise
it before then.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Nov 2001 20:23:06 -0800

>This is completely unrealistic. There are many unresolved issues concerning

         As someone who knows how to develop Internet standards, but knows 
nothing at all about character sets, languages or character normalization, 
I will offer a reaction (and eager solicit comments from the relevant 
document authors):

         What you have listed appears to be and interesting list. Some of 
the items do look like they need to be resolved.  Others appear to be 
important topics that do NOT need to be resolved *by this groups* or *at 
this time*.

         To the extent that items need to be resolved, then the discussions 

>  - what set of characters to disallow (the current spec arguably

         definitely needs to be done.  anyone not agreeing with the 
contents of the current drafts should specify alternate tables.

>  - the definition of "stored" and "request" strings in stringprep

         ok.  please offer definitions.

d/

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 13 Nov 2001 23:32:55 +0800

> canonically equivalent strings is definitely important.)

Nameprep dont "fixed" NFKC. That is not the intention.
Nameprep reference NFKC and use it as-is.

If there is a problem with NFKC, then we have to fix it at UTC, not
here.

>  - the definition of "stored" and "request" strings in stringprep

Most of the these issues have been addressed in the report by Nameprep
team in San Diego. Those that we didnt (such as Jamo), see the above.

> which protocol proposal will be used, or why it's necessary to
finalise

Actually they are independent. Whether the solution is IDNA or not,
UTF-8 or ACE, we always need a normalization process. While we always
related Nameprep to IDNA or ACE, there is nothing in Nameprep which
enforces ACE or IDNA.

-James Seng

---

From: David Hopwood <[email-masked]>
Date: Tue, 13 Nov 2001 22:38:26 +0000

-----BEGIN PGP SIGNED MESSAGE-----

James Seng/Personal wrote:
> David Hopwood wrote:
> > This could be fixed by using the "simple" versions of case foldings
> > for characters that include ypogegrammeni or prosgegrammeni, and
> > removing the folding for U+0345. (It isn't actually important to
> > consider ypogegrammeni to be equivalent to iota, but uniform treatment
> > of canonically equivalent strings is definitely important.)
> 

This has nothing to do with "fixing" NFKC. The problem is a result of
using the "full" case foldings for characters that include ypogegrammeni
or prosgegrammeni, before doing normalisation, when those foldings only
work as intended for already-normalised strings.

The solution I proposed above avoids the problem, and has no significant
disadvantages in the context of IDN. It is a straightforward change to
the nameprep folding table, that stays within the current model of a
stringprep profile. I'm certainly not suggesting redesigning NFC or NFKC.

> If there is a problem with NFKC, then we have to fix it at UTC, not

This is specifically a problem with how case folding is used in nameprep.
Not fixing it would arguably mean that nameprep is nonconformant to the
Unicode Standard (conformance clause C9).

> team in San Diego.

Am I reading the same document:
<http://www.i-d-n.net/ietf49/idn-sandiego-nameprep-design-team-report.ppt>?

The only one of these issues that is even mentioned in the report is the
set of disallowed characters (and it is not discussed in any detail).

> Those that we didn't (such as Jamo), see the above.

The issue about Jamo clusters would benefit from input from the unicode
mailing list, but it is this WG that will have to decide what, if anything,
to do about it. It *may* turn out that it is not a significant problem (for
example if input methods can be relied on to produce Jamo sequences with
clusters as single characters, or if sequences not in that form would be
sufficiently rare). It certainly should not simply be dismissed without
any discussion, though.

> > which protocol proposal will be used, or why it's necessary to
> > finalise it before then.
> 
> UTF-8 or ACE, we always need a normalization process.

Yes, we do, but certain details of normalisation do interact with the
choice of proposal. In particular, the definition of the contexts in
which unassigned characters are allowed does, and that is currently
specified in stringprep.

> While we always related Nameprep to IDNA or ACE, there is nothing in
> Nameprep which enforces ACE or IDNA.

I didn't say that there was.

- --

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 14 Nov 2001 14:10:01 +0800

> stringprep profile. I'm certainly not suggesting redesigning NFC or
NFKC.

In this case, I suggest you follow up with the Nameprep Design team. I
have cc: them above.

> Am I reading the same document:
<http://www.i-d-n.net/ietf49/idn-sandiego-nameprep-design-team-report.pp
t>?

Yes, the note is brief. But the presentation is much more in detail.

Anyway, I am probably interested in one point. :-)

> This is completely unrealistic. There are many unresolved issues
concerning

What would you counter propose to make this realistic?

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Nov 2001 11:54:20 +0800

> than one week.  That suggests that it is time to adopt it and send it
to

Adjusted Nameprep milestone in response to David's suggestion. If there
is no further comments, this will be forward to the ADs.

-James Seng

---
Domain Names are Internet identifiers. They are used both for
machine and human processing, so the form of a Domain Name must
be convenient for both processing venues.  The current set of valid
Domain Name characters is limited to common Internet ASCII, which
is inadequate for the broad range of human Internet users.  This
working group will produce a standards-track specification for
extending the range of characters that can be used in Domain Names,
by humans. The enhancement will be designed to minimize changes to
existing Domain Name software and operations. In particular, changes
to the DNS infrastructure of storage and exchange mechanisms will
be avoided.

The technical approach for the current specification effort shall be to
permit use of international character, as recommended by the IAB, and
then encode the characters, to permit their transmission and storage
within existing DNS mechanisms.  Hence this enhancement to the DNS
involves only end-user software.  In particular software that needs to
be changed is restricted to:  DNS client.  No other modules will need
to be changed.

Language information is not encoded in these identifiers.  That is,
"names" from different languages are defined in a single namespace.

The WG will rely on, and reference, work from established efforts to
internationalize digital characters, such as, Unicode Consortium and
ISO/IEC.  Discussion of new codepoints, codepoint properties and
mappings between codepoints is appropriate for these other venues,
and is out of scope of this working group.

The group will not address the question of what, if any, body should
administer or control usage of names that use this functionality.

The group will identify consequences to the current deployed DNS
infrastructure, the protocols and the applications as well as transition
scenarios, where applicable.

The working group will actively ensure communication with interested
groups who are studying the same, or related, topics.

The Action Item(s) for the Working Group are:

1.  An Informational RFC specifying the requirements for providing
International character sets in domain names. The document should
provide guidance for developing solutions to this problem, taking
localized (e.g. writing order) and related operational issues into
consideration.

2.  A standard track specification on permitting international
characters
in domain names, including specifying any transition issues.

3.  A standard track specification on an ASCII Compatible Encoding
(ACE),
to be used in the standard track specification on permitting
international
characters in domain names.

4.  A standard track specification on normalization of domain name
identifiers for the purpose of string comparisons. This document may
include case folding, map outs, and prohibited characters.

Goal & Milestone:

Dec 2001        ACE specification send to IESG for advancement

Dec 2001        domain name identifiers normalization draft last call
Jan 2002        domain name identifiers normalization draft send to IESG
                for advancement

Nov 2001        Draft of architecture relating input methods, namepreps
                and zonefiles
Dec 2001        Second draft of architecture draft
Feb 2002        Architecture draft last call
Mar 2002        Architecture draft send to IESG for advancement

Dec 2001        IDN Protocol draft wg last call
Jan 2002        IDN Protocol draft send to IESG for advancement

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 18 Nov 2001 23:22:26 -0600

> to the DNS infrastructure of storage and exchange mechanisms will

This is mutually exclusive. What you are describing above (and below) is
an encoding, not a domain name syntax. To be even more precise, it is a
hostname decoding which will result in a UCS label sequence.

Also note that this decoding will require changes to some parts of the
infrastructure in order for it to be a successful encoding, probably at
the authoritative servers for a zone and possibly at the resolver
depending on depth of adoption. I somehow doubt very much that the
advocates of this document seriously mean to preclude themselves from
consideration, so a less politically expeditious but more technically
astute approach may be warranted.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Nov 2001 13:29:49 +0800

Please suggest alternative wordings. Thanks.

-James Seng

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 18 Nov 2001 23:39:32 -0600

> Please suggest alternative wordings. Thanks.

I have yet to hear a good reason for changing the current charter, as
provided at http://www.ietf.org/html.charters/idn-charter.html. As such,
my alternative would be to leave the current charter alone.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Nov 2001 21:37:46 -0800

At 11:22 PM 11/18/2001 -0600, Eric A. Hall wrote:
>This is mutually exclusive.

What, exactly, is mutually exclusive?

>What you are describing above (and below) is
>an encoding, not a domain name syntax.

OK.

>  To be even more precise, it is a

OK.

>depending on depth of adoption.

The only changes need to be up the stack, towards user interactions.  That 
means the DNS client and the DNS Administration interfaces that creates DNS 
entries.  No other part of the system needs to change.

>  I somehow doubt very much that the

Preclude ourselves from consideration???  What DO you mean?

I have no intention of acting as a translator of iDNS strings.  I'm pretty 
sure James also does not.

d/

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Nov 2001 14:01:45 +0800

There are many good reasons:

1. it is clear our action items have missing items. some of the
   action items are outdated and no longer relevant to the group.

2. the clarification of many technical information we now know
   which we dont 2 years ago.

3. we started with an "explorative" charter to look for a solution.
   time to refocus the group to actually produce a solution.

   (unless of course we want the group to continue this never
   ending quest to find the perfect solution).

4. goal & milestone is outdated too.

So I do not agree with your assessment of no "good reasons for changing
the current charter". Leaving it alone is not an option.

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Nov 2001 22:35:25 -0800

At 02:01 PM 11/19/2001 +0800, James Seng/Personal wrote:
>we started with an "explorative" charter to look for a solution.

the best argument for needing a new charter is how long this working group 
has existed and it still has participants who are unclear about the actual 
focus of work.  the new charter clarifies this issue.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 01:03:13 -0600

Dave Crocker wrote:
> the best argument for needing a new charter is how long this working
> group has existed and it still has participants who are unclear about
> the actual focus of work.

Exactly. I can think of no better example than those who would put
political expedience above analysis of the ramifications.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 02:00:49 -0600

Dave Crocker wrote:

> >Also note that this decoding will require changes to some parts of
> >the infrastructure in order for it to be a successful encoding,
> >probably at the authoritative servers for a zone and possibly at the
> >resolver depending on depth of adoption.
> 
> The only changes need to be up the stack, towards user interactions.

> That means the DNS client and the DNS Administration interfaces that
> creates DNS entries.  No other part of the system needs to change.

This is patently false.

Under the current spec, hostile redirects are trivially easy. To use your
favorite phrase, the proposal is "incomplete" without guidance and at
least a recommendation on these and other critical issues. At best, it
will require application involvement, which is substantially more effort
than simple display decoding. The depth to which application interfaces go
in this and other efforts will also affect whether or not resolvers need
to be changed.

It was illustrated last week that answer data cannot be properly encoded
in all cases. There are only a couple of ways to solve this problem, one
of which is ensuring that all of the authoritative servers for a zone
follow the same default recommendation. New servers.

Quite simply, if IDNA only served the principle goal for which it was
designed -- backwards compatibility with hostnames as transferred in
application data -- then it would work without any other changes. Because
it goes beyond this scope into display decodes and zone data, it is by
definition no longer serving the single goal for which it was designed,
and it inherits the problems associated with those turfs.

Your failing to notice these problems doesn't mean they do not exist.

You have made it clear that you despise basic science, but it should be
equally clear that it is far too early to be annointing anything the
winner in this process. Doing so can serve no purpose which is beneficial
to this WG or the Internet community.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 02:11:35 -0600

>    which we dont 2 years ago.

I would suggest that an update to the charter (as opposed to an outright
rechartering) be limited to those issues.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Nov 2001 00:20:02 -0800

At 02:00 AM 11/19/2001 -0600, Eric A. Hall wrote:
>Under the current spec, hostile redirects are trivially easy.

In what way does the translation/encapsulation approach of an ACE alter the 
current fundamentals of DNS security.  It is odd that your assessment of 
the security risk is not shared by others who have worked with the DNS for 
a long time.

In particular, how does the proposal ADD the security risk you describe?

(By the way, there are a number of other questions still awaiting your 
answer from an earlier message of today.  Please do find the time to 
respond to them.)

>You have made it clear that you despise basic science

Actually I mostly despise ad hominems during a technical exchange, though 
it is easy to appreciate the temptation.

>but it should be equally clear that it is far too early to be annointing 
>anything the winner in this process

Perhaps you have experience with other standards work that drags on for 
many years, but is still successful.  Alas, that is not the track record in 
the IETF (or ISO or ITU).  No doubt it would be fascinating to hear 
recitation of such successes.

Some other time, however.  This topic has been hashed, re-hashed, and 
otherwise made a hash of, by these sorts of exchanges.  After two years, 
detailed specifications are in short supply.  In fact, there is only one 
with enough detail to consider completing soon.  It is thorough, has 
minimal operational impact, satisfies the functional requirements, and has 
substantial consensus.

And, by the way, it is entirely acceptable that you disagree.  That's why 
we call IETF consensus "rough".  (The word also covers that ad hominems.)

d/

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Nov 2001 16:56:37 +0800

When I say "rechartering", I actually mean "update to the charter". If
"rechartering" somehow mislead you to think we are changing our goal,
then I apologise for the confusion.

Our goal have not change. Nor have our general intention. But a lot more
clarification was done in the new revised charter.

-James Seng

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 08:53:29 -0600

Dave Crocker wrote:

> In what way does the translation/encapsulation approach of an ACE alter
> the current fundamentals of DNS security.

I am referring to DECODES and the enthusiastic display of a charset with
combining characters without consideration of the results. There is more
to the current proposal than just encapsulation.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Nov 2001 07:35:20 -0800

At 08:53 AM 11/19/2001 -0600, Eric A. Hall wrote:
>combining characters without consideration of the results.

The string that you so mistrust comes from the DNS.  Hence the security 
question is whether strings from the DNS can be trusted.

DNSSec solves that concern.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 09:56:32 -0600

> >I am referring to DECODES and the enthusiastic display of a charset
> >with combining characters without consideration of the results.
> 

Only in some usage scenarios. For protocol and application data which
contains sequences that are decoded for display, this is not true, yet
those encodings must be validated (as legitimate sequences, not as having
legitimate sources which is the DNS problem) before they are trusted.
DNSSEC does nothing to prevent a transliterated URL from pointing to a
site which is different from the displayed domain name.

Unfortunately the scope of this work is such that it cannot be handled by
this WG. In short, the only way that this problem can be adequately
addressed is to reject transliteration for any data that is not lookup
oriented, and to defer tranliteration of protocol or application data
(include mail headers, URLs, everything that is NOT lookup oriented) to
the governing documents where they can be managed as appropriate to their
context. EG, URLs MUST NOT be decoded for display until the URL spec
defines valid characters and sequences, the proper disposition of invalid
sequences, etc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Nov 2001 08:14:33 -0800

At 09:56 AM 11/19/2001 -0600, Eric A. Hall wrote:
>those encodings must be validated

You are confusing an administrative issue with a protocol specification issue.

>this WG.

Excellent!  Thank you for acknowledging that your concern is outside of the 
scope of this working group.

>  In short, the only way that this problem can be adequately
>oriented

I recognize all of the words you used, but have no idea what you mean.

>, and to defer tranliteration of protocol or application data
>context.

This working group is concerned with domain names, not mail headers or 
anything else.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 10:23:56 -0600

> This working group is concerned with domain names, not mail headers or

Have you even read the spec you whip for?

draft-ietf-idn-idna-04.txt:

| 3. Requirements
| 
| IDNA conformance means adherence of the following three rules:
...
| 2) ACE labels SHOULD be hidden from users whenever possible. Therefore,
| before a host name is displayed to a user or is output into a context
| likely to be viewed by users, the ToUnicode operation (see section 4)
| SHOULD be applied to each label. When requirements 1 and 2 both apply,
| requirement 1 takes precedence.

That *requirement* is at polar odds with your statements.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 12:08:03 -0600

> In particular software that needs to

As illustrated, such a specification would preclude all of the current
proposals before this WG. The only way that any current proposals would
conform to such a requirement would be to completely emasculate them so
that they only provided guidance on the precise task of encoding and
decoding label data, but left all such usages (including display and zone
management) to other documents from other WGs.