From: Bruce Lilly (blilly@erols.com)
Date: Wed Sep 18 2002 - 20:38:52 CDT
Charles Lindsey wrote:
> It will be impossible for a successor to 2822 to provide for MIME-style
> parameters, because of backwards compatibility.
If true, then it is impossible for the Usefor draft to introduce
them because of backward compatibility with RFC 1036.
>>>>No, SMTP provides no guarantee of 8-bit transport....
>>>
>
> It provides guaranteed 8-bit transport within bodies when 8BITMIME is
> supported
That's not SMTP -- it's ESMTP and 8BITMIME is an optional
extension. ESMTP is itself optional.
>>>You are confusing two issues. We are discussing MIME-style parameters, as
>>>in "Date: 13 Sep 2002 12:34:56 -0700; foo=bar". I see no 8bit stuff there.
>>
>
>>The draft permits it -- because one example happens not to show
>>all possible permutations of what the draft permits is not
>>relevant to the argument that some of what the draft permits
>>is incompatible with SMTP.
>
>
> Yes, but there are two separate issues to discuss:
>
> 1. To what extent do we permit 8-bit in headers?
>
> 2. To what extent do we permit MIME-style parameters in headers?
>
> These issues are orthogonal. We need to discuss both. But it does not
> further the discussion to use arguments against one as if they were
> arguments against the other.
The argument was in response to your claim that SMTP would
always pass what the draft permits in parameters.
>>1. MIME-style parameters are not applied by MIME to any
>> headers except MIME-specific headers where the relevant
>> defining RFC provides the syntax. N.B. MIME-specific
>> headers always begin with "Content-" (except for
>> MIME-Version, which has no parameters).
>> This draft specifies MIME-style paramters with Date, etc.,
>> which are not MIME-specific headers.
>> It is perhaps of little consequence for new-specific
>> headers such as Injector-Info, but it is clearly not within
>> the authority of this WG to redefine 822/2822 headers.
>>2. MIME does not attempt to change the 822/2822 restrictions
>> on header content, in fact it reinforces and reiterates
>> them (e.g. message media types have the same restrictions).
>> This draft does attempt to do so, in a number of places,
>> in a manner reminiscent of "When I use a word, it means
>> just what I choose it to mean", which is fine for a fictional
>> character in Alice in Wonderland, but not for a technical
>> document intended to be in a collection which includes the
>> unadulterated original.
>
>
> Again, you have sidestepped the issue. Our MIME is defined in 6.21. What
> do you see in 6.21 that would not interoperate with mail MIME?
We were discussing MIME-style parameters in non-MIME headers...
Nevertheless, in 6.21:
"subject to the revised syntax of parameter"
"UTF-xtra-chars to appear within quoted-strings"
6.21.2.2:
" The Content-Type "message/rfc822" should be used for the
encapsulation (whether as part of another news article or, more
usually, as part of an email message) of complete news articles which
have already been posted to Netnews and which are for the information
of the recipient, and do not constitute a request to repost them
(refer to 6.21.6.2 for the now obsolete "message/news" formerly
intended for this purpose).
In the case where such an encapsulated news article has Content-
Transfer-Encoding "8bit" or where its headers contain any UTF8-xtra-
chars (2.4.2)"
vs. RFC 2046:
" A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.
However, unlike top-level RFC 822 messages, the restriction that each
"message/rfc822" body must include a "From", "Date", and at least one
destination header is removed and replaced with the requirement that
at least one of "From", "Subject", or "Date" must be present.
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict
conformance to RFC822, nor are the semantics of "message/rfc822"
objects restricted to the semantics defined in RFC822. More
specifically, a "message/rfc822" message could well be a News article
or a MIME message.
No encoding other than "7bit", "8bit", or "binary" is permitted for
the body of a "message/rfc822" entity. The message header fields are
always US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field in
the encapsulated message will reflect this. Non-US-ASCII text in the
headers of an encapsulated message can be specified using the
mechanisms described in RFC 2047.
"