From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 18 2002 - 08:10:27 CDT
In <3D87B79F.7010601@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In <3D8632ED.2080006@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>> Then why do you suppose that RFC 2045 made provision for such a syntax for
>> Content-Type? All the parameters that have not yet been invented are "for
>> some unspecified potential future use", and yet they are permitted.
>2. unlike this draft, 2045 does *not* permit arbitrary
> parameters; it permits IETF-registered (via 2048's
> procedure) ones and experimental ones beginning
> with "x-" (see 2045 section 5.1). And it specifies
> specific baseline parameters which were introduced
> for a specific purpose.
On the contrary, I have reread 2045 section 5.1, and it is clear that you
may write any syntactically correct parameter. RFC 2046 defines various
such parameters, and it is anticipated that future documents will define
others, which is precisly why the ability to write _any_ parameter was
allowed, just so that those future unforeseen parameters would not break
existing implementations. I guess it says somewhere that you just ignore
the ones you do not recognize.
So they had the great foresight to make syntactic provisions for future
enhancements which they could not possibly foresee.
That is _exactly_ what we are trying to do in our draft with the
MIME-style parameters. True we have only used the flexibility in a couple
of places, but there are many more that have been discussed, but not yet
adopted.
>5. MIME was not introduced as an adjunct to a memo
> purporting to document existing practice; it was clearly
> introduced as a new mechanism
Our draft does more than document existing practice. That was explicitly
allowed for by our charter. That is not to say that there have been
differences of opinion as to how far we should take that :-( .
>The "if we don't do it now" argument doesn't hold water. Date et al.
>are defined by 2822, and if and when a successor to 2822 provides
>for MIME-style parameters for them, there's no reason that they cannot
>then also be used with those parameters in news.
It will be impossible for a successor to 2822 to provide for MIME-style
parameters, because of backwards compatibility. It might be possible for a
successor to a successor to 2822 to provide them if a successor to 2822
had first introduced the necessary groundwork.
>> I keep waiting to hear others on this list who support your position. I
>> have not heard them yet.
>Perhaps because you chose to ignore the straw poll recently
>held, where there was a clear consensus that this draft
>should not tinker with mail-defined headers...
No that straw poll was flawed, as several people have observed, and so
most people have ignored it. It cannot be used to demonstrate consensus,
though it has provoked some useful discussions.
>>>No, SMTP provides no guarantee of 8-bit transport....
It provides guaranteed 8-bit transport within bodies when 8BITMIME is
supported (that support is pretty well universal now). That includes the
headers of MIME multiparts (but not headers at the top level, though in
fact only sendmail that I know of has problems there).
>>
>>
>> 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.
>>>>So will you please indicate whereabouts in our draft we specify some
>>>>behaviour that will fail to be observed by a conforming email agent at the
>>>>far end?
>>>
>>
......
>>
>>
>> No it does not. It defines how MIME may be used within Netnews, which is
>> not currently defined by any IETF document. You will find that nearly all
>> of the changes we have provided are in the direction of restricting
>> (usually at the Ought Not level) how MIME may be used. I asked you to
>> identify where our MIME would not be interoperable with mail MIME.
>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?
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk 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