On Mon, 17 Feb 2003, Charles Lindsey wrote: > I am sorry, but the IMAP list doesn't seem to accept messages from me.
You need to subscribe to the IMAP mailing list. You had better do so if you wish to continue to propose incompatible changes to IMAP in order to accomodate your proposed changes to NNTP. > But > now this discussion is in the Usefor list, I will try and keep it there. Your message had a header of "Newsgroups: local.usefor" which is unreplyable. There is no such newsgroup as "local.usefor" here at the University of Washington. Please use interoperable headers, which in the case of Usefor would be a To: or cc: address of [EMAIL PROTECTED] > >I note that there is an I-D, draft-kohn-news-article-00.txt, ... > That draft is a joke. It is so grossly incompatible with Usenet as it is > currently implemented (and not just in the matter of UTF-8), and ignores > so many issues and problems that beset the current Usenet and which Usefor > has striven to address over many years, that it cannot be considered as a > serious contender for attention. The Kohn draft is, so far, the only proposal which I have seen which can be taken seriously. If you have specific issues with the Kohn draft, please state them. Do not make sweeping generalizations. I do not see anything in the Kohn draft that is "grossly incompatible with Usenet". Nor do I know what "issues and problems that beset the current Usenet" that you are talking about. > Yes, other threads on this list are addressing features of such a header. > For example, it might contain charset and language parameters. But I am > far from convinced that downgrading within what is essentially the last > stage of the transport chain is the right place to do it. Excuse me. What you are convinced or not convinced about is not the point. You have made a proposal -- to inflict raw UTF-8 headers upon the entire messaging world -- which *requires* this in order to preserve interoperability within the entire IMAP installed base. > Regular users of > Usenet are very well aware that it differs substantially from mail. I am a regular user of Usenet. I am also an implementor of Usenet software. I consider the claim that "[Usenet] differs substantially from mail" to be complete nonsense. Usenet and mail are forms of messaging; and to the maximum extent possible should be completely compatible. Proposals which conflict with maximal compatibility should be rigorously opposed. > >IMAP does not allow untagged 8-bit data. If the mail store has such data > >as a result of compliant protocol exchanges, an IMAP server is obligated > >to do what is necessary to comply with the requirements of IMAP. > > > >Currently there is no compliant protocol exchange that would cause this to > >happen. An IMAP server today can weasel out with "garbage in, garbage > >out". > Yes, but if the garbage is clean(ish) then it is probably better to let > the client try to make sense of it that to discard it entirely. But you > don't define the protocol in those words, of course. Please re-read the first paragraph quoted here. There are clients which WILL NOT WORK if the server sends non-compliant data. The author of the IMAP server may attempt to weasel out with the GIGO argument, but if the server got such data and the client won't swallow it then it becomes the server's problem to fix it. This is a real life problem -- it *has* happened. Servers were forced to change a GIGO situation to GIVDO (garbage in, valid data out). Nevertheless, we're not talking about "garbage in" here, though. The incoming "garbage" is something that would be sanction as valid data if UTF-8 in headers is standardized. The result is "valid data in, garbage out", and it would impact *every* IMAP server implementation. The only thing worse than the notion of impacting every IMAP server implementation is the notion of impacting every IMAP client implementation. Implementors who face the prospect of VDIGO will fight vigorously to make sure that such a scenario never happens; that the GI remains GI and never becomes VDI. Your proposal is stirring a hornet's nest. Friendly advice: find other alternatives. > If you really want to provide a downgrading service if the client does not > negotiate the enxtension, then you are free to do so. But I would not > recommend that. Certainly, such a thing would be anathema in the NNTP > protocol. I don't *want* to provide a downgrading service. You propose something that, if standardized, would require me (and all other IMAP implementors) to provide a downgrading service in order to maintain interoperability with the current installed base of IMAP clients. We would have no choice in the matter. > AIUI, the "old-fashioned way" was "garbage out"? That was only when there was "garbage in". There was never "garbage out" when there was "valid data in". > >I have reason to believe that the IESG is not going to accept a document > >which designers and implementors of other protocols will object to, > >particularly when those objections are based upon the admitted existance > >of impossible mandates. > But not if the objections are based on the assumption of madates that are > not actually imposed by our draft. Unfortunately, the only way you can avoid such a mandate is by not using 8-bit headers. You can't just say that you aren't imposing it. > Yes, we may well have to reach some > compromise with the IESG, and that is likely the next business of this WG. Is Usefor going to meet at the San Francisco IETF next month? I don't see it on the agenda yet. > But before that we need to see what would be the consequences of our > present proposals, hence the interest in exploring any needed extension to > IMAP. The consequences of the proposal to transmit 8-bit UTF-8 in message headers is the creation of an unacceptable mandate on all existing IMAP servers (not to mention news to mail gateways) to convert non-compliant (8-bit) header items into RFC 2822 compliant equivalents. > >Once again, I strongly suggest that you consider the direction outlined in > >the Kohn draft. > It is not for me to consider. I am just the editor who implements what the > WG decides. So far, the WG seems singularly unimpressed with the Kohn > draft. I have not read the current Usefor document in detail. However, from what I have seen in having skimmed it, I regret to say that the current Usefor document has accumulated many fatal problems separate from the mistake of 8-bit headers. I strongly recommend that Usefor reconsider its direction, before its members find themselves having squandered a lot of their time and effort in producing something that will be rejected. The Kohn draft appears to be a step in the right direction. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
