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

[Mark Davis ☕]

Ken said what I was trying to say, but much more clearly and hypobolically.
Further, I agree with John about the direction that the text should take.

I have two quibbles about the current wording:

       When the algorithm presented in RFC 5892 is applied to
       Unicode 6.0 and all newly-added code points are ignored
       the results will differ from when it is applied to
       Unicode 5.2 for the three code points discussed in this
       document.

The phrasing "algorithm presented in RFC 5892 is applied to Unicode 6.0" is
a bit odd, and inconsistent with 5892. If anything, the algorithm applies to
code points, not a version of the standard. The phrasing that is used
in 5892 is "It then defines an algorithm for determining a derived property
value. 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." Thus the algorithm *determines* a
derived property value *using* a version of the Unicode standard.

Moreover, "newly-added code points" is incorrect. No version of Unicode
(except very early versions) has *added code points*. Code points are from 0
to 0x10FFFF; that hasn't changed. Instead, it has added *characters*, by
designating previously-reserved code points as representing (new)
characters.

So I'm guessing the most consistent language to use in the new document
would be:

When the algorithm presented in RFC 5892 uses Unicode 6.0, and all
characters added by Unicode 6.0 are ignored, the results will differ from
when it is used with Unicode 5.2 for the three code points discussed in
this document.


Mark

*— Il meglio è l’inimico del bene —*


On Thu, Dec 23, 2010 at 08:28, John C Klensin <klensin at jck.com> wrote:

>
>
> --On Thursday, December 23, 2010 10:30 -0500 Andrew Sullivan
> <ajs at shinkuro.com> wrote:
>
> > There seemed to be a lot of cc:s.  I trimmed them.
> >
> > On Thu, Dec 23, 2010 at 03:41:44PM +0100, J-F C. Morfin wrote:
> >
> >> 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.
> >
> > 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.
>
> Procedurally, there is one other bit of information about this.
> Assuming that the text committing the IETF to produce a new RFC
> every time a new version of Unicode is produced (see my note of
> 13 December) is removed, this document is a complete NO-OP from
> a protocol specification standpoint.  While it describes
> something that happened (a new version of Unicode) and a
> decision to do nothing, it changes nothing in any of RFCs
> 5890-5895.  I would not recommend this, but if the language of
> the document were changed slightly to indicate that Patrik and
> Paul think that these are the reasons why no change was made, we
> have well-established procedures for publishing it as an
> Informational opinion piece without any Last Call or other
> explicit sign of community consensus.
>
> In terms of protocols and tables, the difference between the
> effect   of publishing this document and the effect of just
> losing it is zero.    It provides a historical record of our
> deciding to not do something, but that is all.   Indeed, the
> main issue I see with this document is the importance of wording
> it carefully to avoid having it become, in the words of one or
> two earlier notes, "an event".  Changing the 5890-5894 rule
> requiring no action unless a change is being made to the
> compatibility tables to a rule that requires a new RFC for every
> version of Unicode would be such an event; that is why I feel
> quite strongly that we should not be making such a change.
>
> Certainly, there has been a Unicode change and that change
> causes the non-normative IANA tables that reflect the 5892 rules
> to change, but that was exactly the way that this group of
> standards were expected to work.  Not much more news, or
> requirement for broad consensus, there than is required to BGP
> documents when a new network comes online and requires
> adjustment to global routing tables.
>
> In that context, Ken's revised formulation of the Security
> Considerations section doesn't quite work although the required
> change is fairly obvious, e.g.,
>
> Ken wrote:
>
> >  When the algorithm presented in RFC 5892 is applied to
> > Unicode 6.0 the results will differ from when it is applied
> > to Unicode 5.2 for the three code points discussed in this
> > document.
>
> and we would need something like:
>
>        When the algorithm presented in RFC 5892 is applied to
>        Unicode 6.0 and all newly-added code points are ignored
>         the results will differ from when it is applied to
>        Unicode 5.2 for the three code points discussed in this
>        document.
>
> Otherwise, it is possible to read that statement as "only these
> three changes occurred", which we have discussed elsewhere and
> are trying to avoid.
>
> My personal view of the moment is that, if we cannot swiftly
> reach reasonable agreement about the content and wording of this
> document, we should just drop it.  Again, its presence or
> absence would not change anything normative.
>
>    john
>
>
> _______________________________________________
> 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/a1433e74/attachment.html>