--On Monday, 14 January, 2008 11:11 +0100 Kent Karlsson <[EMAIL PROTECTED]> 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf