rfc3297.txt

RFC 的详细文档！

Klyne, et. al.              Standards Track                    [Page 17]

RFC 3297      Content Negotiation for Messaging Services       July 2002


4. The Content-alternative header

   The 'Content-alternative:' header is a MIME header that can be
   attached to a MIME body part to indicate availability of some
   alternative form of the data it contains.  This header does not, of
   itself, indicate how the alternative form of data may be accessed.

   Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content-
   alternative' header is defined as:

      Content-alternative-header =
          "Content-alternative" ":" Alternative-feature-expression

      Alternative-feature-expression =
          <As defined for 'Filter' by RFC 2533 [6]>

   More than one 'Content-alternative:' header may be applied to a MIME
   body part, in which case each one is taken to describe a separate
   alternative data format that is available.

   A content-alternative header is used with some MIME-encapsulated
   data, and is interpreted in that context.  The intent is to indicate
   possible variations of that data, and it is not necessarily expected
   to be a complete free-standing description of a specific available
   data.  Enough information should be provided for a receiver to be
   able to decide whether or not the alternative thus described (a) is
   likely to be an improvement over the actual data provided, and (b) is
   likely to be processable by the receiver.

   Thus, when interpreting a Content-alternative header value, a
   receiver may assume that features not explicitly mentioned are not
   different in the indicated alternative from the supplied data.  For
   example, if a Content-alternative header does not mention an
   alternative MIME content-type, the receiver may assume that the
   available alternative uses the same content-type as the supplied
   data.

   See also the example in section 8.4.

5. The Original-Message-ID message header

   The 'Original-Message-ID' header is used to correlate any message
   response or re-send with the original message to which it relates
   (see also sections 3.2.3,  3.3).  A re-send is distinct from the
   original message, so it MUST have its own unique Message-ID value
   (per RFC 2822, section 3.6.4).





Klyne, et. al.              Standards Track                    [Page 18]

RFC 3297      Content Negotiation for Messaging Services       July 2002


   The syntax for this header is:

      "Original-Message-ID" ":" msg-id

   where 'msg-id' is defined by RFC 2822 as:

      msg-id = "<" id-left "@" id-right ">"

   The 'msg-id' value given must be identical to that supplied in the
   Message-ID: header of the original message for which the current
   message is a response or re-send.

6. MDN extension for alternative data

   Here, we define two extensions to the Message Disposition
   Notification (MDN) protocol [4] to allow a sender to indicate
   readiness to send alternative message data formats, and to allow a
   receiver to indicate a preference for some alternative format.

   Indication of what alternatives may be available or preferred are not
   covered here.  This functionality is provided by the 'Content-
   alternative' MIME header [8] and "Indicating Supported Media Features
   Using Extensions to DSN and MDN" [2].

6.1 Indicating readiness to send alternative data

   A sender wishing to indicate its readiness to send alternative
   message data formats must request an MDN response using the MDN
   'Disposition-Notification-To:' header [4].

   The MDN request is accompanied by a 'Disposition-Notification-
   Options:' header containing the parameter 'Alternative-available'
   with an importance value of 'optional'.  (The significance of
   'optional' is that receiving agents unaware of this option do not
   generate inappropriate failure responses.)

   This specification defines a value for 'attribute' to be used in an
   MDN 'Disposition-Notification-Options:' header [4]:

      attribute =/ "Alternative-available"

   Thus, a sender includes the following headers to indicate that
   alternative message data is available:

      Disposition-Notification-To:
          <sender-address>
      Disposition-Notification-Options:
          Alternative-available=optional,<lifetime>



Klyne, et. al.              Standards Track                    [Page 19]

RFC 3297      Content Negotiation for Messaging Services       July 2002


   where <lifetime> is "transient" or "permanent", indicating whether
   the alternative data will be made available for just a short while,
   or for an indefinite period.  A value of "permanent" indicates that
   the data is held on long term storage and can be expected to be
   available for at least several days, and probably weeks or months.  A
   value of "transient" indicates that the alternative data may be
   discarded at any time, though it would normally be held for the
   expected duration of a message transaction.

      NOTE: the <lifetime> parameter is provided to help low-memory
      receivers (which are unable to store received data) avoid loss of
      information through requesting an alternative data format that may
      become unavailable.

   A message sent with a request for an MDN with an 'Alternative-
   available' option MUST also contain a 'Message-ID:' header field
   [20].

6.2 Indicating a preference for alternative data

   The MDN specification [4] defines a number of message disposition
   options that may be reported by the receiver of a message:

      disposition-type = "displayed"
                       / "dispatched"
                       / "processed"
                       / "deleted"
                       / "denied"
                       / "failed"

      disposition-modifier = ( "error" / "warning" )
                           / ( "superseded" / "expired" /
                               "mailbox-terminated" )
                           / disposition-modifier-extension

   This specification defines an additional value for 'disposition-
   modifier-extension':

      disposition-modifier-extension =/
          "Alternative-preferred"

   When a receiver requests that an alternative format be sent, it sends
   a message disposition notification message containing the following
   disposition field:

      Disposition:
        <action-mode>/<sending-mode>,
        deleted/alternative-preferred



