Unicode Format for Network Interchange
draft-klensin-net-utf8-09
Yes
(Chris Newman)
No Objection
(Cullen Jennings)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 09 and is now closed.
Chris Newman Former IESG member
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
(was No Objection)
Yes
Yes
(2008-02-20)
Unknown
Last paragraph of section 1.1: "In circumstances in which there is a choice, use of Unicode and the text encoding specified here is preferred to the double-byte encoding of "extended ASCII" [RFC0698] or the assorted per-language or per-country character coding systems and SHOULD be used." I'm guessing the original intent is that the use of what's specified here SHOULD be used, but the sentence probably got mangled in editing... how about "Whenever there is a choice, Unicode SHOULD be used with the text encoding specified here. This combination is preferred to the double-byte encoding of 'extende ASCII' [RFC0698] or the assorted per-language or per-country character coding systems."
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-02-21)
Unknown
Christian Vogt's review:
This document specifies a character encoding that is to be used in new protocols. The encoding is based on Unicode.
High-level comment: I am in general skeptical about defining variant N+1 of a mechanism in order to eliminate the confusion that the N+1 existing variants may have caused. The same applies in the case of this document: It defines "Net-Unicode" to get rid of the diversity of existing Unicode encodings (UTF-8, -16, and -32).
Therefore, if Net-Unicode was to be the encoding standard of the future rather than just "yet another" Unicode variant, it should have clear advantages over existing variants. These should be explicated in the document in a prominent position.
Technical: Section 2 ("Net-Unicode Definition") is confusing with respect to which characters are allowed and which not. Many of its rules do not give clear guidance. E.g., "should be avoided", "requires care", "apply with caution", "use is questionable". Suggestion: Limit this section to clear "must's" and "must not's", and discuss caveats afterwards.
From an editorial standpoint, this document is well written and very nice to read.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown