usefor-article-09 February 2003

4.2.2.  MIME-style Parameters

   A few header-specific MIME-style parameters are defined in this
   standard, but there is also provision for generic extension-
   parameters to appear in most headers for the purpose of allowing
   future extensions to those headers. 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.

   Extension-parameters, other than those using x-tokens, MUST NOT be
   used unless they have first been defined in an IETF-approved RFC
   (whether Informational, Experimental or Standards-Track) or, on a
   provisional basis only, in relation to new protocols under
   development which are the subject of (or intended to be the subject
   of) some such IETF-approved RFC. They MUST ONLY be defined for use in
   those headers where the syntax of this standard so allows. They
   SHOULD NOT, at present, be defined for use 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 wherever
   syntactically allowed in this standard (ignoring them if their
   meaning is unknown) and SHOULD accept (and ignore) them in all
   structured headers wherever defined.
[We could go further, and establish an IANA registry for these
parameters, preloaded with the ones already defined in this standard. A
good model for setting up such a registry is to be found in RFC 2183
(Content-Disposition).]
        NOTE: The syntax does not permit extension-parameters in
        unstructured headers (where they are unnecessary) or in certain
        headers (notably the Date-, From-, Message-ID-, Reply-To-,
        Sender-, Keywords-, Mail-Copies-To-, References-, Supersedes-
        and Complaints-To-headers) which are the same (or similar to)
        headers already existing in the Email standards.

   Each header-specific MIME-style parameter introduced in this standard
   is described by specifying
     (a) the token to be used in its attribute, and
     (b) the syntax rule(s) defining the object(s) permitted in its
         value.
   If a value object is not of the syntactic form of a token, it MUST
   (and otherwise MAY) be encapsulated in a quoted-string (see 2.4.3).
   Observe that the syntax of a parameter also allows additional WSP,
   folding and comments.

   The semantics of a parameter is always to associate the token in its
   attribute with the object represented by the token, or the semantic
   value (2.4.3) of the quoted-string, contained in its value.

   For example, the posting-sender-parameter (6.19) is defined to be
      <a parameter with attribute "sender" and value some sender-value>
   where
      sender-value      = mailbox / "verified"
   A valid posting-sender-parameter would be
      sender = "\"Joe D. Bloggs\" <jdbloggs@bloggs.example>" (authinfo)
   The comment (syntactically part of the quoted-string) is irrelevant.
   The actual mailbox (to be used, for example, if email is to be sent
   to the sender) is
      "Joe D. Bloggs" <jdbloggs@bloggs.example>

--- ../usefor-article-08/MIME-style_Parameters.out          August 2002
+++ ../usefor-article-09/MIME-style_Parameters.out          February 2003
@@ -1,33 +1,36 @@
 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.
+   A few header-specific MIME-style parameters are defined in this
+   standard, but there is also provision for generic extension-
+   parameters to appear in most headers for the purpose of allowing
+   future extensions to those headers. 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
-   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
+   Extension-parameters, other than those using x-tokens, MUST NOT be
+   used unless they have first been defined in an IETF-approved RFC
+   (whether Informational, Experimental or Standards-Track) or, on a
+   provisional basis only, in relation to new protocols under
+   development which are the subject of (or intended to be the subject
+   of) some such IETF-approved RFC. They MUST ONLY be defined for use in
+   those headers where the syntax of this standard so allows. They
+   SHOULD NOT, at present, be defined for use 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 wherever
+   syntactically allowed in 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
+[We could go further, and establish an IANA registry for these
+parameters, preloaded with the ones already defined in this standard. A
+good model for setting up such a registry is to be found in RFC 2183
+(Content-Disposition).]
+        NOTE: The syntax does not permit extension-parameters in
         unstructured headers (where they are unnecessary) or in certain
-        headers (notably the From-, Reply-To-, Mail-Copies-To- and
-        Complaints-To-headers) containing address-lists or mailbox-lists
-        (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
-        <address>es).
+        headers (notably the Date-, From-, Message-ID-, Reply-To-,
+        Sender-, Keywords-, Mail-Copies-To-, References-, Supersedes-
+        and Complaints-To-headers) which are the same (or similar to)
+        headers already existing in the Email standards.
 
    Each header-specific MIME-style parameter introduced in this standard
    is described by specifying