Re: MIME-style parameters

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 18 2002 - 08:32:40 CDT


In <8X6eY5NZcDC@3247.org> list-ietf-wg-apps-usefor@faerber.muc.de (Claus Färber) writes:

>Charles Lindsey <chl@clw.cs.man.ac.uk> schrieb/wrote:
>> 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:

>> 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.

>The difference is that these were completly new headers. With new
>headers, it is a good idea to provide some way to extend it PROVIDED
>that there are already some things that already need the extension
>mechanism:

Indeed, which is more or less the idea behind introducing the possibility
as widely as we can. Many possible applications have been discussed (and
mayy more doubtless will be), even though only two have made it into the
present draft.

>For existing headers (like Message-ID), why is "_now_" any better than
>any other point of time in the future? The header exists today, software
>relies on its format and any article that has a Message-ID header field
>with a parameter will probably be dropped instantly by most news
>transport agents.

It would be better if you could provide an example that actually did that.
It is, of course, why it is a "SHOULD NOT" to do any such thing.

As to why "_now_", it is because we are doing it now for our own news
headers, which provides a convenient opportunity to consider it more
widely.

>> I keep waiting to hear others on this list who support your position. I
>> have not heard them yet.

>Here.

Thank you. Now we can start to consider the possibilities.

The headers we are talking about are:

Date
Message-ID
Sender
Keywords
References
Supersedes

Since those are the ones that occur in RFC 2822 (except Supersedes, which
is really a news header that mail has "borrowed").

Actions we might take are

To remove MIME-style parameters from them all en block.

To consider each one on its merits

To make some provision stronger than SHOULD NOT, pending some future
action by the mail people

And maybe other possibilities.

As regards the individual cases, I could easily be persuaded for Sender,
and only with difficulty for Supersedes, and with the others in between.
BTW, can someone tell me whether "References" is an email header that was
adopted by news, or a news header that was adopted by email. Whichever, it
must have been a long time ago.

-- 
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


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.