[Top] [All Lists]

Re: Restrictions on the Content-Type "message"

1999-01-07 10:03:05
Ned(_dot_)Freed(_at_)innosoft(_dot_)com (Ned Freed)  wrote on 06.01.99 in 

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