Subject: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt

From: "Jiankang Yao" <[email-masked]>
Date: Sun, 24 Apr 2011 00:25:25 +0800

Dear colleagues,

This message starts a two-week WGLC on the draft
draft-faltstrom-5892bis-04.txt.  We did formally
adopt this I-D as a WG document a few months ago.
There has a lot of discussion and an informal last call for comments about
this draft in the IDNAbis list [email-masked].  
The editors/authors of this draft believe that this draft has been in a very good shape.

Please review the draft.  If you support publication, please state as
much on the list.  If you are opposed to publication, please state
that on the list as well.  It is more/only helpful if you give your reasons for
your position as part of your statement.  

Since this draft is the WG item of APPSAWG, we favor that the comments to this draft are sent to the list [email-masked]. 

The WGLC will end on May 08, 2011 at 23:00 UTC.

Note: This draft is a document that updates an earlier RFC by stating nothing is to be updated. 

Best regards,
Jiankang Yao(as a co-chair of APPSAWG)

---

From: JFC Morfin <[email-masked]>
Date: Sun, 24 Apr 2011 15:55:00 +0200

This draft is worded in a way I, and I suppose other IUCG Members, 
can accept. However, the need to publish it underlines that Unicode 
is not the most appropriate Internet oriented solution to support 
IDNs, the multilingual internet, and further on the Intersem 
(semiotic/semantic Internet). For example, I underlines once more 
that IDNA2008 using Unicode does not support the French (and many 
other languages) orthotypography.

jfc morfin
IUCG Facilitator

---

From: John C Klensin <[email-masked]>
Date: Sun, 24 Apr 2011 13:42:23 -0400

--On Sunday, April 24, 2011 00:25 +0800 Jiankang Yao
<[email-masked]> wrote:

> There has a lot of discussion and an informal last call for
> comments about this draft in the IDNAbis list
> [email-masked].   The editors/authors of this draft
> believe that this draft has been in a very good shape.
> 
> Please review the draft.  If you support publication, please
> state as much on the list.  If you are opposed to publication,
>...

I think it is time to approve this and move on.  To review, the
issue here was caused by some corrections of properties between
Unicode 5.2 and Unicode 6.0.  There is no debate about the
corrections being appropriate.  The question is whether it is
more important to maintain strict backward compatibility (by
making the characters exceptions in IDNA to preserve the status
given to them by the Unicode 5.2 properties) or to maintain
consistency with Unicode properties going forward.  The latter
avoids having to actually create an exception table at this
stage and avoids what many of us think of as a fork from Unicode
conformance and libraries into more separate IDNA ones.

In any event, we have been through the discussion several times,
no one is changing their minds, and just about everyone seems to
be in agreement that the odds of these particular characters
ever being an actual issue (other than as a matter of principle)
are quite low.

My main concern at this stage is that the exception procedure in
IDNA2008 assumes that there will be very few property changes
between Unicode versions and we can react fairly quickly when
they occur.   Whether the "few" criterion is being met (i.e.,
whether the implicit promises made about it) depends on one
one's point of view.  Seen as a percentage of the total number
of characters in Unicode, the number of changes is miniscule.
Seen as a cause of disruption and uncertainty, they may be more
of a problem.  And, while the IDNABIS WG anticipated that the
first few Unicode releases after IDNA2008 was adopted would take
extra time as we examined procedures and precedents, we are
certainly not managing "fairly quickly" when it takes this many
months to publish a document whose essence is "we have agreed to
do nothing".

In the short term, I think that suggests we need to approve it
now rather than wasting more time.  In the longer term, we may
need to think about more efficient ways to handle this sort of
thing.
 
   john

---

From: Barry Leiba <[email-masked]>
Date: Sun, 24 Apr 2011 17:20:33 -0400

On Sun, Apr 24, 2011 at 1:42 PM, John C Klensin <[email-masked]> wrote:
> they occur.
...
> need to think about more efficient ways to handle this sort of

I agree.

Barry, as participant

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Apr 2011 07:13:43 -0400

Dear colleagues,

> much on the list.

I have read this document.  I support its publication.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 25 Apr 2011 19:09:32 +0300

