From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Sep 17 2002 - 05:21:50 CDT
In <3D8632ED.2080006@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In <3D80D661.5060803@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>>>Date: 13 Sep 2002 12:34:56 -0700; foo=bar
>>>Message-ID: <xyz123@example.domain.invalid>;fribble=blurfl
>>>Keywords: compatibility, interoperability; reality=NOT
>>>etc.?
>>
>>
>> I dunno. They all come within the scope of that SHOULD NOT. You have made
>> proposals for change in those areas. I am waiting to see hands raised in
>> your support. I haven't seen any yet.
>That doesn't answer the question of whether or not *all*
>existing news (or mail) software will fail to choke on
>such headers. ....
Yes, it does. I said "I dunno". Which is in essence an invitation for
others to come in and say that they DO know.
>Moreover you rationale for introducing the MIME-style
>parameters (viz. for some unspecified potential future
>use) is something that clearly doesn't belong in an IETF
>document that is intended to become a standard, or have
>you forgotten so quickly
>(http://www.imc.org/ietf-822/mail-archive/msg02433.html)?
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.
This generality, for future extensibility, was proposed by Brad Templeton
way back, discussed on this list, and accepted. If we do not introduce it
_now_, it will never be possible to make use of it when one of those
"unspecified potential future" things happens, because the then installed
base will reject it.
I keep waiting to hear others on this list who support your position. I
have not heard them yet.
>> For a start, they will all get transported correctly (because RFC 821 does
>> not look at the headers inside a message, except for CTE).
><snip>
>No, SMTP provides no guarantee of 8-bit transport....
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.
That would clearly be transported by all known mail transports, and the
only issue is whether it would cause problems upon arrival.
>> 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?
>That is neither the issue, nor a suitable metric. The issue
>is that the draft as currently written endorses violation of
>existing IETF RFCs and protocols. If the document is to have
>any chance of being accepted by the IETF, that will have to
>change. It should be changed before submission to the IETF,
>else we'll look like fools for having submitted it.
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.
-- 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