Fwd: Evaluation: draft-yergeau-rfc2279bis - UTF-8, a transformation format of ISO 10646 to Standard

[hardie@qualcomm.com]

Hi folks,
	At the retreat, Harald sent around some proposed text
that would allow us to move the ABNF reference from the normative
to informative sections.  To refresh your memory, the issue and
his suggestion (modified by Steve) were:

OK, here's the ABNF issue.

ISSUE: ABNF, RFC 2234, is at Proposed.
The text with the ABNF grammar is added between Draft and Full, and 
thus has had no known implementation or interoperability testing. 
Thus, we can't be certain of its quality.

SUGGESTION:

1) add to the beginning of section 4:
For the convenience of implementors using ABNF, a definition of UTF-8 
characters in ABNF syntax is given here.

2) Add to the end of section 4 a NOTE:
NOTE: The authoritative definition of UTF-8 is in [UNICODE] and 
[ISO.10646]. This grammar is believed to describe the same thing as 
what those references describe, but does not claim to be 
authoritative. Implementors are strongly urged to rely on the 
authoritative documents, rather than on this ABNF.

3) Move the RFC 2234 reference from NORMATIVE to INFORMATIVE.

OK, it's working around the edge. But understanding the ABNF is *not* 
required to implement UTF-8, which is the point of the document.



	I'm okay with this resolution, and if there are others who are not,
it would be great if they could indicate why now.
	There was also the issue raised by Russ, asking that the text of the
Security considerations be updated to include a discussion of the "spoofing"
issue.  Here is proposed text for that paragraph:

When UTF-8 is used in protocol elements such as identifiers,
comparisons of two strings may be necessary in order to achieve
correct protocol processing.  Any protocol which will use UTF-8
for such protocol processing will need to specify the rules used
for comparison.  While the common case may be bitwise, octet-by-octet
comparison, it cannot be assumed; it must be specified.

	This broadens the issue slightly, in a way that eliminates
wiggle room around what is and is not an identifier.  Again,
suggested replacement text if this is not appropriate would be much
appreciated.   As an FYI, Chris Newman submitted an i-d which describes
a proposed IANA registry of comparators.  Obviously, this way too early a
piece of work to use in a full Standard, but interested folks should 
probably read:
draft-newman-i18n-comparator-00.txt.
			regards,
				Ted Hardie