ietf-822
[Top] [All Lists]

Re: Unicode newsgroup name options

2003-02-25 14:05:56

Bruce Lilly <blilly(_at_)erols(_dot_)com> 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 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.

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 (rra(_at_)stanford(_dot_)edu)             
<http://www.eyrie.org/~eagle/>