Ned(_dot_)Freed(_at_)innosoft(_dot_)com (Ned Freed) wrote on 07.01.99 in
<01J69BS6QEX88ZEM56(_at_)INNOSOFT(_dot_)COM>:
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.
There's nothing new here -- these are exactly the same arguments we heard 7
years ago when we first did MIME, and I understand them all too well. The
point you don't seem to be getting is that we considered all these choices
way back when MIME was designed, and we decided that we would not allow such
requirements to be met. Let me repeat that: We would not allow it. We
understood that situations would arise where such requirements would be
given, but we decided not to cater to them. So we wrote MIME with a no
nested encodings rule, and we didn't make an exemption for tunneling or
anything else.
Well, it's true. I do have problems getting the point that people would
act that way without a good reason.
Which good reason, frankly, nobody has given yet.
You're attempting to go back on a decision that was made some time ago,
rightly or wrongly, and which implementations have gone along with in good
faith, and which has resulted in a situation where if you're allowed to
proceed along the path you've chosen the result becomes untenable.
Uh, there's a problem with your assertions there.
You seem to think that there will be implementations negatively affected
by implementing the obvious solution to the above problem.
I completely fail to see which implementations that would be. In fact,
given the nature of the problem, it seems just about impossible for such
implementations to exist.
Maybe you could explain this?
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.
The proposal - this part of it, at least - is *guaranteed* *not* to cause
interoperability problems. IMHO.
Now, we all know
that mail and news are gatewayed all the time. Messages pass from news to
mail and from mail to news, sometimes multiple times.
So what happens when a application/news-message object passes from news to
Uh, pay attention, please. The above is application/news-transmission, not
application/news-message, for which, if you recall, I said that the case
is far murkier.
mail, one which contains 8bit characters in the data, and the mail system
has to downgrade to 7bit? There are two choices:
(1) The mail system treats the object as opaque and slaps on a CTE. But then
when someone tries to read this object using a mail reader, they see an
opaque blob. The content, which likely contains perfectly reasonable
MIME objects, is unreadable.
Sounds perfectly ok to me. It's not meant to be viewed in a MUA. It's
meant to be fed to a news server. There's no good reason why a mail reader
*should* know how to interpret this. (Incidentally, this is the exact same
case as with application/batch-smtp - you can't dig down to embedded MIME
objects with that one, either.)
The result is a failure to interoperate,
one which would effectively prevent any sort of move to draft standard.
Seems extremely silly to me. "Hey, this doesn't do something that there's
no good reason to try to do." So what?
Either way you have a violation of the intent, if not the letter, of the
standards process. And this is why I'm saying that the course you're on
isn't viable.
Except I'm claiming that it certainly doesn't violate the intent, whereas
your line, to me, looks like intentionally trying to subvert the standards
process.
Think about it: what you're saying is, in effect, "you can't do a standard
that does what you need, you need to do it with non-standard means".
Doesn't that sound silly to you?
The long and short of it is that you need to give up on this idea of strict
tunneling. And once you do, a number of approaches open up that I think will
meet your real requirements without breaking things and which are viable as
standards.
Nope. Without strict tunnelling, this cannot do what it is meant to do.
The most obvious way to do this is to treat this as a gateway problem and
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.
define the operation of mail <--> news gateways to get what you want. For
That's a *far* harder nut than this MIME issue. Except if you just handle
it as a different, non-MIME way of encapsulation, in which case I must see
I see even less of a point.
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.
I disagree. I don't think you've explored all the options for moving
forward. I think that you've picked a way forward that solves one set of
problems but not a bunch of others (you've admitted your solution doesn't
handle the outermost header of a news message moving through mail), and
Huh?! That sounds like just about the opposite of what I've said. The
application/news-message thing *does* solve that problem; the message/rfc-
822 doesn't, the way I understand it.
moreover it causes lots of new problems, many of them of a sort that are
going to give you a great deal of trouble in the standards process. But
you've gotten hung up on how this one solution works and made the conditions
I find it interesting that you claim I'm hung up on a solution, just
because I take the trouble of explaining it to you. Also above you claim
I'm "just not getting" a point.
Maybe you confuse me with someone else?
of it absolute.
I think the conditions are just about absolute, and in any case, they're
older than the solution.
Oh, and you seem just as (if not far more) hung up on some absolute, and
far less justified, conditions.
I think that with a bit of compromise on your part we'll
"Hey, you forget about your necessary functionality, and I'll keep my
unreasonable demands. Now isn't that a nice compromise?"
Why doesn't that sound reasonable to me?
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.
No, I don't speak for the news community. But I still think I know what
their reaction to unreasonable opposition will be.
And I have no problems at all labelling what I see here as unreasonable.
have a way to move forward that works and which satisfies the requirements
of both communities. It likely will dump on gateways, but hey, those of us
who write gateways are used to it.
I know more about news-to-X gateways that I ever wanted to, and the best
you can do is not having them. If you do have them, correct software is
only part of any solution; it also takes correct administration, and quite
a lot of that, as well.
"Gateway", except in very precise circumstances, has become a sort of four
letter word for news people. And for good reasons.
MfG Kai