Russ Allbery wrote:
Bruce Lilly <blilly(_at_)erols(_dot_)com> writes:
The scenario: User U wishes to crosspost to two newsgroups, one a
conventional newsgroup, and one an unmoderated extended newsgroup. For
whatever reason (e.g. the conventional group is moderated),
Moderation is not gatewaying in my document.
That was a mere example (N.B. the "e.g."). It could also be
that the user doesn't have access to an NNTP server that
permits posting to the newsgroups in question, or that the
user has access to email at the time, but not full TCP/IP
connectivity, or any of a number of reasons, i.e. "for
whatever reason".
he chooses to use the gateway to the conventional newsgroup. His UA
inserts a Newsgroup field with the two names in punycode (since it's
being mailed) and sends it to the gateway. The gateway is somehow
supposed to magically convert the punycode names to UTF-8, but no
existing gateway does so.
This isn't how most (nearly all) mail to news gateways work. Mail to news
gateways have addresses corresponding to newsgroups (whatever you want
those addresses to be) and messages sent to those addresses are posted to
those newsgroups. Some gateways go a step farther and analyze the headers
and support crossposting.
Gateways don't expect the e-mail message to have a Newsgroups header. In
fact, honoring the Newsgroups header in a mail message when processing the
message at a mail to news gateway can cause a bunch of other problems.
So you're analyzing a situation that in practice is exceedingly rare and
isn't the normal or recommended way of managing mail to news gateways,
because it causes mishandling of messages sent, e.g., by a user agent like
trn that doesn't use that meaning of Newsgroups in e-mail messages.
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. 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, and at that point the Newsgroups field is
an accurate description of the newsgroups to which the article has
been posted.
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. Anyone who wishes to pursue
punycode for newsgroup names ought to at least take a look at the work in
progress on i18n for local-parts (as announced by Paul Hoffman to many
mailing lists, including Usefor, on Feb. 6). The issue of gateway name
compatibility was missing from your table; as column 15, it should be:
15
-+---
A| I (or Y if you prefer)
B| N
C| N
D| N
13 requires (for backwards compatibility) that the article format and
the format used in IMAP be tha same, which is not the case for A.
No, it doesn't require that. The IMAP server could be modified
========
In what way is that backwards compatible with the existing (i.e.
unmodified) installed base of IMAP servers?
I don't find your personal definition of backwards compatible to be
reasonable or useful. I'm using the standard definition.
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.
Under proposal (A), if that's what you're asking, existing IMAP servers
will not work with new non-ASCII newsgroups without modification.
We're agreed on that -- "existing" and "without modification" refer
to the same thing.
That "process" is often reading directly from the spool (which under A
is in utf-8) or via NNTP (and an NNTP server has no way of determining
if its client is an IMAP server). In any event, nothing now in that
process does such a conversion, so that is a backwards compatibility
issue which rates at least a 'Y'.
Likewise for a message moved from folder to folder (on the IMAP server;
please read a description of the IMAP protocol if you don't understand
that) by a client's user.
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. *If*
and _only if_ the article format is the same as in the "mail"
format, that works. Otherwise, as in method A, it doesn't.
There is a point at which the IMAP server obtains the messages from news.
No, at least in some implementations the articles aren't "obtained",
they are exactly *the* same articles that reside in the news spool.
What "gateway"? IMAP servers get news articles from the news spool
directly, via NNTP, or via LMTP.
That's a gateway, by the standard definition of a gateway. A gateway is a
system that talks two different protocols and moves data from one protocol
to another.
Where the first method listed above is used, the articles aren't
moved, and there's no protocol involved, just files. In some
cases there *might* be a file sharing protocol such as NFS or SMB
involved, but those are not news-specific, and you'll have a
hard time convincing file system software authors to embed
Newsgroup-header-field-transforming code into such software.
If anybody still wants to pursue A, they should present a comprehensive
plan as to how it can be achieved with existing (unmodified) IMAP
servers -- a plan that is agreeable to the IMAP experts.
I don't think I'd make that strong of a requirement, but certainly one of
the things that I hoped to accomplish by posting this summary and this
discussion to the IMAP list is to make them aware of this discussion and
the possible impacts on IMAP implementations.
I still say that A is incompatible with IMAP servers that directly
access the articles in the news spool. And whatever plan ends up
in the draft is going to be reviewed as part of the last call, as
Dan has pointed out, so it's best to propose something viable in
the first place rather than to have it shot down and sent back to
be reworked.
How so -- B, C, and D all have more 'N's than A; A has more
incompatibilities ('Y' and 'I') than C or D and at least as many as B --
how can that be "least possible modifications"?
See the note at the end of the original summary about how some news
clients have been confirmed to just work with UTF-8 newsgroup names
without any modification, including displaying them correctly. This
property is unique to (A) and not shared by any other proposal that I've
seen.
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) where C and D require no modification or minimal
modification which does not entail an incompatibility (merely user
convenience).