Other-parameters

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Dec 06 2002 - 11:54:15 CST


Here are the changes arising from Issue 3 (I have, of course, made the
necessary changes to the syntax, but will not bore you with them).

I have also included the replacement of 'other-parameter' by
'extension-parameter' together with revised wording as to when they
may be used, as discussed earlier. However, I have now allowed the
use of such parameters involving x-tokens, because I see that we
positively encourage their use (and rightly so) in the case of the
Injector-Info-header (but I might be persuaded that we should only allow
them where we explicitly say so, as in that case).

Old:

4.2.2. MIME-style Parameters
 
   The possibility of allowing MIME-style parameters (whether header-
   specific ones or generic extension-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
        <address>es).
        
New:

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.

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


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.