rfc3297.txt

RFC 的详细文档！

   other default format (e.g. Intenet fax [1] has TIFF profile S [11] as
   its default format;  see section 7 of this document).

   "Extended Facsimile Using Internet Mail" [1] and "Indicating
   Supported Media Features Using Extensions to DSN and MDN" [2]
   indicate a possible mechanism for a sender to have prior knowledge of
   receiver capabilities.  This specification builds upon the mechanism
   described there.

   As always, the sender may gather information about the receiver in
   other ways beyond the scope of this document (e.g., a directory
   service or the suggested RESCAP protocol).

3.1.2 MDN request indicating alternate data formats

   When a sender is indicating preparedness to send alternative message
   data, it MUST request a Message Disposition Notification (MDN) [4].

   It indicates its readiness to send alternative message data by
   including the MDN option 'Alternative-available' [9] with the MDN
   request.  Presence of this MDN request option simply indicates that
   the sender is prepared to send some different data format if it has
   more accurate or up-to-date information about the receiver's
   capabilities.  Of itself, this option does not indicate whether the
   alternatives are likely to be better or worse than the default data
   sent -- that information is provided by the "Content-alternative"
   header(s) [8].

   When using the 'Alternative-available' option in an MDN request, the
   message MUST also contain a 'Message-ID:' header with a unique
   message identifier.








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


3.1.3 Information about alternative data formats

   A sender can provide information about the alternative message data
   available by applying one or more 'Content-alternative' headers to
   message body parts for which alternative data is available, each
   indicating media features [5,6] of an available alternative.

   The purpose of this information is to allow a receiver to decide
   whether any of the available alternatives are preferable, or likely
   to be preferable, to the default message data provided.

   Not every available alternative is required to be described in this
   way, but the sender should include enough information to allow a
   receiver to determine whether or not it can expect more useful
   message data if it chooses to indicate a preference for some
   alternative that matches its capabilities.

   Alternative formats will often be variations of the content-type
   originally sent.  When different content-types can be provided, they
   should be indicated in a corresponding content-alternative header
   using the 'type' media feature tag [24].  (See example 8.4.)

      NOTE:  the sender is not necessarily expected to describe every
      single alternative format that is available -- indeed, in cases
      where content is generated on-the-fly rather than simply selected
      from an enumeration of possibilities, this may be infeasible.  The
      sender is expected to use one or more 'Content-alternative'
      headers to reasonably indicate the range of alternative formats
      available.

      The final format actually sent will always be selected by the
      sender, based on the receiver's capabilities.  The 'Content-
      alternative' headers are provided here simply to allow the
      receiver to make a reasonable decision about whether to request an
      alternative format that better matches its capabilities.

      ALSO NOTE:  this header is intended to be usable independently of
      the MDN extension that indicates the sender is prepared to send
      alternative formats.  It could be used with a different protocol
      having nothing to do with email or MDN.  Thus, the 'Content-
      alternative' header provides information about alternative data
      formats without actually indicating if or how they might be
      obtained.

      Further, the 'Content-alternative' header applies to a MIME body
      part, where the MDN 'Alternative-available' option applies to the
      message as a whole.




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


   The example sections of this memo show how the 'Content-features:'
   and 'Content-alternative:' MIME headers may be used to describe the
   content provided and available alternatives.

3.2 Receiver options

   A negotiation-aware system receiving message data without an
   indication of alternative data formats MUST process that message in
   the same way as a standard Internet fax system or email user agent.

   Given an indication of alternative data format options, the receiver
   has three primary options:

   (a)   do not recognize the alternatives:  passively accept what is
         provided,

   (b)   do not prefer the alternatives:  actively accept what is
         provided, or

   (c)   prefer some alternative format.

3.2.1 Alternatives not recognized

   This corresponds to the case that the receiver is a simple mode
   Internet fax recipient [12], or a traditional email user agent.

   The receiver does not recognize the alternatives offered, or chooses
   not to recognize them, and simply accepts the data as sent.  A
   standard MDN response [4] or an extended MDN response [2] MAY be
   generated at the receiver's option.

3.2.2 Alternative not desired

   The receiver does recognize the alternatives offered, but
   specifically chooses to accept the data originally offered.  An MDN
   response SHOULD be sent indicating acceptance of the data and also
   containing the receiver's capabilities.

   This is the same as the defined behaviour of an Extended Internet Fax
   receiver [1,2].