23.04.2011 19:25, Jiankang Yao wrote:
> draft-faltstrom-5892bis-04.txt. [ . . . ]
>
Making some, maybe very scanty, contribution to further existence of
this document... :-)

As a minor proposal. I think some sentences or a paragraph regarding the
IDNs and the Unicode should be added to the draft, for the convenience
of the readers, who are not deeply familiar with these topics.

I think a link to http://www.unicode.org/versions/Unicode6.0.0/ should
also go in the [Unicode6] citation.

Mykyta Yevstifeyev
> [ . . . ]
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Apr 2011 06:47:52 +0200

> also go in the [Unicode6] citation.

Please send proposed text.

   Patrik - editor

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 26 Apr 2011 20:28:40 +0300

> Please send proposed text.
Patrik,

I am not a great expert in these topics.  So, to be frank, I do not 
think I can be useful as a contributor to this draft.

Mykyta Yevstifeyev

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Apr 2011 22:28:49 +0200

"Jiankang Yao" <[email-masked]> writes:

> draft-faltstrom-5892bis-04.txt.

All,

I support publication of a document to clarify IDNA2008's relationship
to Unicode 6.0 but I believe the content of the above document causes an
instability for U+19DA which can be avoided.  From my implementer's
point of view, it seems better to add U+19DA as PVALID in the
BackwardCompatible (G) category so that we have the property that
IDNA2008-Unicode5.2(X) = IDNA2008-Unicode6.0(X) for all strings X that
were permitted by IDNA2008-Unicode5.2.

The above document effectively forbids some strings that were permitted
before.  I believe this causes a perception of instability in the
algorithm.  It seems that permitting strings with this code point would
not cause any problem in practice.  To me that is a strong argument that
good algorithmical/implementation properties are more important than any
consideration for this particular code point.  If U+19DA would cause
operational difficulties, I would be more inclined towards forbidding
strings that contains it, but I haven't seen those arguments.

This has been brought up before by others, and I have merely been
convinced by that discussion.  I'm not trying to state this point as
anything original.  In particular, here are pointers to where Mark Davis
explains the point:

http://article.gmane.org/gmane.ietf.idnabis/6910
http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html

> nothing is to be updated.

That seems wrong.  Technically the document does not claim to update any
earlier RFC according to the document content (there is no 'Updates:'
header).  Could you clarify what you mean here?  Is the intention that
the document will be marked as Updating any earlier RFC or not?

/Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Apr 2011 10:06:44 -0400

On Wed, Apr 27, 2011 at 09:28:25AM -0400, Vint Cerf wrote:
> algorithms for PVALID, etc. Does anyone know whether U+19DA has
> actually been used in any domain names?

Short of scanning the entire DNS of the entire Internet (presumably
including split-brain cases where the name is not visible in the
public tree), non-evidence of use doesn't show very much.  But it
seems a very unlikely character.

Implicit in the decision in the past about these sorts of cases was
that we'd treat them case by case.  The reason to do that was that
some (potential) incompatibilities are more serious than others.  IF
we were changing the rules around (say) the character "0", I'm quite
sure that the reaction would be different.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Apr 2011 10:58:00 -0400

[cc:s trimmed]

On Wed, Apr 27, 2011 at 04:49:18PM +0200, Stéphane Lancel wrote:

> I am sorry because I am not really expert in PVALID issues (changes, etc.),
> but I understood that PVALID once, PVALID for ever. I realize with this
> Draft that this means at character level not at codepoint level. Or am I
> wrong?

I think you're wrong in two ways.

First, it's true that the idea in IDNA2008 was that once something
would be PVALID, it would be PVALID forever.  But IDNA2008 depends on
Unicode and its properties.  If Unicode changes properties such that
something moves from PVALID to something else, then the desired state
is not achieved.

Now, one could just make a rule, "once PVALID then always PVALID."
But this is tantamount to sticking IDNA2008 to the Unicode version
that was around at the time of IDNA2008 publication.  We wanted to be
Unicode-version independent, and so that strategy doesn't meet the
goal.  

Second, I don't think "at character level not at codepoint level" is
right.  We're dealing in code points.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Wed, 27 Apr 2011 02:51:28 +0200

However I support JFC's position on the long range, I disagree that IUCG
should support the Draft until the points well made by Simon Josefsson are
addressed. Even if we can introduce a better network suited approach than
Unicode we will still have to interface the Unicode codepoints for a very
long time.
Portzamparc

2011/4/26 Simon Josefsson <[email-masked]>

> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: Stéphane Lancel <[email-masked]>
Date: Wed, 27 Apr 2011 16:49:18 +0200

This worries me: "implicit in the decision on the past". In RFC everything
MUST be explicit. (my interest lies in non registered sub-domain names used
to deliver an information to the other end).

What about the applications using hard-coded code points names, or crypted
domain names or subnames based upon an algorythm among PVALID  code points
(I understood that ".su" permitted that)..

Another point is that this Draft is precisely to show that IDNA2008 is
stable. Simon and Andrew show that this may not be the case, even when IETF
says it is? How could the IDNS be stable if it uses a non-stable element
(Unicode) ?

2011/4/27 Andrew Sullivan <[email-masked]>

---

From: Vint Cerf <[email-masked]>
Date: Wed, 27 Apr 2011 09:28:25 -0400

Simon,

point taken - the other side of the equation is to try to get the
UNICODE property values to produce stable results using the IDNA2008
algorithms for PVALID, etc. Does anyone know whether U+19DA has
actually been used in any domain names?

v

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Apr 2011 12:05:48 -0400

On Wed, Apr 27, 2011 at 05:56:15PM +0200, Stéphane Lancel wrote:
>    " But IDNA2008 depends on Unicode and its properties.  If Unicode changes
> properties such that something moves from PVALID to something else",
> 
> is that not a change in Unicode, i.e. a new version ?

It is.  That's what the issue is in this case: there's a new Unicode
version, and a code point's properties changed from one version to
another, such that the derived category in IDNA2008 changes from
PVALID to something else.  Have you read the draft?  This is called
out quite explicitly in section 1.

> Yes, and their properties change for the same character ?

Please don't bring characters into this.  We are talking about code
points, and we don't need to muddy the waters.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stéphane Lancel <[email-masked]>
Date: Wed, 27 Apr 2011 17:56:15 +0200

> I think you're wrong in two ways.

No problem. I try to understand.

> We wanted to be Unicode-version independent, and so that strategy doesn't
> meet the goal.
>

Here I am lost.

> Second, I don't think "at character level not at codepoint level" is right.
>  We're dealing in code points.
>

Best
S. Lancel

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Apr 2011 19:35:52 +0200

(I'm limiting the cc list to just idna-update and apps-discuss.)

> Draft that this means at character level not at codepoint level. Or am I

The "PVALID once PVALID forever" invariant will not be true if this
draft is approved.  However I'm not saying that should be an absolute
axiom.  There could be cases where we want to disallow some strings that
used to be permitted because they cause significant problems (for
similar reasons some code points are disallowed today).  I would prefer
case-by-case decisions.  What I'm not seeing here is an explanation why
this code point is so problematic that we must disallow it.  The code
point doesn't even seem to be used in IDNs.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Apr 2011 14:58:08 -0400

--On Wednesday, April 27, 2011 10:06 -0400 Andrew Sullivan
<[email-masked]> wrote:

>...
> Implicit in the decision in the past about these sorts of
> cases was that we'd treat them case by case.  The reason to do
> that was that some (potential) incompatibilities are more
> serious than others.

We have been over this before, but there is another reason that
keeps getting lost when someone says "it is incompatible".
There really isn't ever going to be a choice between
"incompatibility" and "no incompatibility".   It is a tradeoff
between two different choices of incompatibility:

	* We preserve the earlier interpretation of a character.
	That requires compensating for a change in Unicode
	properties by putting the character into a table of
	exceptions (a table that we have not yet actually had to
	create and start putting entries into).
	
	* We preserve the alignment between IDNA2008 and
	evolving-version Unicode properties by letting the
	character's interpretation change if its Unicode
	properties are changed.  That is the "do nothing" option
	as far as IDNA2008 (and RFC 5892 in particular) are
	concerned -- IDNA2008's rules and tables are unchanged,
	but the character status changes.

That distinction is important because the underlying design
model for IDNA2008 is that it is a specification of rules about
property values (with exceptions as absolutely needed), not a
table of characters and their interpretations (the latter was
the model with Stringprep and Nameprep).  While I assume that
others may understand things differently than I do, that implies
to me that the "normal" (and stable) action for new versions of
Unicode is simply to run the existing rules against the
Unicode-updated character and property list.  If Unicode decides
that a property was sufficiently in error that they should
reclassify the character despite whatever disruptions that would
have (to our work or that of anyone else), then the IETF/IDNA
default, IMO, should be that we don't second-guess that choice
or its importance, _especially_ in an environment in which,
however many labels appear in the DNS today for a previously
PVALID character (or that might have appeared if the character
were previously DISALLOWED), there will be more on the future,
just because of the growth in registrations.

Remember too that the WG's decision (which I hope we don't need
to reopen) was that, all things being equal, a change from
DISALLOWED to PVALID is no less problematic than a change from
PVALID to DISALLOWED.  That is at least partially because, if
someone wants to register a label that would naturally include a
DISALLOWED character, people will make compromises and register
whatever they consider as similar as possible.    If the
character is later reclassified to PVALID, while there is no
issue with a label becoming invalid, we end up with the same
problem we are now facing with Sharp S, Final Sigma, and the
previously "mapped to nothing" joiner characters (and had some
years ago with the introduction of decorated Latin characters):
there is no way to know whether previous registrations were
intended as compromises with what was possible or were intended
to be in that form, creating a need for either special
registration models (e.g., sunrise reservations), alias
registrations in some form, or both.

The reality is that any change in properties and therefore IDNA
classification of a code point between versions of Unicode is
going to be disruptive.  I think we need to assume (and hope)
that Unicode will not make such changes unless they are really
necessary and justified and will exert appropriate caution in
adding characters to make the odds of needing to reclassify them
very low. But, if they do make such a change and we continue to
believe in the "Unicode version independent" model of IDNA2008,
our default, IMO, needs to be "follow Unicode" in the absence of
strong and material evidence that the change would be unusually
and unacceptably disruptive to IDNA.  Otherwise, it seems to me
that we lose that model and, instead, replace the IDNA2003 model
of "Unicode 3.2 forever" with one that uses rolling snapshots of
Unicode based on each version's property lists, i.e., that we
effectively hold properties immutable that the Unicode
Consortium, in its wisdom, feels free to change.

IF we were changing the rules around
> (say) the character "0", I'm quite sure that the reaction
> would be different.

Indeed.

    john

---

From: "J-F C. Morfin" <[email-masked]>
Date: Wed, 27 Apr 2011 23:43:02 +0200

At 20:58 27/04/2011, John C Klensin wrote:
>That is at least partially because, if someone wants to register a 
>label that would naturally include a DISALLOWED character, people 
>will make compromises and register whatever they  consider as 
>similar as possible.

John,

this is what, I believe, makes Stephane differentiating characters 
and code points.

Characters are what people consider. Code points and their properties 
what Unicode considers. Characters exist before Unicode code points. 
Unicode changes at this stage are to better match characters. The way 
people have used code points to support a character may be the same 
or different from the way Unicode will do it in its new version: this 
is something a registry can easily address through a policy statement 
and in validating domain names using the new Unicode approach to 
replace the people compromise.

Also, remember that if IDNA2008 is Unicode-version independent, it 
means that it is necessarily UCS system independent. I consider that 
Unicode is inappropriate to network semiotics support but that 
IDNA2008 does a good job to support Unicode and pave the way for new 
kind of supports.

This means that U-labels and A-labels may go for ever, but N-labels 
(from an UCS network oriented system?) could be introduced and 
supported [that internally may very well use ISO 10646 tables or 
not]. At this stage, IDNA2008, on the machine side uses Unicode which 
is a computer oriented (hence code point) system, while people use 
signs (i.e. when scripting, characters). The whole issue is to make 
them better and better correspond. However, IMHO we are reaching the 
limits of the Unicode kind of typographic oriented system (ex. lack 
of French majuscules support, but also logos, gestures, sounds, 
thoughts, etc. new signs for new kind of communication system. etc.)

jfc