usefor-article-07 May 2002

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
   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
        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
        addresses).

   Each header-specific 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@example.com>" (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@example.com>