3.2.3 Alternative preferred

   This case extends the behaviour of Extended Internet Fax [1,2] to
   allow an alternative form of data for the current message to be
   transferred.  This option may be followed ONLY if the original
   message contains an 'Alternative-available' MDN option (alternative




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


   data re-sends may not use this option).  Further, this option may be
   followed ONLY if the recipient is explicitly addressed in the message
   headers ('to:', 'cc:' or 'bcc:').

   The receiver recognizes that alternative data is available, and based
   on the information provided determines that an alternative format
   would be preferable.  An MDN response [4] is sent, which MUST contain
   the following:

   o  an 'Alternative-preferred' disposition modifier [9] indicating
      that some data format other than that originally sent is
      preferred,

   o  an 'Original-Message-ID:' field [4] with the message identifier
      from the received message, and

   o  receiver capabilities, per RFC 2530 [2].

   On sending such an MDN response, the receiver MAY discard the message
   data provided, in the expectation that some alternative will be sent.
   But if the sender has indicated a limited lifetime for the
   alternative data, and the original data received is within the
   receiver's capability to display, the receiver SHOULD NOT discard it.
   Lacking sufficient memory to hold the original data for a period of
   time within which alternative data would reasonably be received, the
   receiver SHOULD accept and display the original data.  In the case
   that the original data is not within the receiver's capability to
   display then it SHOULD discard the original data and request an
   alternative format.

      NOTE:  the above rules are meant to ensure that the content
      negotiation framework does not result in the loss of data that
      would otherwise be received and displayed.

   Having requested alternative data and not displayed the original
   data, the receiver MUST remember this fact and be prepared to take
   corrective action if alternative data is not received within a
   reasonable time (e.g., if the MDN response or transmission of
   alternative data is lost in transit).

   Corrective action might be any of the following:

   (a)   re-send the MDN response, and continue waiting for an
         alternative,

   (b)   present the data originally supplied (if it is still
         available), or




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


   (c)   generate an error response indicating loss of data.

   On concluding that alternative data is not forthcoming, the preferred
   option is (b), but this may not be possible for receivers with
   limited memory.

   See Appendix A for further discussion of receiver behaviour options.

      NOTE:  A cache control indicator on recipient capabilities has
      been considered, but is not included in this specification.
      (Sometimes, a recipient may want to offer certain capabilities
      only under certain circumstances, and does not wish them to be
      remembered for future use; e.g., not wanting to receive colour
      images for routine communications.)

      NOTE:  the receiver does not actually get to select any specific
      data format offered by the sender.  The final choice of data
      format is always made by the sender, based on the receiver's
      declared capabilities.  This approach:

      (a)   more closely matches the style of T.30 content negotiation,

      (b)   provides for clean integration with the current extended
            mode Internet fax specification,

      (c)   builds upon existing email mechanisms in a consistent
            fashion, and

      (d)   allows for cases (e.g., dynamically generated content) where
            it is not feasible for the sender to enumerate the
            alternatives available.

3.3 Send alternative message data

   Having offered to provide alternative data by including an
   'Alternative-available' option with the original MDN request, and on
   receipt of an MDN response indicating 'Alternative-preferred', the
   sender SHOULD transmit alternative message data that best matches the
   receiver's declared capabilities.  (In the exceptional case that the
   response requesting an alternative data format does not contain
   receiver capabilities, a baseline format should be selected.)

   If any part of the best available message data matching the receiver
   capabilities is the same as that originally sent, it MUST still be
   re-transmitted because the receiver may have discarded the original
   data.  Any data sent as a result of receiving an 'Alternative-
   preferred' response should include an MDN request but SHOULD NOT
   include an 'Alternative-available' disposition notification modifier.



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


   If the sender is no longer able to send message data for any reason,
   it MUST send a message to the receiver indicating a failed transfer.
   It SHOULD also generate a report for the receiver indicating the
   failure, containing an MDN request and including an 'Alternative-
   not-available' disposition notification modifier.

   Any message sent to a receiver in response to a request for
   alternative data MUST include an 'Original-Message-ID:' header [23]
   containing the Original-message-ID value from the received
   disposition notification message (which is the 'Message-ID:' from the
   original message).  This header serves to correlate the re-send (or
   failure message) with the original message, and also to distinguish a
   re-send from an original message.

3.4 Confirm receipt of resent message data

   When resent data is received (indicated by presence of an 'original-
   message-ID:' header field), the receiver processes that data and
   generates an MDN response indicating the final disposition of the
   data received, and also indicating capabilities that may be used for
   future messages, per RFC 2530 [2] and RFC 2532 [1].

   If the re-send indicates that alternative data is no longer available
   (by including an 'Alternative-not-available' disposition notification
   modifier), and the receiver still holds the original data sent, it
   should display or process the original data and send an MDN response
   indicating the final disposition of that data.  Thus, the response to
   an 'Alternative-not-available' indication may be a successful
   disposition notification.

   If the re-send indicates that alternative data is no longer available
   (by including an 'Alternative-not-available' disposition notification
   modifier), and the receiver has discarded the original data sent, it
   SHOULD:

   (a)   display or process the failure message received, OR

   (b)   construct and display a message indicating that message data
         has been lost, preferably indicating the sender, time, subject,
         message identifier and other information that may help the
         recipient user to identify the missing message.

   and send a message disposition response indicating a final message
   disposition of "deleted".