Russ Allbery wrote:
To take an example, if someone posts to a local Stanford newsgroup and
also cc's postmaster(_at_)stanford(_dot_)edu, 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.
I don't see the problem; if the message hits an injector first and
the gateway also tries to inject to the specified stanford.foo or
whatever newsgroup as well as the gated postmaster group, surely
the message-id will already be there and there won't be a duplicate
or other problem. And if by quirk the mailed copy hits the gateway
before the posted copy is injected, the same applies. So what's the
problem? Is the postmaster gateway mangling message-ids or something?
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.
Well I did say "desirable", and I did point out that proponents of
punycode should look at what's being done for address local-parts.
I would add that based on past history, not only is it likely that
both IDN and i22d local-parts will be standardized well before any
Usefor draft specifying newsgroup name i18n becomes an RFC, but IDN
and i22d local-parts will likely be widely *implemented* in UAs before
that happens. So some relevant support is likely to exist by the time
i22d newsgroup names become standardized, and unless the local-part
work is ignored or proves to be unsuitable for some valid reason, it
may well simply be a drop-in.
So at no point does the IMAP server call open() on a disk file? The
articles just appear magically in memory?
What are you proposing; that the OS open() call do some transformation
when called by an IMAP server but not when called by any other process?
Or that the OS somehow magically determine whether a file is "news" or
"mail" and flag that somehow (e.g. odd-numbered file-descriptor for
"news", even otherwise)? How would the OS know (bear in mind that any
disk file might be opened, including one saved to an ordinary file
by AT&T mail or BSD mailx or trn or Outlook Express (which handles
both "news" and "mail" messages and can save them to files (which
have a ".eml" suffix regardless or whether somebody thinks the message
is "news" or "mail")))? Even if that were feasible, it would still be
a backwards incompatibility.
Are you aware of IMAP servers that use the news spool storage format for
IMAP mailboxes?
Mark has addressed this issue for the UW implementation; there is
on-line documentation available for other implementations if
for some reason his affirmative response is not sufficient. Or
one could read the O'Reilly "Managing IMAP" book, though the material
is rather dated (ISBN 0-596-00012-X, or go to
http://www.oreilly.com/catalog/mimap/).
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."
I don't have a problem with defects in a proposal being pointed out,
whether it's one of my proposals or somebody else's. And in the
final analysis, the burden should be on the proponents of a scheme to
address the relevant issues in sufficient detail that others can see
that it will work compatibly. It ought not to be a case of "Here's
my half-baked scheme; tell me why it won't work", or "(waving hands)
some magic occurs here and we all live happily ever after". If that
means that a proponent has to learn about IMAP or LMTP or stringprep
or punycode or whatever, that's the price of being a proponent --
welcome to reality. Consider that the writer of "well, obviously
your solution won't work" may well be correct, and it may indeed be
obvious to somebody familiar with a relevant aspect of news -- that
means that the proponent of the scheme hasn't done his homework.
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.
The degree of pain associated with any backward incompatibiliy ('Y')
or fundamental incompatibility for any scheme seems to be such as to
preclude those schemes from serious consideration. At minimum, any
such scheme would require staged implementation, which means that
initially there would have to be a MUST NOT generate rule, and that
means no benefit for at least a couple of years. Even before that,
sufficient detail on an extension negotiation and fallback method
at various places where there are incompatibilities needs to be worked
out in sufficient detail to ensure that the scheme is feasible, and
that's likely to take a considerable amount of time. If i18n of
newsgroup name protocol elements is as urgent an issue as some think,
surely an approach that doesn't necessitate such delays is called
for, and that pretty much rules out A and B due to the 'Y's. If
a scheme has only 'N's, 'C's and 'D's, there doesn't seem to be any
reason why it cannot begin to be implemented immediately, with
corresponding benefit being available immediately to early adopters.