usefor-article-13 May 2004

4.2.2.  MIME-style Parameters

   A few header-specific MIME-style parameters are defined in this
   standard (see 6.12 and 6.19), 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 (2.4.2).  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.2) 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-12/MIME-style_Parameters.out          November 2003
+++ ../usefor-article-13/MIME-style_Parameters.out          May 2004