On Wed, 06 Jan 1999 10:04:15 -0800 (PST)
Ned Freed <Ned(_dot_)Freed(_at_)innosoft(_dot_)com> said...
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.
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.
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.
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. 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).
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.
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.
I suppose something like the following might be possible:
Content-Transfer-Encoding: 8bit
Content-Type: message/news; boundary="foofoo" (or should it be
multipart/news?)
Other-Email-Headers:
This is an encapsulated news article.
--foofoo
Content-Transfer-Encoding: quoted-printable (1111)
Content-Type: application/news-headers; charset=utf-8 (1111)
(or text/news-headers?)
Newsgroups: various.groups.in.some.greek.hierarchy.using.utf-8.characters
Message-ID: <12345(_at_)foo(_dot_)com> (message-ids are still strict ascii)
Path: here!there!everywhere
Subject: Some Greek text, no doubt
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-6 (or whatever the Greek iso
code
is)
Other-News-Headers:
--foofoo
Content-Transfer-Encoding: base64 (2222)
Content-Type: text/plain; charset=iso-8859-6 (2222)
The body of the article, written in greek using iso-8859-6 (whatever).
--foofoo--
An interesting idea, and certainly one that avoids obvious pitfalls. But it is
also unspeakably ugly. And an argument can certainly be makde that
application/news-headers should be a subtype of message.
Well precisely what you call the various types is a detail to be
discussed. I was aiming for something that would survive unscathed
through a system that tried to process it as multipart/mixed. And
I was hoping that the headers of the two parts could be omitted in
straighforward cases (I gather that CT defaults to text/plain, but I
cannot find where in RFC-2046 it says what CTE defaults to inside a
multipart).
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.
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