L2/07-151

From: Doug Ewell
Date: 2007-05-09
Subject: Re: Comments on Unicode Format for Network Interchange

L2/07-126, written by Markus Scherer, proposes some changes to the 
Internet-Draft "draft-klensin-net-utf8-03", by John Klensin and Michael 
Padlipsky.  This Internet-Draft proposes to replace the venerable 
"network ASCII" standard with a tightly defined profile of UTF-8, 
including NFC normalization and CRLF line endings.

In particular, L2/07-126 proposes that the requirement to end lines of 
text with CRLF be relaxed to permit "bare CR" and "bare LF" as well. 
The document states, "We believe that single CR and LF are common 
because of implementation practice on a variety of platforms, and that 
it is both unrealistic and unnecessary to try to legislate them away."

In fact, the concept of "network ASCII," and the purpose of the present 
Internet-Draft, is to do just that: "legislate" a specific profile of 
ASCII and UTF-8, respectively, that can be expected to maximize 
interoperability.  There is indeed a large number of text files on the 
Internet that use "bare CR" or "bare LF," just as there is a large 
number of files encoded in ISO 8859-1 or other character sets, but this 
potentially troublesome diversity is exactly why a standard format is 
being proposed.

I recommend that the proposal to "legislate" the use of CRLF be retained 
in the Internet-Draft.  Furthermore, I suggest that the authors of the 
I-D withdraw their continued support in "network Unicode" for the 
obscure "CR NUL" sequence, which means "carriage return without line 
feed" and was formerly used as a hack to create overstruck sequences. 
This mechanism is completely unnecessary in a text-transport mechanism 
that supports Unicode, with its rich support for "proper" combining 
characters, and is unlikely to be handled correctly by most text engines 
in any case.

L2/07-126 also recommends that the control code HT (horizontal 
tabulation, U+0009) be permitted under Section 2.2 of the "network 
Unicode" definition.

I recommend that the control code FF (form feed, U+000C) be likewise 
permitted.  The form feed function is well known and well defined in 
almost all printing functions, and all RFCs issued in modern times use 
FF to separate pages.  It would ironic indeed for the Internet-Draft to 
retain the requirement that form feeds "SHOULD NOT be used unless 
required by exceptional circumstances" while advancing toward 
publication as an RFC, complete with form feeds!

I have no objection to the other proposals set forth in L2/07-126.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages