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

[John C Klensin]

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