usefor-article-10 April 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-attributes, 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) its attribute, and
     (b) the syntax rule(s) defining the object(s) permitted in its
         value.
   Any parameter, or set of parameters with numbered sections, which,
   according to [RFC 2231], is semantically equivalent to an unnumbered
   regular-parameter with that attribute and value may be used.

        NOTE: If the value is not of the syntactic form of a token and
        is not encoded as an extended-value, it is necessary to
        encapsulate it within 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 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-09/MIME-style_Parameters.out          February 2003
+++ ../usefor-article-10/MIME-style_Parameters.out          April 2003
@@ -7,8 +7,8 @@
    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
+   Extension-parameters, other than those using x-attributes, 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
@@ -25,6 +25,7 @@
 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-,
@@ -34,17 +35,22 @@
 
    Each header-specific MIME-style parameter introduced in this standard
    is described by specifying
-     (a) the token to be used in its attribute, and
+     (a) 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.
+   Any parameter, or set of parameters with numbered sections, which,
+   according to [RFC 2231], is semantically equivalent to an unnumbered
+   regular-parameter with that attribute and value may be used.
+
+        NOTE: If the value is not of the syntactic form of a token and
+        is not encoded as an extended-value, it is necessary to
+        encapsulate it within 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.
+   The semantics of a parameter is always to associate 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>