Bruce Lilly <[EMAIL PROTECTED]> writes: > While it might be rare (I haven't analyzed *every* gateway), it does > happen and it is an area where method A has issues that don't apply to > the other methods.
I agree with this. In the case where you have a generalized mail to news gateway that takes a Newsgroups header in the message header or body and uses it verbatim, method (A) would cause that mail to news gateway to not work correctly with any article posted or crossposted to a non-ASCII newsgroup. I think this is a pretty uncommon situation, but I suppose it could potentially arise. > And trn seems to be irrelevant in this case, since it isn't going to see > the article until after the gateway has caused it to be injected, This isn't necessarily true. When you're trying to do a lot of mail to news gatewaying, and I've set up quite a few of these for a lot of odd and interesting reasons, including many cases where the user doesn't actually know that a given address is going to a gateway, you run into messages that have been posted and mailed by agents like trn that include a Newsgroups header. To take an example, if someone posts to a local Stanford newsgroup and also cc's [EMAIL PROTECTED], that message will show up at a mail to news gateway, since we gate all mail to postmaster into a newsgroup. And that gateway can't trust the Newsgroups header in the message; it will do completely the wrong thing. Some of these are special situations that don't arise all that often, but mail to news gateways are used for a rather wide variety of applications. > Incidentally, the issue of gateways that "have addresses corresponding > to newsgroups" is another area where the canonical name being in an > ASCII-compatible form is at least highly desirable, because address > local-parts are constrained to a subset of ASCII. Not really. I mean, it would be useful to be able to use IDN or something here, but the mail address corresponding to a newsgroup can be anything you want. There's no inherent linkage. > The issue of gateway name compatibility was missing from your table; That's because I don't consider it to be a relevant issue for our current discussion. It's too trivial to work around for any specific case. > as column 15, it should be: > 15 > -+--- > A| I (or Y if you prefer) > B| N > C| N > D| N Making the mail address be the punycode version of the newsgroup name doesn't actually help the user one whit, since their mail client isn't (at least right now) going to know how to form that address anyway. It's just a bunch of letters they have to memorize, like any other randomly chosen address. So this column is Y for all proposals; in every case, if you want someone's mail client to automatically form a mail to news gateway address from a desired newsgroup name, you need support for taking the UTF-8 newsgroup name and transforming it into a mail address, which means that the mail clients would have to be modified to have punycode support. Again, though, I think this is a pretty small side issue in the overall view of things, not worth worrying about to any large degree. It's one of those things that will sort itself out one way or another no matter which strategy is picked and that gives no clear advantages to any strategy. > What I use is not a "personal definition" it *is* "the standard > definition" as used in scores of RFCs. Either a proposed modification > to a protocol would not result in illegal input to existing > infrastructure, in which case the modification is backwards compatible, > or there could be illegal input presented to that existing > infrastructure, in which case the proposed modification is not backwards > compatible. Okay, I'm sorry. I do see your point. The issue of IMAP gateways in particular are somewhat more problematic than any of the other compatibility issues posed by solution (A) since under (A) there would now be news messages flying around that were not compatible with the mail message format, and one can construct some plausible scenarios where an existing IMAP gateway would encounter those messages accidentally. >> All messages in IMAP folders, including the news ones, have mail >> syntax. I think I've said this about four times now. > You keep saying it but it doesn't work that way. Think of IMAP access to > news as an abstraction where the articles in the news spool are > presented to the user as messages in folders. Yes, and the process performing that abstraction can change formats. It's certainly not even remotely pretty to do that work at that layer, but it is entirely possible. > No, at least in some implementations the articles aren't "obtained", > they are exactly *the* same articles that reside in the news spool. So at no point does the IMAP server call open() on a disk file? The articles just appear magically in memory? Are you aware of IMAP servers that use the news spool storage format for IMAP mailboxes? I'm not, and I would have thought that would be an untenable storage format since it doesn't contain enough metadata in an indexed form to provide basic IMAP functionality without a huge speed hit. If the IMAP server doesn't use the same storage format for mailboxes and for news articles, then it is internally aware that the news messages are something different than the rest of its mailboxes. > As you have agreed, that is only *some* UAs, and others *would* require > modification for that purpose with that method (indeed it may well be > impossible for some). And that ignores all of the other areas where A > requires substantial modifications (some of which may also be > impossible) I don't believe that the contention that proposal (A) requires any impossible modifications is even remotely viable or defendable, and none of your posts have convinced me otherwise. I find this contention very frustrating, since one of the things that has poisoned this debate from the beginning has been a complete unwillingness of people on both sides to actually read, understand, and analyze the proposals of the people on the other side without preformed conclusions. As a result, we've had a ton of articles from both perspectives that *start* by saying "well, obviously your solution won't work." People are going to have to change things to get non-ASCII newsgroups to work. There's no way around this, and some point of the combined news and mail system is going to have to bear some pain. The purpose of my summary and analysis was to try to present, as well as I could, how the pain would be distributed for the different proposed solutions. After that exercise has been completed, we then move on to debating about who has to deal with the pain, which is the hard part. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
