However, looking at the precedents established in the case of HTTP, I see
the use of phraseology such as "MIME-like" and "different use of Internet
Media Types than is typically found in Internet mail". More specifically,
I see that the media type text/plain is different in that naked CR and LF
are allowed, and even line endings that are totally different in the event
that multi-byte charsets are used. And, again, in their usage of
multipart/mixed they allow the use of HTTP headers as body part headers,
with no suggestion that headers not of the form "Content-*" might get
discarded en route.
And naturally they warn that precautions are necessary if ever the HTTP
object is to be moved into a pure (Email) MIME environment, which is
exactly the same as I am proposing to do with Netnews.
There were several reasons for allowing this in HTTP: (1) Text media types were
already widely deployed in HTTP with different semantics than in email at the
time this was added to the HTTP standard, (2) HTTP and email are sufficiently
disjoint applications that incompatibilities in their interpretation of media
types are unlikely to cross over, and (3) To the extent there was crossover
gateways and converters were aware from the get-go of the need to convert
between the two.
None of these considerations apply to use of message/rfc822 in news: (1) You
yourself have argued that MIME elements aren't deployed in the context of
netnews, (2) Cases abound where material passes back and forth between netnews
and email, (3) Existing gateways aren't going to know what to do and therefore
will not handle this well if at all.
But even if the cases were comparable, this barely squeaked by in HTTP at the
time. And knowing what we know now about this stuff, many people, myself
included, now believe it was a mistake to have allowed this. So if we had it to
do over again I very much doubt it would be allowed.
8. Insofar as MIME introduces the use of headers within the bodies of
articles/messages, it is only to be expected that within Netnews the
general conventions regarding Netnews headers should apply to them. Again,
any resulting messiness is to be confined to the gateways.
And that's fine. Just don't reuse an existing media type in the process.
OK, so you have no problem with
Content-Disposition: attachment; filename="?-?-?-?"
where "?-?-?-?" is a placeholder for some filename in Hungarian, Arabic or
Chinese. Just so long as that usage is confined to Netnews, and is not
seen in Email except in the corresponding RFC 2231 form?
I assume the ?-?-?-? is intended to represent a utf-8 string. If so, then
of course I have a problem with this. It is a different problem than
the one with message/rfc822 usage, but a problem nevertheless.
And, naturally, that usage will be seem in the body part headers of a
multipart/mixed (again within Netnews, not Email)? For that is precisely
where you would expect "attachments" to be found.
So I am allowed to reuse the existing media type multipart/mixed.
But not message/rfc822?
Sigh. I again repeat: You can use any media type in any way you want as long as
you do not change its definition. What you cannot do is redefine it. Media
types are supposed to define content independent of transport. If I have
a handler for message/rfc822 objects I should be able to call it from a
any sort of application that deals with media types and it should be able
to work.
This completely transcends the issue of gateways and their ability to convert
between netnews and email.
9. In fact, there are only two places where MIME in Netnews will differ
from MIME in Email. One is in allowing full UTF-8 within quoted-strings
within parameters in the Content-* headers (and probably in comments
within those headers too). The other is in "message/rfc822". Both these
cases therefore require attention by gateways.
It seems you are accepting the first difference, but not the second?
I never said anything of the sort. I accept neither but for different reasons.
Ned