From: Claus Färber (list-ietf-wg-apps-usefor@faerber.muc.de)
Date: Tue Sep 17 2002 - 18:21:00 CDT
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:
>>>> 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.
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:
With Content-Type, there already were media types that had parameters
from day 1 (e.g. the charset parameters for text/plain). So software
authors had to implement it
If the extension mechanism had been included just in case it would be
needed at some time, many software authors would probably not have
implemented it at all and it would have been worth nothing to include
it.
> 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.
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.
For new headers, you one can either provide an extension mechanism that
will already be used from the beginning or leave it out.
Currently, we only have two new headers for which parameters are
defined:
Injector-Info already has defined some parameters.
For Archive, we could easily define some. (No, I don't think filename
belongs there.)
> I keep waiting to hear others on this list who support your position. I
> have not heard them yet.
Here.
Claus
-- ------------------------ http://www.faerber.muc.de/ ------------------------ OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0