draft-klensin-net-utf8-06

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

Ok, this document just went into the queue and should appear
momentarily (probably before this message goes up).  It is
clearly less ready than the unicode-escapes one, partially
because of the addition of a lot of new or revised text, but I
hope we are converging: I will probably not have time to
generate another draft --except possibly for _very_ minor
changes-- prior to at least the middle of next month.

I've tried to deal with the comments from Frank, Stephane,
Clive, a few offlist comments, and the very extensive analysis
from Martin.  The comments that follow address some suggested
changes that I did not make plus a few things that seem to
deserve comments.

(1) We obviously have a tension between those who like the
history, context, and explanations and those who don't.  Oddly,
at least one person who asked for less then turned around and
complained that one decision wasn't explained.   Given people on
both sides, I've tried to strike a balance, but it clearly
reflects my/our editorial preferences.

(2) There are many ways in which the document could be more or
less radically reorganized.  Some might make it better.  Barring
really compelling arguments, we aren't going to do it: the move
of some material to appendices already fouled up some references
(I hope this iteration fixes all of them) and the payoff just
doesn't seem worth the additional time and iterations.

(3) This document affects protocols, which the unicode-escapes
one almost exclusively affects documentation and how the IETF
talks about things.  I have consequently tagged this one as
destined for Proposed Standard and the other one as BCP.  If you
disagree, this is probably the time to speak up.

(4) I've tried to clarify the text in several places, but I'm
not sure I got one bit adequately.  For CR, the rule is
   MUST NOT appear bare (i.e., MUST be followed by LF or NUL)
   SHOULD NOT appear with NUL
I believe that is consistent.

(5) I've added some words about both HT and FF.  One may need to
look in the appendices to find all of them.

(6) I've eliminated references to IDNA entirely, substituting
one to Stringprep where that appeared necessary.  

(7) The document is now linked to Unicode 5.0, with previous
versions, notably 3.2, referenced only non-normatively in
discussion.   I hope the revision was done correctly; please
tell me if it was not.  Moving to 5.0 eliminates any possible
need to go into detail about NFC changes after 3.2 but not the
need to caution against the risk of similar changes in the
future.

(8) While a few people advocated it, I can't see making the NFC
requirement a MUST.  First, there are certainly reasonable cases
in which it is not appropriate.  Second, if NFC on sending is a
MUST, then receivers have the right to expect that they will see
only NFC-normalized forms on input.  That assumption is
dangerous, since, in general, there is no way to know whether a
sender is following this spec.  I hope the text is now
consistent with that position.

best,
     john