Klyne, et. al.              Standards Track                    [Page 20]

RFC 3297      Content Negotiation for Messaging Services       July 2002


   For example, an automatically generated response might contain:

      Disposition:
        automatic-action/MDN-sent-automatically,
        deleted/alternative-preferred

   An MDN response containing an 'alternative-preferred' disposition
   modifier MUST also contain an 'Original-message-ID:' field [4] with
   the 'Message-ID:' value from the original message.

   An MDN response containing an 'alternative-preferred' disposition
   modifier SHOULD also contain a 'Media-accept-features:' field [2]
   indicating the capabilities that the sender should use in selecting
   an alternative form of message data.  If this field is not supplied,
   the sender should assume some baseline feature capabilities.
   Receiver capabilities supplied with an alternative-preferred
   disposition notification MUST NOT be cached:  they may apply to the
   current transaction only.

6.3 Indicating alternative data is no longer available

   A sender that receives a request for alternative data that is no
   longer available, or is unable to provide alternative data matching
   the receiver's capabilities, MUST respond with an indication of this
   fact, sending a message containing data describing the failure.

   Such a message MUST specify the MDN 'Disposition-Notification-To:'
   header [4], accompanied by a 'Disposition-Notification-Options:'
   header containing the parameter 'Alternative-not-available' with an
   importance value of 'required'.

   This specification defines a value for 'attribute' to be used in an
   MDN 'Disposition-Notification-Options:' header [4]:

      attribute =/ "Alternative-not-available"

   Thus, a sender includes the following headers to indicate that the
   alternative message data previously offered is no longer available:

      Disposition-Notification-To:
          <sender-address>
      Disposition-Notification-Options:
          Alternative-not-available=required,(TRUE)

   A message sent with a request for an MDN with an 'Alternative-not-
   available' option MUST also contain an 'Original-message-ID:'  header
   [23] containing the value from the 'Message-ID:' header of the
   original message.



Klyne, et. al.              Standards Track                    [Page 21]

RFC 3297      Content Negotiation for Messaging Services       July 2002


6.4 Indicating loss of original data

   This specification defines an additional value for 'disposition-
   modifier-extension':

      disposition-modifier-extension =/
          "original-lost"

   When a receiver loses message data because it lacks memory to store
   the original while waiting for an alternative to be sent, it sends a
   message disposition notification containing the following field:

      Disposition:
        <action-mode>/<sending-mode>,
        deleted/original-lost

   For example, an automatically generated response might contain:

      Disposition:
        automatic-action/MDN-sent-automatically,
        deleted/original-lost

   An MDN response containing an 'original-lost' disposition modifier
   MUST also contain an 'Original-message-ID:' field [4] with the
   'Message-ID:' value from the resent message, or from the original
   message (if no re-send has been received).

6.5 Automatic sending of MDN responses

   In sending an MDN response that requests alternative data, the
   security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2)
   regarding automatic MDN responses must be respected.  In particular,
   a system capable of performing content negotiation MUST have an
   option for its user to disable negotiation responses, either
   generally, on a per-message basis, or both.

7. Internet Fax Considerations

   Internet fax is an application that uses email to exchange document
   images (see RFC RFC 2305 [12] and RFC 2532 [1]).

   Both sender and receiver parts of this specification involve the use
   of media feature expressions.  In the context of Internet fax, any
   such expressions SHOULD employ feature tags defined by "Content
   feature schema for Internet fax" [16].  In a wider email context, any
   valid media features MAY be used.





Klyne, et. al.              Standards Track                    [Page 22]

RFC 3297      Content Negotiation for Messaging Services       July 2002


   For Internet fax [12], "image/tiff" is the assumed content-type for
   message data.  In particular, all Internet fax devices are presumed
   to be capable of sending and receiving the TIFF profile S
   capabilities (Section 3 of [11]).  When communication is between
   Internet fax devices, this capability may be assumed.  But when
   dealing with devices that go beyond these capabilities defined for
   Internet fax (e.g. generic email agents with fax capabilities) it
   would be better not to assume fax capabilities, and for the
   negotiating parties to be explicit with respect to all their
   capabilities.

   It would be better if even Internet fax devices do not assume that
   they are communicating with other such devices.  When using Internet
   email, there is no reliable way to establish this fact.  Therefore,
   for any Internet fax device that may reasonably be expected to
   exchange messages with any other email agent, it is RECOMMENDED that
   Internet fax capabilities (such as image/tiff baseline format
   handling) are not assumed but stated explicitly.

   In particular, the 'Media-Accept-Features:' header in receiver MDN
   responses SHOULD explicitly indicate (type="image/tiff") and baseline
   TIFF capabilities, rather than just assuming that they are
   understood.

8. Examples

8.1 Sending enhanced Internet Fax image

   An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image to
   send to a receiver.  The baseline for Internet fax is 200x200dpi and