From: Paul Overell (paulo@turnpike.com)
Date: Fri Apr 05 2002 - 03:18:39 CST
In message <200204042005.VAA25723@clw.cs.man.ac.uk>, Charles Lindsey
<chl@clw.cs.man.ac.uk> writes
>Here is the full syntax, after the recent spate of changes.
>
>Now that we can see the full syntax of headers all in one place, we can
>address the issue of where parameters should be allowed, which some
>people have been asking about.
>
>First, two statements which are, I hope, not controversial:
'fraid not.
>
>1. There are no parameters after the "unstructured" headers.
>
OK.
>2. Section 4 says that
> .parameters MAY anywhere our syntax allows, except that
typo: MAY be used
> .they SHOULD NOT be used (for now) in headers that did not have
> them before this standard (i.e. the MAY applies only to the newly
> introduced headers), but
I'm still really unhappy about this. Changing the syntax of existing
headers is not something to be undertaken lightly. With this draft the
only thing stopping someone from sticking parameters onto existing
headers is the above weak "SHOULD NOT be used (for now)". Is that
really a sufficient barrier?
> .compliant software MUST accept (and usually ignore) them anywhere our
> syntax allows, and
I don't like this because, with the existing syntax, it unnecessarily
denounces RFC1036 compliant software to be non-compliant.
Both of the above can be fixed by not retrospectively adding parameters
to existing headers, in which case the statement becomes OK.
> .compliant software SHOULD accept (and ignore) them in all headers
> (including those borrowed from other standards).
>
OK
>Now the present state of our draft:
>
>3. Our syntax allows parameters in all unstructured headers that our draft
>defines. This causes slight parsing difficulties in headers where a naked
>';' can occur in the main part of the header. In fact, that is just the
>headers with address-list in them. There is a NOTE pointing out the need
>for care when parsing these. In other cases, ignoring everything after a
>naked ';' should be easy enough to implement.
>
>4. So we can consider a series of increasingly severe changes we might make:
>
>4a. Leave it as it is.
>
>4b. Disallow parameters in those address-list headers. That would eliminate
> Complaints-To
> Reply-To
> Mail-Copies-To
>(though you might exclude Complaints-To and Mail-Copies-To on the
>grounds that they are "ours", parsing problems or not)
>
>4c. Disallow parameters in the mailbox-list headers (because people get
>confused between the subtle difference between address and mailbox).
>That would eliminate
> From
> Sender
>
>4d. Disallow parameters in all those headers which also appear in RFC
>2822 (however, it might be argued that most of these are really "News
>headers" which Email has borrowd, but does not really use). That would
>eliminate
> Date
> Message-ID
> Keywords
>
and References?
>4e. Disallow also the two headers defined in RFC 2156 which can arise
>from conversion of Emails from X.400. These really our our headers, and
>RFC 2156 had no business filching them. That would eliminate
> Expires
> Supersedes
>
>And in case you were wondering what is left, the headers which really
>are our own are
> Newsgroups
> Path
> Distribution
> Followup-To
> Posted-And-Mailed
> Archive
> Control
> Approved
> Xref
> Lines
> User-Agent
> Injector-Info
> Complaints-To
>
>And of these we have actually define useful parameters for
> Archive
> Injector-Info
>(we also had some in Replaces at one time)
>
>And of course all the MIME headers allow parameters.
>
>
I would go further:
4f. Disallow RFC1036 defined headers, as changing the syntax of these
headers may break deployed software.
This would leave just the newly defined headers that don't take
address-lists
Posted-And-Mailed
Archive
User-Agent
Injector-Info
Regards
-- Paul Overell T U R N P I K E