Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05

[John C Klensin <[e-mail]>]

--On Monday, October 08, 2007 3:19 PM +0100 "Clive D.W. Feather" 
<[e-mail]> wrote:

> John C Klensin said:
>>
>> New versions of these documents have been posted for your
>> reading pleasure, reflecting comments and discussions on this
>> list (and some private correspondence about editorial issues)
>> today.
>
> unicode-escapes section 7 has a spurious closing double quote.

Will check on this.

> Appendix A.1., comment after "BMP-form", what does "the one
> above" refer to?

Probably the result of pulling that text out to a separate 
section.  Will check.

> Nitpick: some slashes in the definition of HEXDIG have a space
> before them and some don't. You've also got two spaces after
> some = and three after others.

If the RFC Editor thinks this is important, I'm sure they will 
fix it.

> You don't have an A.3 for Java.

Because there was no specific syntax in the last draft that had 
the syntax in line.

Re the FF and CR discussions: please understand that, if one 
were able to erase the entire history of text on the network and 
start over today, one might reasonably do something different. 
Or one might not.  But, because this whole business is intended 
for untagged text, making incompatible changes in interpretation 
of strings is just not, IMO, a plausible option.  CR was 
discussed more intensely in the net-utf8 draft because it is 
discussed more intensely in the NVT / Net-ASCII documents.  Bare 
LF was discussed less because it wasn't considered much of an 
issue and because the negative effects of interpreting it 
differently than the sender intended were much less severe 
(e.g., one-line vertical indexing versus NewLine) than the 
consequences of getting the interpretation of bare CR wrong 
(NewLine versus overstriking).  Anyone who has

 seen a terminal
                or other display
                                 render bare-LF
                                                text like this

versus having lines overstuck or, worse, rewritten multiple 
times with each one being quickly erased, should understand this 
immediately.  The LF case is readable, if annoying, and the 
source of the problem is almost immediately clear.  The CR case 
obscures text: on a fast enough device, or on a system that 
canonicalizes before transmitting, one ends up looking only at 
the last line of a paragraph and has to guess what might have 
happened.

I could try to incorporate a little more text along those lines 
in the document, but please remember that it has already been 
criticized for containing too much history and explanation 
rather than just laying out the rules.

General comment on these two documents.  In both cases, I 
started them because it appeared that they would be useful to 
the community.  I am not strongly committed to them and my 
patience for nitpicking has just reached zero.  So, I will 
generate -06 drafts if they are really needed, but that is it: 
if the community, or selected individuals, want the quest for 
perfection to drive out the opportunity to have something useful 
(but probably imperfect), this is your opportunity.  Or, if 
there is someone who has more patience and time than I do who 
would like to take over and polish them to a high luster, please 
let me know.

      john