Subject: Re: [iucg] WGLC: draft-faltstrom-5892bis-04.txt

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: 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]>

> "Jiankang Yao" <[email-masked]> writes:
>
> > Dear colleagues,
> >
> > This message starts a two-week WGLC on the draft
> > 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
>
> > Note: This draft is a document that updates an earlier RFC by stating
> > 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
> _______________________________________________
> 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).

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?

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]>

> 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]

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

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: 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.

   " 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 ?

> 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.
>

Yes, and their properties change for the same character ?

Best
S. Lancel

---

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

> 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.