From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 11 2002 - 07:03:25 CDT
In <3D7E8948.5020900@alex.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In fact we already removed it from From-, Reply-To-, Mail-Copies-To- and
>> Complaints-To-headers, and you could argue that Sender should have been
>> included in that batch (the reason it was not is that the parsing
>> ambiguity does not apply there, and there is no great requirement to take
>> a Sender and turn it automatically into a To for reply purposes).
>Having done some extensive parsing work, I can state that there's
>no parsing ambiguity. There should be no problem with Complaints-To
>or Mail-Copies-To -- those are newly defined in the Usefor draft, so
>they could include MIME-style parameters if there were a need to do
>so.
The ambiguity arises if the 'group' syntax from RFC 2822 is used (it never
is, of course, but we have to be prepared), beacuse it includes a ';'.
Yes, I know it can be parsed by a suitable Turing machine, but it is a
bloody nuisance, which is one of the reasons why we removed the insistence
on doing it.
>But headers defined in other RFCs should not be [re]defined incompatibly
>in our draft.
There is no reason why headers should not be defined differently in mail
and news. It is simply a question of wether it is wise or not in each
particular case. The news headers are already a superset of the mail ones,
because we allow UTF-8. Essentially, we took a conscious decision to place
the burden, if any, on the gateways, in order to achieve a cleaner product
within the news environment (which is our primary concern).
>The incompaibility arises whenever such a header might be injected
>into its native domain, viz. email. I mentioned three such
>mechanisms earlier, and I now add a fourth; the four are:
>1. post-and-mail
>2. incoming gateways from email (also when a proto-article is sent
> to a moderator via email w/o encapsulation)
>3. outgoing gateways
>4. via intermediate files. A usenet article may be saved as a file
> and subsequently forwarded as email (or some software (e.g. combined
> news reader/email program) might do so w/o an intermediate file)
Yes, these cases all need to be taken care of in the proper places
(gateways, for example). The draft draws attention to what needs to be
done. Actually, I don't think there is much problem with (2), and (4) is
simply a complicated way of going gatewaying. He who hacks around with
files bears the responsibility for doing it right.
The following cases are the ones you have asked to be changed. They need
to be decided on an individual basis, but so far I have heard no support
for your request. So hands up, please, anyone who wants to exclude
MIME-style parameters in these cases (or from anyone who wants to retain
them, for that matter).
>> So there is an arguable case for Sender.
>Sender is defined in RFC 2822, section 3.6.2.
>> We have already removed it from Message-ID.
>Hmmm. In response to a request for the full draft, Charles wrote
>(on Aug 2):
>> > Is this draft available in full somewhere?
The current draft is draft-ietf-usefor-article-08.txt, which is available
both on the Landfield site and from the usual internet-drafts sources. You
have been looking at an earlier one.
>> There is an arguable case for Date.
>Date is defined in RFC 2822 section 3.6.1.
>> I am not convinced there is a serious problem wuth Keywords.
>Keywords is defined in RFC 2822 section 3.6.5.
>> And I am not convinced about References.
>References is defined in RFC 2822 section 3.6.4.
>And Supersedes is defined in RFC 2156, and has no provision
>for MIME-style parameters. The Usefor syntax for Supersedes
>(excepting the paramters) is a subset of what 2156 permits --
>if parameters are removed from the specification in the draft
>there won't be any problems in cases 1 and 3 (and presumably
>incoming gateways and injection agents will deal with any
>email-originated Supersedes headers which have multiple msg-ids).
No, we make it clear in 6.15.that our Supersedes header has no connection
with that defined in RFC 2156 (which is provided purely for use with
gateways from X-400 mail). The semantics are totally different. We
discussed and resolved this issue several months ago.
>> My understranding is that it is already not allowed for CTE and any other
>> MIME headers that do not allow it, since we simply incorporate the
>> relevant MIME documents, modulo various trimmings we explicitly mention.
>The text of section 4.2.2 seems to imply that MIME-style parameters
>may be added willy-nilly to these headers.
OK, that could be clarified.
>A related concern is that 6.21.1 specifically states that those
>headers which *are* defined such as to accept parameters may be
>generated in such a way as to be imcompatible with the syntax
>in the defining standards (specifically UTF-xtra-chars). That
>should not be done, as the MIME RFCs specifically provide a means
>of encoding 8-bit characters in parameters (see RFC 2231 and
>the RFC errata page at http://www.rfc-editor.org/errata.html).
It is generally the case that our draft allows either UTF-8 OR RFC
2047/2231 in all relevant places (with no bias either way - it is a matter
for the market place). Of course, in the case of posted and mailed and
similar situations, the sensible approach might well be to use RFC
2047/2231 for both, but that is up to the implementor.
-- 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