Re: Comments on draft-klensin-net-utf8-06

["Frank Ellermann" <[e-mail]>]

John C Klensin wrote:

>> * Section 4: "the string order of RFC 3629". It's not very
>> clear to me  what is meant with this. Byte order? Sorting
>> order?
 
> 3629 specifies a byte order (in section 4).  It does not address
> or mention sort order except to note (in the introduction) that
> UTF-8 preserves it and that sort order based on code point
> sequence is likely to be fairly useless.
 
> I _think_ I would welcome text to clarify this

Please simplify the remark and remove one "that":

-| Were Unicode to be changed in a way that violated these
-| assumptions, i.e., that either invalidated the string order
-| of RFC 3629 or that that changed the stability of NFC as
-| stated above, this specification would not apply.

+| Were Unicode to be changed in a way that violated these
+| assumptions, i.e., that changed the stability of NFC as
+| stated above, this specification would not apply.

UTF-8 as specified in STD 63 is stable.  

> So I am loathe to cover things that are well-covered in 
> 3629 lest more confusion be created.

Yes, just don't mention the "byte-value lexicographic sorting
order of UTF-8 strings", it's covered in STD 63, and besides
not very interesting.

>> * Section 4: I would drop the last paragraph, since it is a
>> repetition of  what is exhaustively explained in section 5.2.
>> I got a parsing error at  the last sentence of that paragraph
>> anyway.

Indeed, that paragraph is unnecessary.  I also can't parse its
first sentence.

> That last sentence could be restated, less formally, as:
 
> If one encounters a UTF-8 string in a protocol, and its
> syntax and properties are not specifically defined, then
> it is reasonable to assume that it conforms to this
> specification.

I still don't understand this.  What is an UTF-8 string with
"unspecified syntax" ?  STD 63 specifies the syntax of UTF-8,
anything not following this syntax is invalid.

The net-utf8 I-D doesn't specify any default properties, what
is an assumption that "unspecified properties" conform to
net-utf8 supposed to do ?  

If you're talking about unassigned code points please say so.
In that case it's covered in 5.2, and you can simply delete
the last paragraph of section 4.

> I'm going to hold the document for a few days before 
> re-posting in the hope of getting comments from others.

Please update the [NFC] reference, s/March 2005/2006-10-12/
for the version belonging to TUS 5.0.

 Frank