Ned(_dot_)Freed(_at_)innosoft(_dot_)com (Ned Freed) wrote on 06.01.99 in
<01J67U5JTO888ZE0OY(_at_)INNOSOFT(_dot_)COM>:
Not so. Within the news environment, all those questions have been
addressed, and downgrading to 7bit is not needed. Gatewaying may get a
bit complicated, but application/news-transmission (which is aimed at
machines rather than humans) gets over some of the problems. Which just
leaves the matter of a human friendly way to transmit news across email
and have is restorable to exactly the same thing at the far end.
Your implicit assumption here is that you'll be allowed to move forward with
a specification that doesn't give detailed, specific, and up to date syntax
rules and without downgrading rules. Now, I'm not in a position to say that
The way I understand it, application/news-transmission is a tunneling
protocol. As such, it's *requirements* are:
1. Upon unpacking from the tunnel, the articles in question must be bit-by-
bit *identical* to the articles that went in. That means redoing nested
encodings is Right Out[tm].
2. It being news, and news wanting no 7 bit restriction for very good
reasons (such as those being known to lead to flamewars all the time), the
mail restriction to 7 bit means that some sort of CTE is necessary here.
Now, the combination of 1 and 2 means there is no possible way to do this
without using nested encodings. OTOH, 1 also means that nested encodings
should not be a problem, since nobody is expected to *handle* nested
encodings - the mail and gateway parts only ever handle the outer
encodings, and other news software only ever sees the inner encodings.
Now, the case of application/news-message is not quite so simple. The way
I understand it, this one is actually meant (among others) for situations
where software would need to act on these nested encodings.
*However*, it still runs up against the problem that
a. News is meant to be 8 bit clean (not binary clean, though)
b. News is built around the assumption that, once a news article is
underway, most of the article headers and all of the body are safe from
change, in stark contrast to the mail case. (Typically, the exeptions are
the Path: header and the Xref: header.) There are applications around
*right* now that rely on this.
Obviously, a means that the headers of a news message, if sent by mail,
may still need to have a CTE applied. And b means that redoing CTEs is
still a problem.
So, it seems to me that we have here a case where the design goals of the
news communbity are actually incompatible with the design goals of the
MIME community, and there is no technical solution that will completely
satisfy both sides.
Note that "822 doesn't allow 8 bits in headers" is *not* the problem here;
that's just a red herring. The real problem here is that (I) people want
to transmit complex, 8 bit MIME data through an environment that has 7 bit
body restrictions, and (II) redoing MIME encodings can lead to bad
effects, something that, IIRC, has come up several times in the mail
security WGs, and in this case, this includes both body and header.
I must say that I certainly do not see a good solution here. If someone
else has a bright idea, I'm sure people will be happy to hear about it.
If all mail were 8 bit clean, this would be a non-issue. However, this is
not the case.
MfG Kai