I am now on the ietf-822(_at_)imc(_dot_)org list, so no need to send separate
Cc:s to
me now.
In <78S7FYw1w-B(_at_)khms(_dot_)westfalen(_dot_)de>
kaih(_at_)khms(_dot_)westfalen(_dot_)de (Kai Henningsen) writes:
Ned(_dot_)Freed(_at_)innosoft(_dot_)com (Ned Freed) wrote on 07.01.99 in
<01J69BS6QEX88ZEM56(_at_)INNOSOFT(_dot_)COM>:
I see that Ned has now agreed that he was shooting at the wrong target
here, so I will just comment on a few details and clarifications.
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].
Yes, absolutely so. It is meant now to be processed by news software only.
If that software finds some inner CTE that it wants to expand, then so be
it. Note that the stage at which a CTE is undone can be important if there
is a digital signature involved. Checking it on the wrong side of the CTE
will make it fail.
... So we wrote MIME with a no
nested encodings rule, and we didn't make an exemption for tunneling or
anything else.
No. There is no nested encoding in multipart or message types, but you can
do what you like in applications types (it is the application that gets to
sort out the mess).
But there is a formal rule that things have to interoperate. You cannot
proceed down the standards track in the presence of interoperability
problems and you cannot even get on the track if it can be shown that your
proposal is guaranteed to cause interoperability problems.
Actually, since RFC 1036 was never a standard, the formal rule may not
strictly apply. Not that we wish to avoid that problem, of course.
Everything that has been proposed in USEFOR has had its impact on existing
implementations carefully considered. We have drawn a clear distinction
between news readers (or which there are millions worldwide, with umpteen
different implementations) and news servers (which are fewer in number and
use a rather small number of different implementations). Clearly, current
newsreaders will be around a long time yet, and so must be failsafe as
regards new funtionality. OTOH, it is much easier to lean on servers that
are behind the times, and to flood around them if they remain so (news has
never been a 100% lossless medium :-( ).
Gateways are a problem. If you transfer through a news->mail and a
mail->news gateway, what you get is corrupted news and people shouting at
you to shut down that gateway.
Yes, gateways are a problem and gateways are difficult. And maybe even
more difficult than they were before :-( . And yes, they are always going
to get shouted at.
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.
Yes. Son-of-1036 made this argument strongly, and the USEFOR drafts make
it even more strongly. If you cannot handle an article for some reason,
then it is better to drop it on the floor than to try and transmit it in
munged form.
I think I can predict something here. If nobody comes up with a better
solution (and I don't think your ideas about gateways would even count as
half as good), and the IETF/IESG decide to make a problem out of this,
then the news community will probably decide that, since they've gone so
long without an IETF/IESG-blessed standard, they can do the same in the
future; they'll just make their own standards, just the same as they've
done all the time.
Yes, that could indeed happen. But the intention and hope is to do it
right if it can be done.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5