In <[EMAIL PROTECTED]> Mark Crispin <[EMAIL PROTECTED]> writes:
>Please do not communicate with me privately on this matter without >cc'ing the IMAP and usenet-format mailing lists. Your statements about >what I purportedly said were forwarded to me. I am sorry, but the IMAP list doesn't seem to accept messages from me. But now this discussion is in the Usefor list, I will try and keep it there. >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. >On Fri, 14 Feb 2003, Charles Lindsey wrote: >> Well if you are suggesting a new header along the lines of >> This-Message-Contains-8bit-Headers: [yes/no] >> (syntax left stupid because such a header might contain lots of other >> goodies as well) then I might well be persuaded. Particularly so if it >> could lead to some way of bringing UTF-8 into Email messages as well >> (though that might be a longer prospect). >This is a start. But the tag needs to be specifically UTF-8, not 8-bit, >and the means of downgrading to a 7-bit environment must be clearly >specified. 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. However, this is on the Usefor list now, so other opinions need to be heard. >So, you are expecting that all implementors of all other messaging >protocols do UTF-8 validity checks on untagged 8-bit data, and do what? if >it fails the validity check. No, I am not expecting that. Any non-UTF-8 material will not be Usefor compliant (not according to present plans, anyway) so there is no obligation on implementors to do that check. Nevertheless, some may do so if their users lean on them hard enough, but the check is better performed in the user agent, because only the user is in a position so say how he would like untagged, non-compliant, non-utf-8 material treated. >And what happens when there is a mistake? Some small piece of otherwise >valid UTF-8 was corrupted and flunks the validity check. Or there's a >false positive? The current estimate is that, considering Subject headers, the false positive rate will be of the order of 1:100,000. Which is not a bad recovery rate for data that was non-compliant in the first place. >IMAP is messaging, and the sooner that people stop thinking about "news" >and "mail" and start thinking about "messaging", the better. Well, others on this list have answered that point. Regular users of Usenet are very well aware that it differs substantially from mail. >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. >You are proposing to introduce such an exchange. You recognize that this >impacts IMAP, hence your discussions for an extension, but you have not >broached the issue of complete interoperability and compliance with and >without the extension. 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. >> So I think you are asking for a new command >> of the form "Please do/do not send me these new-fangled things". Or, >> putting it more politely, an ENABLE8BIT command. Is that correct? >In effect. The new command is "you may send me these new-fangled things". >In the absence of the client negotiating such a command, the server MUST >do what is necessary to comply with the old-fashioned way. AIUI, the "old-fashioned way" was "garbage out"? >Red herring. 8-bit headers are prohibited in SMTP. Then why do they keep coming :-( ? >They should be prohibited in NNTP for the same reason. The Kohn draft >solves the problem without using 8-bit headers. >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. Yes, we may well have to reach some compromise with the IESG, and that is likely the next business of this WG. 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. >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. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: [EMAIL PROTECTED] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ------ This is a Cc: of an article on USENET sent to you for your convenience. ------
