Subject: Re: [iucg] I-D Action:draft-faltstrom-5892bis-01.txt

From: jefsey <[email-masked]>
Date: Thu, 23 Dec 2010 12:04:07 +0100

At 08:29 23/12/2010, Patrik Fältström wrote:
>Ken, thanks for this.
>Makes sense.
>What do others think?
>Patrik

I support all the comments of Ken, except "... The IETF considers it 
important that the IDNA standard remain aligned with the Unicode Standard."

This is a negation of the former WG/IDNAbis charter and RFC 5892 
which states: " It specifies a procedure, and not a table, of code 
points so that the algorithm can be used to determine code point sets 
independent of the version of Unicode that is in use".

IDNA2008 is deal with those who "design, use, and manage" the inside 
and the outside of the Internet which is to be as much stable ad the 
DNS is stable. This is for outside applications (eg. RFC 5895, 
ML-DNS, etc.) to see their submissions resolved the same whatever the 
date they were developed and deployed.

This may create difficulties. These difficulties may belong to :
- the "inside" of the Internet, the network side. They are to be 
addressed by the IAB coming IDNA work to keep them transparent to the 
external side.
- the "ouside", on the user side. They are to be addressed by the 
emerging IUse community. This community is _not_ exclusively Internet 
oriented. It needs and has started working on the preparation of an 
ISO 10646 based cross-needs International Network Character Set that 
will serve as a IUI (Intelligent Use Interface) reference. The INCS 
is based upon RFC 5892. Its plans includes visual character 
validation and IDv6 locale transcription tables.

As long as the entire IDNA architecture has not been securely 
consolidated by the IAB or by grassroots practice, no application 
developer should be proposed anything else than the RFC 5892 allowed 
code points. In any case we deny the right to non-IUse SDOs to make 
any assumption on the use of any code point. They are allowed or not 
period. There are at least two projects we know of encyption 
algorithms based on the INCS. IDNA2008 specifies the "inside" aspects 
of the protocol and leaves open the "outside" aspects. Unicode and 
IETF does not now the impact of unilateral changes of them on others 
who trust them to respect the rules. PVALID must stay unchanged.

Anyway, I have difficulties understanding how a private submission 
can be standard track and could be partly override a close dedicated 
WG standard track document set. This kind of suggested update is 
similar to the job of Michael Everson for langtags, except that the 
langtags table maintenance is described in an RFC (eventhought it is 
not respected). Maintaining RFC 5892 was never considered, no IETF 
job was ever discussed, etc. the IUse "group" would have determinedly 
opposed it.

Please, let no divide the Internet again on the Unicode issue we have 
solved. IETF RFCs and Unicode Versions are "independent" (RFC 5892).

jfc

---

From: Vint Cerf <[email-masked]>
Date: Thu, 23 Dec 2010 07:29:32 -0500

I agree with ken's suggested formulations.

As to Jefsey's position, I don't think I agree. In other words, the
codepoints defined as PVALID in RFC 5892 are derived from Unicode 5.2. The
intent of IDNABIS was to define that algorithm in such a way that the
determination of PVALID would be through the application of it to any
specific version of Unicode. Provision was made in the algorithm to preserve
backward compatibility through the reversal of algorithmic results for
specific characters whose properties might have changed between Unicode
versions.

The IETF discussions and consensus (as proposed in the instant internet
draft), adopts the position that the change in "PVALIDITY" of three
characters between the application of the algorithm to Unicode 6.0 and to
Unicode 5.2 is not of sufficient consequence to merit forcing backward
compatibility with the results obtained using Unicode 5.2.

The IDNABIS WG consensus was that changes of this kind would require RFC
level procedures to determine whether backward compatibility had to be
preserved or whether a new prefix was needed, so that is why we are
discussing this I-D.

I agree with this consensus statement (and with Ken Whistler's formulation
of the text).

vint

On Thu, Dec 23, 2010 at 6:04 AM, jefsey <[email-masked]> wrote:

> This is a negation of the former WG/IDNAbis charter and RFC 5892 which
> states: " It specifies a procedure, and not a table, of code points so that
> the algorithm can be used to determine code point sets independent of the
> version of Unicode that is in use".
>
> IDNA2008 is deal with those who "design, use, and manage" the inside and
> the outside of the Internet which is to be as much stable ad the DNS is
> stable. This is for outside applications (eg. RFC 5895, ML-DNS, etc.) to see
> their submissions resolved the same whatever the date they were developed
> and deployed.
>
> - the "inside" of the Internet, the network side. They are to be addressed
> by the IAB coming IDNA work to keep them transparent to the external side.
> - the "ouside", on the user side. They are to be addressed by the emerging
> IUse community. This community is _not_ exclusively Internet oriented. It
> needs and has started working on the preparation of an ISO 10646 based
> cross-needs International Network Character Set that will serve as a IUI
> (Intelligent Use Interface) reference. The INCS is based upon RFC 5892. Its
> plans includes visual character validation and IDv6 locale transcription
> tables.
>
> As long as the entire IDNA architecture has not been securely consolidated
> by the IAB or by grassroots practice, no application developer should be
> proposed anything else than the RFC 5892 allowed code points. In any case we
> deny the right to non-IUse SDOs to make any assumption on the use of any
> code point. They are allowed or not period. There are at least two projects
> we know of encyption algorithms based on the INCS. IDNA2008 specifies the
> "inside" aspects of the protocol and leaves open the "outside" aspects.
> Unicode and IETF does not now the impact of unilateral changes of them on
> others who trust them to respect the rules. PVALID must stay unchanged.
>
> Anyway, I have difficulties understanding how a private submission can be
> standard track and could be partly override a close dedicated WG standard
> track document set. This kind of suggested update is similar to the job of
> Michael Everson for langtags, except that the langtags table maintenance is
> described in an RFC (eventhought it is not respected). Maintaining RFC 5892
> was never considered, no IETF job was ever discussed, etc. the IUse "group"
> would have determinedly opposed it.
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: "J-F C. Morfin" <[email-masked]>
Date: Thu, 23 Dec 2010 15:41:44 +0100

At 13:29 23/12/2010, Vint Cerf wrote:
>codepoints defined as PVALID in RFC 5892 are derived from Unicode 5.2.

Vint,

I am afraid, not.

RFC 5892 only dates from the Unicode Version 5.2, like I was born on 
FDR 3rd term, that is all.

The intent was that IDNA2008 was to make IDNA independent from 
Unicode versioning.  It is only derived (through an accepted 
expertise of reference and described in ISO 10646 code points) 
from  what users of different technologies, languages, cultures, etc. 
do or want to do when it comes to directly handle the internet 
technology in using domain names , and from the way their interfaces 
(keyboards, screens, printers, etc.) support them.

>The intent of IDNABIS was to define that algorithm in such a way 
>that the determination of PVALID would be through the application of 
>it to any specific version of Unicode. Provision was made in the 
>algorithm to preserve backward compatibility through the reversal of 
>algorithmic results for specific characters whose properties might 
>have changed between Unicode versions.

Correct.

>The IETF discussions and consensus (as proposed in the instant 
>internet draft), adopts the position that the change in "PVALIDITY" 
>of three characters between the application of the algorithm to 
>Unicode 6.0 and to Unicode 5.2 is not of sufficient consequence to 
>merit forcing backward compatibility with the results obtained using 
>Unicode 5.2.

Such a discussion is worthless since it is to strictly confirm the 
essence of RFC 5892. However, introducing a new "consensus" where a 
WG+IETF consensus exists is only a way to introduce a doubt about the 
sustainability of the RFC 5892. If this Draft was accepted: this 
sustainability should be committed somewhere else.

>The IDNABIS WG consensus was that changes of this kind would require 
>RFC level procedures to determine whether backward compatibility had 
>to be preserved or whether a new prefix was needed, so that is why 
>we are discussing this I-D.

Precisely, the RFC 5892 is about the algorithm being used to create 
tables for each version of Unicode. This means that as far as the 
IETF is concerned new Unicode versions are and are to stay 
non-event.  Making them an event only gives the feeling that RFC 5892 
is actually dependent on Unicode versions.

This is why a new (if it is not a new one, why an new RFC) IDNA2008 
consensus can only be that it is important that the Unicode standard 
does not force the IETF to possibly either reconsider RFC 5892 or 
split from Unicode compatibility.  But this is implied in Unicode 
people having shared into the IDNA2008 consensus.

>I agree with this consensus statement (and with Ken Whistler's 
>formulation of the text).

Now, there cannot be any consensus statement: the WG/IDNABIS is closed.

Would this Draft be submitted to a sole IETF Last Call and not to a 
prior WG/IDNA2011 LC, I would obviously appeal it since it would only 
represent the consensus of a small group of people. This would be the 
same as if the new IUTF published a fundamental document without 
first liaising at least with ISO, ITU and IETF.

Now, should a WG/2011 be created, this could only be within the IAB 
International Program framework. As such it would respect:
" - 2.2 The position of the IAB
...
With this program the IAB intends to create a longer term effort that 
not only involves ongoing evaluation and the development of guidance 
but working with other organizations to expand both our understanding 
of the issues and theirs.
" - 2.3 Goals
Develop and provide guidance for architectural and strategic efforts 
surrounding internationalization. Generate working documents, 
organize workshops, and propose and develop relationships with other 
organizations as needed. "

IMHO, the best is to forget this I_D. this will far better 
demonstrates that RFC 5892 works and that the IDNA2008 consensus does hold.

jfc

>On Thu, Dec 23, 2010 at 6:04 AM, jefsey 
><<mailto:[email-masked]>[email-masked]> wrote:
>points so that the algorithm can be used to determine code point 
>sets independent of the version of Unicode that is in use".
>ML-DNS, etc.) to see their submissions resolved the same whatever 
>the date they were developed and deployed.
>addressed by the IAB coming IDNA work to keep them transparent to 
>the external side.
>emerging IUse community. This community is _not_ exclusively 
>Internet oriented. It needs and has started working on the 
>preparation of an ISO 10646 based cross-needs International Network 
>Character Set that will serve as a IUI (Intelligent Use Interface) 
>reference. The INCS is based upon RFC 5892. Its plans includes 
>visual character validation and IDv6 locale transcription tables.
>algorithms based on the INCS. IDNA2008 specifies the "inside" 
>aspects of the protocol and leaves open the "outside" aspects. 
>Unicode and IETF does not now the impact of unilateral changes of 
>them on others who trust them to respect the rules. PVALID must stay unchanged.
>job was ever discussed, etc. the IUse "group" would have 
>determinedly opposed it.
>
>Please, let no divide the Internet again on the Unicode issue we 
>have solved. IETF RFCs and Unicode Versions are "independent" (RFC 5892).
>jfc
>
>
>
>
><mailto:[email-masked]>[email-masked]

---

From: "J-F C. Morfin" <[email-masked]>
Date: Fri, 24 Dec 2010 02:10:32 +0100

At 16:30 23/12/2010, Andrew Sullivan wrote:
>There seemed to be a lot of cc:s.  I trimmed them.

I restored those who are concerned and not on the 
[email-masked] mailing list.

>I think you have a deep confusion about IETF procedures.  There is no
>requirement that documents from the IETF automatically came from a
>working group.  An AD-sponsored document that goes through an IETF
>last call can still represent IETF consensus.  There is no IETF
>requirement at all for a working group for this draft.

As you say: "can still represent". This is a standard track private 
submission without any AD sponsoring so far, unless I am wrong?

This is why some precautions should be considered for credibility. 
Questions might also be raised when the Chair of the formerly 
concerned WG says that there is already a consensus, if I am reading 
him correctly. I certainly can guess that there is a consensus among 
the Unicode BoD Members, Directors, senior Members and President from 
their mails on this list.

There is a non-event confirming that RFC 5892 is well written. There 
is also the use of this non-event to reopen again the_single_central_ 
architectural issue: who is to control the Internet linguistic 
architecture (and IANA user linguistic tables updates)? Is it the 
Unicode globalization or the grassroots multilingualization, or 
should they coexist. RFC 4646 and RFC 5892 already answered that.

If the target is to restart opposition between the commercially 
sponsored "inside engineers" and FLOSS lead user "outside engineers" 
solely to demonstrate RFC 3869 again, just as ICANN tries to impose 
the US international policy over gTLDs, then I have no problem with 
that. Moreover, the rationale is rather weak, since the whole thing 
boils down to three short utterances:

- "as per RFC 5892, Unicode Version 6 is an IETF non-event"
- "but who knows, perhaps RFC 5892 could have been wrong, so keep 
watching (implied: do not over trust IDNS2008)"
- "because Unicode is the Internet reference (implied not the IETF, 
nor the IUsers)".

Mind you, there is a simple way to address this: every Unicode 
President, Director, Members, and Member employee should excuse 
him/herself from this decision and clearly identify him/herself as a 
"Unicoder" in the IETF Last Call discussion, since there seems to be 
a real COI over an Internet fundamental issue for us, IUsers, which 
is (with no intended disrespect to anyone) the Internet that exists 
the day after the Google stream stops.

jfc