From: Bruce Lilly (blilly@erols.com)
Date: Tue Sep 17 2002 - 18:15:43 CDT
Charles Lindsey wrote:
> In <3D8632ED.2080006@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>>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.
If there is no clear answer already known, then we
are certainly not talking about "current practice"; at
best it is "experimental" -- in this case it is clearly
an attempt to "predict the future".
>>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.
1. Content-Type != Date, (or Message-ID etc.)
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.
3. MIME RFCs do not attempt to redefine the syntax of
822/2822 headers such as Date, etc.; they do not
add parameters to any 822/2822 headers and they do
not permit any characters in headers which are not
permitted by 822/2822
4. the MIME standards did not appear overnight as 2045+,
they began more than a decade ago and did not adversely
impact 822 (or 1036, for that matter)
5. MIME was not introduced as an adjunct to a memo
purporting to document existing practice; it was clearly
introduced as a new mechanism
> 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.
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. And unless or until
that happens, any new application could be handled by a new news-specific
header which does not encroach on 2822 etc.'s prior use.
> 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...
>>>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.
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.
>>>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.
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.
Both of those areas where this draft is incompatible with MIME
not only go far beyond MIME (rather than "restricting
... how MIME may be used"), they go beyond current practice
and are incompatible with 822/2822.