--On Monday, 14 January, 2008 11:11 +0100 Kent Karlsson
<kent(_dot_)karlsson14(_at_)comhem(_dot_)se> wrote:
...
I think this document is at least one draft, maybe two or three
drafts, away from being of sufficient clarity and of sufficient
quality to become a standards document. In addition you state
that you don't have time right now to deal with this. I would
therefore suggest that the document be withdrawn from last
call, to allow time for clearing up the document.
Kent,
I think we have a difference of opinion here that has been
fairly well summarized in your exchanges with Frank. Let me
try to identify the difference in a different way by examining
three possible cases:
(1) We have a collection of protocols in the IETF that
use text in lines and data transmission models that are
both very simple and very dependent on a clear and
precise definition of "line". That definition has
traditionally involved a CRLF sequence and that alone.
(2) We have other protocols (and are likely to have more
in the future) that use other definitions of text,
usually, but not always, involving some form of markup
or highly structured data. HTML and XML are just two of
those.
(3) At least in principle, we could have something
intermediate -- no markup in the XML sense, but
significant use of contemporary Unicode characters and
directives that become more or less specific about
breaks and non-breaks, "soft" and "hard" line-endings,
paragraph endings, and, as I had explained to me
recently, the distinction between spaces and tabs in
Unicode's "bidi" algorithm.
Now the net-utf8 work is targeted exclusively at the first case.
Even more specifically, it has been clear since the request to
get this written up and standardized came out of an Applications
Area meeting a few years ago that it would need be designed so
that all of the sensible and plausible uses of "NVT" would be
valid for it, without changes. Based on the discussions on the
Apps Area discussion list over the last 18 months or so and the
comments on the IETF list since the Last Call started, I believe
that, modulo some tuning and clarifications, it is largely done.
From reading your last three notes, it appears to me that you
would prefer the third protocol definition instead. While I
find it interesting that the IETF has apparently not needed
anything like that so far (at least not that I've noticed), I
think creating such a definition would be a perfectly reasonable
activity. But it doesn't seem to me that it is reasonable for
you to say that the net-utf8 document should be withdrawn from
Last Call and run through multiple additional drafts because it
doesn't solve the (rather different) problem you would like to
solve in the way in which you would like to solve it.
Like Ned Freed and probably you and others, I would like to
think that, if we were doing our character stream and line
definitions today, with all of Unicode and its various
formatting and layout characters in front of us, we would make
some decisions differently from the decisions made in the first
half of the 1970s (when I assume some readers of this note were
very, very young). If we need that third protocol, then that
may be the place to make different decisions. But, because of
those old decisions and a huge installed base the reflects them,
there are constraints on what can be done with net-utf8. The
current specification reflects those constraints (or at least I
think it does). Most of the suggestions you are making do not.
Assuming that the third protocol were written, we could then
look forward to many interesting arguments as to whether it, or
net-utf8, or something else entirely, should be specified for
use in a particular protocol or situation. But that argument,
it seems to me, would be worthwhile. Trying to insist that
net-utf8 be turned into something else entirely is not, IMO.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf