I-D Action:draft-faltstrom-5892bis-01.txt

[Vint Cerf]

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 <jefsey at jefsey.com> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101223/c81e376d/attachment.html>