From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed May 01 2002 - 12:16:37 CDT
In <200204231330.OAA20634@clw.cs.man.ac.uk> Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>I have three items on my list:
>1. Which headers will allow MIME-style parameters.
>Recent discussions seem to indicate that my solution 4c, which removes
>the possibility of such parameters within From, Reply-To, Mail-Copies-To
>and Complaints-To, is acceptable to most people. That is what I will now
>do unless I hear loud screams to the contrary.
In the absence of screams, I have now done this (see diffs below for
changes in section 4. However, I now wonder whether I should not have
included the Sender-header in this list.
The Sender-header differs from the others in that the minor parsing
problem does not arise, and people should not automatically be sending
mail to it (only if something has screwed and they have inspected the
Sender-header manually to see why, and then constructed a manual email to
sort it out).
Also, since the Sender-header is used in a variety of situations, I can
see some possibilty in the future of adding a parameter to it to indicate
the reason for its inclusion.
So, for these two reasons I am inclined to leave it as it is (with
parameter), but it would take only a very small torque on my arm to
persuade me otherwise. So please read the texts in the diffs, and let me
know what you think.
>2. Reply-To <>
>Whilst several people were reluctant to see '<>' removed, only one of
>them actually said he would live with the revised syntax (which is what
>matters). Two, or maybe three were happy to omit the matter entirely.
>Please can we have more views on this? It has to be decided, but it does
>not seem like an issue worthy of the full Straw Poll procedure.
Since that message, there has been only one further response, and that was
for removal. So it is now removed.
Here are the diffs for section 4.
I am now just about ready for a full draft, and I intend to put it out as
soon as the Sender-header issue is settled. You have already seen all the
non-trivial changes that will be in it. As soon as that draft is out, I
will start making noises about Last Call.
*** /tmp/d7XaWeM Wed May 1 18:12:09 2002
--- /tmp/section_4 Wed May 1 17:58:43 2002
***************
*** 29,37 ****
where the USENET-parameter, which MUST always be of the same
syntactic form as an other-parameter (see below), is not provided in
! all headers, and even the other-parameter is omitted in a few cases
! where the content is "unstructured". Observe that "USENET" is (and
! MUST be) of the syntactic form of a header-name.
other-parameter = <a parameter not defined by this standard>
parameter = attribute "=" value
--- 29,37 ----
where the USENET-parameter, which MUST always be of the same
syntactic form as an other-parameter (see below), is not provided in
! all headers, and even the other-parameter is omitted in some cases
! cases (see 4.2.2). Observe that "USENET" is (and MUST be) of the
! syntactic form of a header-name.
other-parameter = <a parameter not defined by this standard>
parameter = attribute "=" value
***************
*** 87,98 ****
variant header whose header-name is syntactically correct, and
reading agents MUST enable them to be displayed, at least optionally,
posting and injecting agents SHOULD NOT generate headers other than
! o headers established by this standard or any extension to it,
o those recognized by other IETF-established standards, notably the
! Email standard [RFC 2822] and its extensions (or alternatively by
! any IANA registry of recognized headers that may be established
! in the future),
! o experimental headers beginning with "X-" (as defined in 4.2.5.1),
o on a provisional basis only, headers related to new protocols
under development which are the subject of (or intended to be the
subject of) some IETF-approved RFC (whether Informational,
--- 87,100 ----
variant header whose header-name is syntactically correct, and
reading agents MUST enable them to be displayed, at least optionally,
posting and injecting agents SHOULD NOT generate headers other than
! o headers established by this standard or any extension to it;
o those recognized by other IETF-established standards, notably the
! Email standard [RFC 2822] and its extensions, excluding any
! explicitly deprecated for Netnews (e.g. see section 9.2.1 for the
! deprecated Disposition-Notification-To-header); or,
! alternatively, those listed in some future IANA registry of
! recognized headers;
! o experimental headers beginning with "X-" (as defined in 4.2.5.1);
o on a provisional basis only, headers related to new protocols
under development which are the subject of (or intended to be the
subject of) some IETF-approved RFC (whether Informational,
***************
*** 109,124 ****
preferred forms for them. Relaying and reading agents MUST, however,
tolerate articles not obeying this convention.
- 4.2.2. Parameters
- The possibility of allowing parameters (whether header-specific ones
- or generic other-parameters) to appear in virtually all headers is
- provided mainly for the purpose of allowing future extensions to
- existing headers, since only a very few specific parameters are
- defined in this standard. Observe that such parameters do not, in
- general, occur in headers defined in other standards, except for the
- MIME standards [RFC 2045] et seq. and their extensions.
Other-parameters (whether those defined elsewhere or experimental
parameters whose attribute is an x-token) MAY be used, where the
syntax so allows, in any of the headers defined in this standard or
--- 111,130 ----
preferred forms for them. Relaying and reading agents MUST, however,
tolerate articles not obeying this convention.
+
+ 4.2.2. MIME-style Parameters
+
+ The possibility of allowing Mime-style parameters (whether header-
+ specific ones or generic other-parameters) to appear in virtually all
+ headers is provided mainly for the purpose of allowing future
+ extensions to existing headers, since only a very few specific
+ parameters are defined in this standard. Observe that such parameters
+ do not, in general, occur in headers defined in other standards,
+ except for the MIME standards [RFC 2045] et seq. and their
+ extensions.
+
Other-parameters (whether those defined elsewhere or experimental
parameters whose attribute is an x-token) MAY be used, where the
syntax so allows, in any of the headers defined in this standard or
***************
*** 125,137 ****
its extensions except that, at present, they SHOULD NOT be used in
headers in widespread use prior to the introduction of this standard
(this restriction is likely to be removed in a future version of this
! standard). Nevertheless, compliant software MUST accept all such
! parameters (ignoring them if their meaning is unknown) and SHOULD
! accept (and ignore) them even in headers defined in other standards.
! NOTE: The presence of a ";" in a header does not indicate the
! presence of a parameter in the few situations where it can be
! legitimately be parsed as part of the content of that header.
Each header-specific parameter introduced in this standard is
described by specifying
--- 131,148 ----
its extensions except that, at present, they SHOULD NOT be used in
headers in widespread use prior to the introduction of this standard
(this restriction is likely to be removed in a future version of this
! standard). Nevertheless, compliant software MUST accept such
! parameters where required by this standard (ignoring them if their
! meaning is unknown) and SHOULD accept (and ignore) them in all
! "structured" headers (wherever defined).
! NOTE: The syntax does not permit other-parameters in headers
! with "unstructured" contents (where they are unnecessary) or in
! certain headers (notably the From-, Reply-To-, Mail-Copies-To-
! and Complaints-To-headers) containing addresses or mailboxes (so
! that agents can simply replace the header-name by "To" or "Cc"
! to obtain a header immediately suitable for sending Email, and
! also so as to avoid some minor parsing problems with addresses).
Each header-specific parameter introduced in this standard is
described by specifying
***************
-- 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