ietf-822
[Top] [All Lists]

Re: Restrictions on the Content-Type "message"

1999-01-07 17:50:48
I'm sorry, but this just doesn't wash. For one thing, I fail to see
the urgency -- the format for news was last updated well over a decade
ago, if memory serves. 822bis is nearly done and should be out in
another month or two. I fail to see how any sense of urgency could
exist that warrants this kind of haste after a decade of inactivity.

Well the course of action you were suggesting appeared to involve a
5-year wait to develop new protocols before the news people could even
begin to address their part of the problem. I think the USEFOR group
would rather find a solution that can be worked within the existing
constraints.

I have no idea where you got the notion 822bis was going to take 5 years to do.
The course of action that's likely to take that long, if past experience is any
indicator, is the one you're on. (In case you didn't know, more or less the
same thing, with the same claims, was tried by the SMTPEXT group. And  the
result was that the proposal eventually went down in flames, but not before
wasting three whole years of time. And the IETF was much, much smaller then,
and much faster at getting things done.)

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 you cannot do this. But I'll tell you right
now that I'll be one of the people reviewing your documents when they
make it to IETF last call, and I guarantee that I will object if these
matters aren't covered. I suspect many others will as well.

With respect, you haven't been following the discussions on the USEFOR
list. We are well aware that such additional functionality as we propose
must degrade gracefully when it meets older systems. We are also well
aware of what older systems are actually capable, and we think we
have devised acceptable solutions within the news environment.

As I said before, once you reach last call I'll be one of the people who
will review your document. And then we'll see.

When it comes to gatewaying with other environments we find some
problems, and the solution we have proposed so far is admittedly
sub-optimal. So if you people are able to point us at a better solution,
then that would clearly be welcomed.

That is precisely what I tried to do in my previous message.

Again, I said that I see no problem with using message/rfc822 for this, and 
as
yet the only objection you've managed to raise is that such usage cannot be
accomplished on your timeline. If you have a technical reason why this 
cannot
be done I'd like to hear it.

You are asking me to prove a negative, which is not always easy.

Where? I asked you for technical objections to using message/rfc822. Thus far
you haven't given any. You've only given arguments based on a timeline which
is, as far as I can tell, entirely fantastic. I see no place where I'm asking
you to prove a negative.

Are
you saying that message/rfc822 as it stands can do it? Surely not. News
headers will be liable to contain characters with the top bit set.
Message/rfc822 must follow the syntax of RFC-822 (or drums if you like)
which forbids such headers (though allowing some email headers to be
omitted).

Please reread my ealier response where I covered how to do this. Repeating:

First we finished 822bis so we have a stable, coherent specification to work
with. Then we develop a very detailed, very concrete specification for how to
do 8bit in headers along with downgrading rules. (Perhaps you have already done
this, but I cannot see how it is possible in the absence of 822bis.) 

Then we develop an SMTP extension for transmission of 8bit headers. (This is
easy and I have offered to do it.)

Then we formally extend the definition of message/rfc822 to include such
things. (This can happen independent of the SMTP extension. All it takes is a
citable specification.)

I figure all this will take six months to do if there's sufficient motivation
to actually do the work quickly. By contrast, I see no chance of your approach
producing any useful result in less than several years, assuming it ever does.

If you are suggesting some extension of message/rfc822, then please
indicate the sort of thing that might be allowed. The 8th bit could be
admitted at the stroke of a pen, and one can always put CTE: 8bit on
the outside, but that is not much help if you offer it to a transport
that does not support 8BITMIME. AIUI, such a transport could properly
re-encode the _body_ of the message and create/modify the CTE in the
inner headers, but to re-encode those headers themselves would seem to
need rather a large and incompatible extension to the existing stuff.
Please correct me if I am wrong.

I'm fairly confident you're wrong. I cannot prove it since I don't have
a concrete proposal that addresses all the issues, but I think I see how
to do it, and I see no substantive technical objections to doing it. And
perhaps more to the point, you haven't come up with any either.

So for the moment we have proposed
application/news-message - not that we like it very much.

Please understand that I'm not being obstructive about this just for the 
heck
of it. I sincerely believe that this is a dreadful idea, one that will 
cause a
huge amount of pain to the installed base,...

I agree that it is a dreadful idea, but I don't see that it will cause
pain to the installed base. It will indeed cause pain to the users of
the installed base because it will get treated like octet-stream and get
shoved off to a file, which is probably not what the user wanted.

And we have a name for this: Lack of interoperability. And we have formal
rules about interoperability.

But even supposing we moved forward with this, the question becomes: Can you
get consensus around this idea faster than 822bis can complete and the job 
can
be done right?

I would have thought so, but I would be happy to listen to arguments to
the contrary.

It should be obvious that I cannot prove to you that the course of action I
suggest is viable. The only way to test the road is to travel down it. But I
certainly can tell you that my assessment is that the course you're on is one
of the toughest imagineable, one which I suspect is doomed to failure, and even
should it succeed will take far more time than you can imagine or afford. And
to be blunt, at least part of that I can more or less guarantee.

                                Ned