From: Bruce Lilly (blilly@erols.com)
Date: Mon Sep 16 2002 - 14:37:17 CDT
Charles Lindsey wrote:
> In <3D80D661.5060803@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>> How much existing news or mail software
>>can deal with
>>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. That includes any news software that needs
to examine Date, Message-ID, References, etc. headers.
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)?
> 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. There
is an optional extension for negotiation of 8-bit transport
in ESMTP, but as it is an extension and an option, not
a requirement or guarantee, one cannot rely on it being
available.
>>Future requirements for which there are no current concrete, tested
>>solutions are best dealt with after the issues have been clearly identified,
>>possible solutions are proposed, their pros and cons enumerated, and
>>experiments undertaken to ensure interoperability.
And I would add that all of that would be the subject for
a new proposal, not for this WG.
> But not if some prior decision has ruled out what would otherwise have
> been the best solution. These parameters are an investment for the future.
> The payoff may well be years away, but they were put there after much
> discussion on this WG.
>
> We have carefully arranged that their syntax follows that of MIME, so that
> existing bits of software that deal with MIME headers can be reused.
See http://www.imc.org/ietf-822/mail-archive/msg02433.html again.
[...]
> 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.