<html>
<body>
At 13:29 23/12/2010, Vint Cerf wrote:<br>
<blockquote type=cite class=cite cite="">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. </blockquote><br>
Vint, <br><br>
I am afraid, not. <br><br>
RFC 5892 only dates from the Unicode Version 5.2, like I was born on FDR
3rd term, that is all. <br><br>
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.<br><br>
<blockquote type=cite class=cite cite="">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.
</blockquote><br>
Correct.<br><br>
<blockquote type=cite class=cite cite="">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.</blockquote><br>
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.<br><br>
<blockquote type=cite class=cite cite="">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.</blockquote><br>
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. <br><br>
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.<br><br>
<blockquote type=cite class=cite cite="">I agree with this consensus
statement (and with Ken Whistler's formulation of the
text).</blockquote><br>
Now, there cannot be any consensus statement: the WG/IDNABIS is closed.
<br><br>
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. <br><br>
Now, should a WG/2011 be created, this could only be within the IAB
International Program framework. As such it would respect: <br>
" - 2.2 The position of the IAB <br>
...<br>
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. <br>
" - 2.3 Goals <br>
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. "<br><br>
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.<br><br>
jfc<br><br>
<br><br>
<blockquote type=cite class=cite cite="">On Thu, Dec 23, 2010 at 6:04 AM,
jefsey <<a href="mailto:jefsey@jefsey.com">jefsey@jefsey.com</a>>
wrote:
<dl>
<dd>At 08:29 23/12/2010, Patrik Fältström wrote:
<dl>
<dd>Ken, thanks for this.
<dd>Makes sense.
<dd>What do others think?
<dd>Patrik<br>
<br><br>
</dl>
<dd>I support all the comments of Ken, except "... The IETF
considers it important that the IDNA standard remain aligned with the
Unicode Standard."<br>
<dd>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".<br>
<dd>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.<br>
<dd>This may create difficulties. These difficulties may belong to :
<dd>- 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.
<dd>- 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.<br>
<dd>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.<br>
<dd>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.<br><br>
<dd>Please, let no divide the Internet again on the Unicode issue we have
solved. IETF RFCs and Unicode Versions are "independent" (RFC
5892).<br>
<dd>jfc<br>
<br>
<br>
<br>
<br>
<dd>_______________________________________________
<dd>Idna-update mailing list
<dd><a href="mailto:Idna-update@alvestrand.no">
Idna-update@alvestrand.no</a>
<dd>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a><br><br>
</dl><br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>