On Sun, 3 Jan 1999 13:04:41 +0100
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> said...
Below is a quote from DRAFT Mime headers 0.4
by Charles Lindsey <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>, which
is being developed by the USEFOR IETF group:
6.x.5.3 Message/news obsoleted
The Content-Type "message/news", as previously registered with
IANA, is hereby obsoleted and should be withdrawn. The reason
is that, according to RFC-2045, it is expressly forbidden for
any "message" type to use a transfer-encoding other than
"7bit", "8bit" or "binary", thus preventing a news article
which makes full use of UTF-8 characters in its headers, or
which uses (as it SHOULD) "8bit" as its own transfer-encoding,
from being passed through a 7bit transport medium (recall that
it is not permitted by this document for the transfer-encoding
of a news article to be changed).
How does this conclusion influence e-mail standards?
------------------------------------------------------------------------
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
I don't think it affects e-mail standards at all, since message/rfc822
does not have this problem (at least, not with e-mail as currently
specified by DRUMS - they are going to run into this problem if/when
they decide to allow UTF-8 in headers at some future date).
IMHO RFC-2045 is too restrictive. It should have allowed each
message/type to decide this issue for itself. In fact, RFC-2045
contradicts itself for it says, in the first paragraph of 6.4:
"... If an entity is of type "multipart" the Content-Transfer-Encoding
is not permitted to have any value other than "7bit", "8bit" or
"binary". Even more severe restrictions apply to some subtypes of the
"message" type."
That seems to suggest that the restriction applies to all multipart
types (which is fine by me) but not to message types unless some
particular message-type so specifies (as message/rfc822 indeed does).
This view is confirmed by the 7th paragraph of 5.1 of RFC-2046 (as
regards multipart-types) and the 3rd paragraph of section 5.2 of
RFC-2046 which states:
"Subtypes of "message" often impose restrictions on what encodings are
allowed. These restrictions are described in conjunction with each
specific subtype."
and the followinng section of RFC-2046 then goes on to specifiy exactly
such a restriction in the case of message/rfc822. That interpretation
would suit me just fine.
HOWEVER, the 4th paragraph of section 6.4 of RFC-2045 then goes and
undoes the good work by forbidding other than "7bit", "8bit" or "binary"
with any composite media type.
This is most unfortunate, since it forbids for all time any message-type
for any kind of document which allows 8bit characters in its headers.
This is not a problem (yet) for rfc822-style email, but it will be a
problem for news articles constructed according to the new draft now in
preparation, and it will be a problem for any not-yet-thought-of kind of
internet document that might be proposed in the future.
So that is the reason why we have proposed to obsolete message/news.
On Sun, 03 Jan 1999 11:18:35 -0800 (PST)
Ned Freed <Ned(_dot_)Freed(_at_)innosoft(_dot_)com> said...
Below is a quote from DRAFT Mime headers 0.4
by Charles Lindsey <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>,
which
is being developed by the USEFOR IETF group:
6.x.5.3 Message/news obsoleted
[snipped]
Well, I certainly agree with the outcome -- message/news should never
have been registered. The intent was always for message/rfc822 to
cover News, and it does so just fine. Creating additional composite
types is a serious business owing to the need to add support in a
large number of contexts. It should never have been allowed, and would
not be today, but back in those days we didn't have an appropriately
tuned type registration mechanism in place.
No, it is too much to expect message/rfc822 to apply to news, for that
will constrain the news standards and the mail standards and the mime
standards always to keep in exact step, and the whole IETF mechanisms
are too complex to ever expect to achieve consensus across such a
wide front at any one time. Currently, the Usenet-format group, which
started its work a couple of years later than DRUMS, and which is in the
fortunate position of being able to take advantage of a software base
for news transport which is already 8bit clean, has been able to take
the plunge and build 8bit in as a mandatory requirement for transports.
Specifically, it is proposing to a allow UTF-8 in headers.
UTF-8 is currently a favoured option for future developments within
IETF, and it looks like news is going to be the first major application
to take it on board. This does, however, mean that we get to bear the
brunt of the teething problems :-(.
But the reasons given here are specious. For one thing, the use of UTF-8 in
headers is an orthogonal issue to this one. We've had a strong consensus for
years that this is a place we want to get to eventually, but we have to finish
a bunch of other stuff, most notably DRUMS, first. Only then will we have the
basis on which a design team can write a specification for UTF-8 headers that
actually works.
At which point you will undoubtedly run into this exact same problem.
And as for the CTE issue, it was decided long ago that CTEs cannot be
nested. And this is why the restrictions on message exist, and will
apply equally to any attempt to register any other composite type,
regardless of what top-level type you put it under. And this is why
CTEs on inner parts can and will be changed by software as messages,
be they from News or whereever, move from News to mail or vica versa.
Millions of lines of code have been written in good faith based on
this choice. We don't go against choices we made in the past that have
led to widespread good faith implementations. As such, any document
that says I cannot do what I've previously been specifically told I
have to do to messages because they happened to originate in News,
doesn't stand much of a chance of being standardized.
How does this conclusion influence e-mail standards?
It isn't a conclusion, it is simply a paragraph in an Internet Draft. And one
which will receive strong objection if by some chance it makes it to IETF last
call.
I don't see how you can object to the removal of a feature which you
just said should not be there in the first place. What you may not
like is the thing we propose to put in its place, which is two new
application types:
application/news-tramsmission
application/news-message
These are quite legal according to RFC-2045. The first one is no problem
(indeed it is already registered with IANA) but the second is an ugly
compromise which is bound to lead to less-than-optimal behaviour on
existing news and mail readers (until they are upgraded to recognise it
as requiring disposition-display). It would have been much easier to
have "message" recategorized as a non-composite type, but that is not
our call :-(.
Ned
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