doc: Add RFC documents

1 files changed, 2579 insertions, 0 deletions

diff --git a/doc/rfc/rfc3297.txt b/doc/rfc/rfc3297.txt
new file mode 100644
index 0000000..1a9b8e6
--- /dev/null
+++ b/doc/rfc/rfc3297.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Network Working Group                                           G. Klyne
+Request for Comments: 3297                        Clearswift Corporation
+Category: Standards Track                                     R. Iwazaki
+                                                             Toshiba TEC
+                                                              D. Crocker
+                                             Brandenburg InternetWorking
+                                                               July 2002
+
+
+       Content Negotiation for Messaging Services based on Email
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo describes a content negotiation mechanism for facsimile,
+   voice and other messaging services that use Internet email.
+
+   Services such as facsimile and voice messaging need to cope with new
+   message content formats, yet need to ensure that the content of any
+   given message is renderable by the receiving agent.  The mechanism
+   described here aims to meet these needs in a fashion that is fully
+   compatible with the current behaviour and expectations of Internet
+   email.
+
+Table of Contents
+
+   1. Introduction................................................... 3
+     1.1 Structure of this document ................................. 4
+     1.2 Document terminology and conventions ....................... 4
+        1.2.1 Terminology............................................ 4
+        1.2.2 Design goals........................................... 5
+        1.2.3 Other document conventions............................. 5
+   2. Background and goals........................................... 5
+     2.1 Background ................................................. 5
+        2.1.1 Fax and email.......................................... 5
+        2.1.2 Current facilities in Internet Fax..................... 6
+     2.2 Closing the loop ........................................... 6
+
+
+
+Klyne, et. al.              Standards Track                     [Page 1]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+     2.3 Goals for content negotiation .............................. 8
+   3. Framework for content negotiation..............................10
+     3.1 Send data with an indication of alternatives ...............11
+        3.1.1 Choice of default data format..........................12
+        3.1.2 MDN request indicating alternate data formats..........12
+        3.1.3 Information about alternative data formats.............13
+     3.2 Receiver options ...........................................14
+        3.2.1 Alternatives not recognized............................14
+        3.2.2 Alternative not desired................................14
+        3.2.3 Alternative preferred..................................14
+     3.3 Send alternative message data ..............................16
+     3.4 Confirm receipt of resent message data .....................17
+   4. The Content-alternative header.................................18
+   5. The Original-Message-ID message header.........................18
+   6. MDN extension for alternative data.............................19
+     6.1 Indicating readiness to send alternative data ..............19
+     6.2 Indicating a preference for alternative data ...............20
+     6.3 Indicating alternative data is no longer available .........21
+     6.4 Indicating loss of original data ...........................22
+     6.5 Automatic sending of MDN responses .........................22
+   7. Internet Fax Considerations....................................22
+   8. Examples.......................................................23
+     8.1 Sending enhanced Internet Fax image ........................23
+     8.2 Internet fax with initial data usable ......................27
+     8.3 Negotiate to lower receiver capability .....................28
+     8.4 Sending an alternative content type ........................32
+   9. IANA Considerations............................................36
+     9.1 New message headers ........................................36
+     9.2 MDN extensions .............................................36
+        9.2.1 Notification option 'Alternative-available'............36
+        9.2.2 Notification option 'Alternative-not-available'........36
+        9.2.3 Disposition modifier 'Alternative-preferred'...........37
+        9.2.4 Disposition modifier 'Original-lost'...................37
+   10. Internationalization considerations...........................37
+   11. Security Considerations.......................................37
+   12. Acknowledgements..............................................38
+   13. References....................................................38
+   Appendix A: Implementation issues.................................40
+     A.1 Receiver state .............................................40
+     A.2 Receiver buffering of message data .........................41
+     A.3 Sender state ...............................................42
+     A.4 Timeout of offer of alternatives ...........................42
+     A.5 Timeout of receiver capabilities ...........................42
+     A.6 Relationship to timely delivery ............................43
+     A.7 Ephemeral capabilities .....................................43
+     A.8 Situations where MDNs must not be auto-generated ...........44
+   Appendix B: Candidates for further enhancements...................44
+   Authors' Addresses................................................45
+
+
+
+Klyne, et. al.              Standards Track                     [Page 2]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Full Copyright Statement..........................................46
+
+1. Introduction
+
+   This memo describes a mechanism for email based content negotiation
+   which provides an Internet fax facility comparable to that of
+   traditional facsimile, which may be used by other messaging services
+   that need similar facilities.
+
+   "Extended Facsimile using Internet Mail" [1] specifies the transfer
+   of image data using Internet email protocols.  "Indicating Supported
+   Media Features Using Extensions to DSN and MDN" [2] describes a
+   mechanism for providing the sender with the details of a receiver's
+   capabilities.  The capability information thus provided, if stored by
+   the sender, can be used in subsequent transfers between the same
+   sender and receiver.
+
+   Many communications are one-off or infrequent transfers between a
+   given sender and receiver, and cannot benefit from this "do better
+   next time" approach.
+
+   An alternative facility available in email (though not widely
+   implemented) is for the sender to use 'multipart/alternative' [15] to
+   send a message in several different formats, and allow the receiver
+   to choose.  Apart from the obvious drawback of network bandwidth use,
+   this approach does not of itself allow the sender to truly tailor its
+   message to a given receiver, or to obtain confirmation that any of
+   the alternatives sent was usable by the receiver.
+
+   This memo describes a mechanism that allows better-than-baseline data
+   formats to be sent in the first communication between a sender and
+   receiver.  The same mechanism can also achieve a usable message
+   transfer when the sender has based the initial transmission on
+   incorrect information about the receiver's capabilities.  It allows
+   the sender of a message to indicate availability of alternative
+   formats, and the receiver to indicate that an alternative format
+   should be provided to replace the message data originally
+   transmitted.
+
+   When the sender does not have the correct information about a
+   receiver's capabilities, the mechanism described here may incur an
+   additional message round trip.  An important goal of this mechanism
+   is to allow enough information to be provided to determine whether or
+   not the extra round trip is required.
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 3]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+1.1 Structure of this document
+
+   The main part of this memo addresses the following areas:
+
+   Section 2 describes some of the background, and sets out some
+   specific goals that are addressed in this specification.
+
+   Section 3 describes the proposed content negotiation framework,
+   indicating the flow of information between a sender and receiver.
+
+   Section 4 contains a detailed description of the 'Content-
+   alternative' header that is used to convey information about
+   alternative available formats.  This description is intended to stand
+   independently of the rest of this specification, with a view to being
+   usable in conjunction with other content negotiation protocols.
+
+   Section 5 describes a new mail message header, 'Original-Message-ID',
+   which is used to correlate alternative data sent during negotiation
+   with the original message data, and to distinguish the continuation
+   of an old message transaction from the start of a new transaction.
+
+   Section 6 describes extensions to the Message Disposition
+   Notification (MDN) framework [4] that support negotiation between the
+   communicating parties.
+
+1.2 Document terminology and conventions
+
+1.2.1 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [22].
+
+   Capability exchange
+      An exchange of information between communicating parties
+      indicating the kinds of information they can generate or consume.
+
+   Capability identification
+      Provision of information by the a receiving agent that indicates
+      the kinds of message data that it can accept for presentation to a
+      user.
+
+   Content negotiation
+      An exchange of information (negotiation metadata) which leads to
+      selection of the appropriate representation (variant) when
+      transferring a data resource.
+
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 4]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Message transaction
+
+      A sequence of exchanges between a message sender and receiver that
+      accomplish the transfer of message data.
+
+   RFC 2703 [17] introduces several other terms related to content
+   negotiation.
+
+1.2.2 Design goals
+
+   In discussing the goals for content negotiation, {1}, {2}, {3}
+   notation is used, per RFC 2542, "Terminology and Goals for Internet
+   Fax" [3].  The meanings associated with these notations are:
+
+   {1}   there is general agreement that this is a critical
+         characteristic of any definition of content negotiation for
+         Internet Fax.
+
+   {2}   most believe that this is an important characteristic of
+         content negotiation for Internet Fax.
+
+   {3}   there is general belief that this is a useful feature of
+         content negotiation for Internet Fax, but that other factors
+         might override;  a definition that does not provide this
+         element is acceptable.
+
+1.2.3 Other document conventions
+
+   NOTE:  Comments like this provide additional nonessential information
+   about the rationale behind this document.  Such information is not
+   needed for building a conformant implementation, but may help those
+   who wish to understand the design in greater depth.
+
+2. Background and goals
+
+2.1 Background
+
+2.1.1 Fax and email
+
+   One of the goals of the work to define a facsimile service using
+   Internet mail has been to deliver benefits of the traditional Group 3
+   Fax service in an email environment.  Traditional Group 3 Fax leans
+   heavily on the idea that an online exchange of information discloses
+   a receiver's capabilities to the sender before any message data is
+   transmitted.
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 5]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   By contrast, Internet mail has been developed to operate in a
+   different fashion, without any expectation that the sender and
+   receiver will exchange information prior to message transfer.  One
+   consequence of this is that all mail messages must contain some kind
+   of meaningful message data:  messages that are sent simply to elicit
+   information from a receiving message handling agent are not generally
+   acceptable in the Internet mail environment.
+
+   To guarantee some level of interoperability, Group 3 Fax and Internet
+   mail rely on all receivers being able to deal with some baseline
+   format (i.e., a basic image format or plain ASCII text,
+   respectively).  The role of capability exchange or content
+   negotiation is to permit better-than baseline capabilities to be
+   employed where available.
+
+   One of the challenges addressed by this specification is how to adapt
+   the email environment to provide a fax-like service.  A sender must
+   not make any a priori assumption that the receiver can recognize
+   anything other than a simple email message.  There are some important
+   uses of email that are fundamentally incompatible with the fax model
+   of message passing and content negotiation (notably mailing lists).
+   So we need to have a way of recognizing when content negotiation is
+   possible, without breaking the existing email model.
+
+2.1.2 Current facilities in Internet Fax
+
+   "Extended Facsimile using Internet Mail" [1] provides for a limited
+   provision of receiver capability information to the sender of a
+   message, using an extension to Message Disposition Notifications
+   [2,4], employing media feature tags [5] and media feature expressions
+   [6].
+
+   This mechanism provides for receiver capabilities to be disclosed
+   after a message has been received and processed.  This information
+   can be used for subsequent transmissions to the same receiver.  But
+   many communications are one-off messages from a given sender to a
+   given receiver, and cannot benefit from this.
+
+2.2 Closing the loop
+
+   Classic Internet mail is an "open loop" process:  no information is
+   returned back to the point from which the message is sent.  This has
+   been unkindly --but accurately-- characterized as "send and pray",
+   since it lacks confirmation.
+
+   Sending a message and obtaining confirmation that the message has
+   been received is a "closed loop" process:  the confirmation sent back
+   to the sender creates a loop around which information is passed.
+
+
+
+Klyne, et. al.              Standards Track                     [Page 6]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Many Internet email agents are not designed to participate in a
+   closed loop process, and thus have no responsibility to respond to
+   receipt of a message.  Later additions to Internet standards, notably
+   Delivery Service Notification [18] and Message Disposition
+   Notification [4], specify means for certain confirmation responses to
+   be sent back to the sender, thereby closing the loop.  However
+   conformance to these enhancements is optional and full deployment is
+   in the future.
+
+   DSN must be fully implemented by the entire infrastructure; further
+   when support is lacking, the message is still sent on in open-loop
+   fashion.  Sometimes, transmission and delivery should instead be
+   aborted and the fact be reported to the sender.
+
+   Due to privacy considerations for end-users, MDN usage is entirely
+   voluntary.
+
+   Content negotiation is a closed loop function (for the purposes of
+   this proposal -- see section 2.3, item (f)), and requires that the
+   recipient of a message make some response to the sender.  Since
+   content negotiation must retro-fit a closed-loop function over
+   Internet mail's voluntary and high-latency environment, a challenge
+   for content negotiation in email is to establish that consenting
+   parties can recognize a closed loop situation, and hence recognize
+   their responsibilities to close the loop.
+
+   Three different loops can be identified in a content negotiation:
+
+              Sender                      Receiver
+                |                             |
+         Initial message ------>------------  v
+                |                             |
+               (1) ------------<--- Request alternative data
+                |                             |
+        Send alternative ------>------------ (2)
+                |                             |
+               (3) ------------<------ Confirm receipt
+                                       of usable data
+
+   (1)   Sender receives acknowledgement that negotiable content has
+         been received
+
+   (2)   Receiver receives confirmation that its request for data has
+         been received.
+
+   (3)   Sender receives confirmation that received data is processable,
+         or has been processed.
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 7]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Although the content negotiation process is initiated by the sender,
+   it is not established until loop (1) is closed with an indication
+   that the receiver desires alternative content.
+
+   If content sent with the original message from the sender is
+   processable by the receiver, and a confirmation is sent, then the
+   entire process is reduced to a simple send/confirm loop:
+
+                  Sender                      Receiver
+                    |                             |
+             Initial message ------>------------  v
+                    |                             |
+                   (3) ------------<------ Confirm receipt
+                                           of usable data
+
+2.3 Goals for content negotiation
+
+   The primary goal {1} is to provide a mechanism that allows arbitrary
+   enhanced content features to be used with Internet fax systems.  The
+   mechanism should {2} support introduction of new features over time,
+   particularly those that are adopted for Group 3 fax.
+
+   Further goals are:
+
+   (a)   Must {1} interwork with existing simple mode Internet fax
+         systems.
+
+   (b)   Must {1} interwork with existing email clients.
+
+         The term "interwork" used above means that the mechanism must
+         be introduced in a way that may be ignored by existing systems,
+         and systems enhanced to use the negotiation mechanisms will
+         behave in a fashion that is expected by existing systems.
+         (I.e., existing clients are not expected in any way to
+         participate in or be aware of content negotiation.)
+
+   (c)   Must {1} avoid transmission of "administrative non messages".
+         (I.e., only messages that contain meaningful content for the
+         end user may be sent unless it is known that the receiving
+         system will interpret them, and not attempt to display them.)
+         This requirement has been stated very strongly by the email
+         community.
+
+         This means that a sender must not assume that a receiver can
+         understand the capability exchange protocol elements, so must
+         always start by sending some meaningful message data.
+
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 8]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   (d)   Avoid {1} multiple renderings of a message.  In situations
+         where multiple versions of a message are transferred, the
+         receiver must be able to reliably decide on a single version to
+         be displayed.
+
+   (e)   Minimize {2} round trips needed to complete a transmission.
+         Ideally {3} every enhanced transmission will result in simply
+         sending data that the recipient can process, and receiving a
+         confirmation response.
+
+   (f)   The solution adopted should not {3} transmit multiple versions
+         of the same data.  In particular, it must not {1} rely on
+         routinely sending multiple instances of the same data in a
+         single message.
+
+         This does not prohibit sending multiple versions of the same
+         data, but it must not be a requirement to do so.  A sender may
+         choose to send multiple versions together (e.g., plain text and
+         some other format), but the capability exchange mechanism
+         selected must not depend on such behaviour.
+
+   (g)   The solution adopted should {2} be consistent with and
+         applicable to other Internet email based applications; e.g.,
+         regular email, voice messaging, unified messaging, etc.
+
+   (h)   Allow for a graceful recovery from stale cache information.  A
+         sender might use historic information to send non-baseline data
+         with an initial message.  If this turns out to be unusable by
+         the recipient, it should still be possible {3} for the baseline
+         data, or some other acceptable format, to be selected and
+         transferred.
+
+   (i)   The mechanism defined should {2} operate cleanly in conjunction
+         with the mechanisms already defined for extended mode Internet
+         fax (extended DSN and MDN [2], etc.).
+
+   (j)   As much as possible, existing email mechanisms should {3} be
+         used rather than inventing new ones.  (It is clear that some
+         new mechanisms will be needed, but they should be defined
+         cautiously.)
+
+   (k)   The mechanism should {2} be implementable in low memory
+         devices.  That is, it should not depend on any party being able
+         to buffer arbitrary amounts of message data.
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                     [Page 9]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+         (It may not be possible to completely satisfy this goal in a
+         sending system.  But if the sender does not have enough memory
+         to buffer some given message, it can choose to not offer
+         content negotiation.)
+
+3. Framework for content negotiation
+
+   This section starts with an outline of the negotiation process, and
+   provides greater detail about each stage in following sub-sections.
+
+   1. Sender sends initial message data with an indication of
+      alternative formats available (section 3.1).  Initial data MAY be
+      a baseline or some other guess of what the recipient can handle.
+
+   2. The receiver has three main options:
+
+      (a)   Does not recognize the optional alternative formats, and
+            passively accepts the data as sent (section 3.2.1).
+
+      (b)   Does recognize the alternatives offered, and actively
+            accepts the data as sent (section 3.2.2).
+
+      (c)   Recognizes the alternatives offered, and determines that it
+            prefers to receive an alternative format.  An MDN response
+            is sent (i) indicating that the original data was not
+            processed, and (ii) containing receiver capability
+            information so that the sender may select a suitable
+            alternative (section 3.2.3).
+
+            Note that only recipients named in 'to:', 'cc:' or 'bcc:'
+            headers in the original message may request alternative data
+            formats in this way.  Recipients not named in the original
+            message headers MUST NOT attempt to initiate content
+            negotiation.
+
+            NOTE: the prohibition on initiation of negotiation by
+            recipients other than those explicitly addressed is to avoid
+            the sender from having to deal with negotiation requests
+            from unexpected parties.
+
+   3. On receipt of an MDN response indicating preference for an
+      alternative data format, the sender MUST select and transmit
+      message data matched to the receiver's declared capabilities, or
+      send an indication that the receiver's request cannot be honoured.
+      When sending alternative data, the sender suppresses the
+      indication that alternative data is available, so the negotiation
+      process cannot loop.
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 10]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   4. On receipt of final data from the sender, the receiver sends an
+      MDN response indicating acceptance (or otherwise) of the data
+      received.
+
+         NOTE:  the receiver does not choose the particular data format
+         to be received;  that choice rests with the sender.  We find
+         that this approach is simpler than having the receiver choose
+         an alternative, because it builds upon existing mechanisms in
+         email, and follows the same pattern as a traditional Group 3
+         fax.  Further, it deals with situations where the range of
+         alternatives may be difficult to describe.
+
+         This approach is similar to server driven negotiation in HTTP
+         using "Accept" headers [13].  This is distinct to the agent-
+         driven style of negotiation provided for HTTP as part of
+         Transparent Content Negotiation [14], or which might be
+         constructed in email using "multipart/alternative" and
+         "message/external-body" MIME types [15].
+
+3.1 Send data with an indication of alternatives
+
+   A sender that is prepared to provide alternative message data formats
+   MUST send the following message elements:
+
+   (a)   a default message data format,
+
+   (b)   message identification, in the form of a Message-ID header.
+
+   (c)   appropriate 'Content-features' header(s) [7] describing the
+         default message data sent,
+
+   (d)   a request for Message Disposition Notification [4],
+
+   (e)   an indication that it is prepared to send different message
+         data, using an 'Alternative-available' MDN option field [9],
+         and
+
+   (f)   an indication of the alternative data formats available, in the
+         form of 'Content-alternative' header(s) [8].  Note:  more than
+         one Content-alternative' header MAY be specified; see section
+         3.1.3 for more information.
+
+   Having indicated the availability of alternative data formats, the
+   sender is expected to hold the necessary information for some time,
+   allowing the receiver an opportunity to request such data.  But,
+   unless it so indicates (see [9]), the sender is not expected to hold
+   this information indefinitely;  the exact length of time such
+   information should be held is not specified here.  Thus, the
+
+
+
+Klyne, et. al.              Standards Track                    [Page 11]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   possibility exists that a request for alternative information may
+   arrive too late, and the sender will then send an indication that the
+   data is no longer available.  If message transference is being
+   completed within a predetermined time interval (e.g., using [21]),
+   then the sender should normally maintain the data for at least that
+   period.
+
+3.1.1 Choice of default data format
+
+   The normal default format is text/plain.  This is the format sent
+   unless the sender has prior knowledge or expectation of other content
+   formats supported by the recipient.  Some uses of email presume some
+   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".
+
+
+
+
+
+
+
+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
+   MH image compression.
+
+   Sender's initial message:
+
+      Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Content Negotiation
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      Disposition-Notification-Options:
+          Alternative-available=optional,permanent
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615765/ example.com"
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 23]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+      --RAA14128.773615765/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+      Content-features:
+          (& (color=Binary)
+             (image-file-structure=TIFF-minimal)
+             (dpi=200)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MH)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+      Content-alternative:
+          (& (color=Binary)
+             (image-file-structure=TIFF-limited)
+             (dpi=400)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MMR)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+
+      [TIFF-FX Profile-S message goes here]
+
+      --RAA14128.773615765/ example.com--
+
+   Receiver sends MDN response to initial message:
+
+      Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200020.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Content Negotiation
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615766/example.org"
+
+      --RAA14128.773615766/example.org
+
+      The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
+      Tom Recipient <Tom_Recipient@example.org> with subject "Internet
+      FAX Full Mode Content Negotiation" has been received.  An
+      alternative form of the message data is requested.
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 24]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+      --RAA14128.773615766/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200019.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically;
+                   deleted/alternative-preferred
+      Media-Accept-Features:
+          (& (type="image/tiff")
+             (color=Binary)
+             (image-file-structure=TIFF)
+             (| (& (dpi=200) (dpi-xyratio=200/100) )
+                (& (dpi=200) (dpi-xyratio=1) )
+                (& (dpi=400) (dpi-xyratio=1) ) )
+             (| (image-coding=[MH,MR,MMR])
+                (& (image-coding=JBIG)
+                   (image-coding-constraint=JBIG-T85)
+                   (JBIG-stripe-size=128) ) )
+             (MRC-mode=0)
+             (paper-size=[A4,B4])
+             (ua-media=stationery) )
+
+      --RAA14128.773615766/example.org--
+
+   Sender's message with enhanced content:
+
+      Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200021.12345@example.com>
+      Original-Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Image Transmission
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615768/ example.com"
+
+      --RAA14128.773615768/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+
+      [TIFF-FX profile-F message goes here]
+
+      --RAA14128.773615768/ example.com--
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 25]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Receiver sends MDN confirmation of enhanced message content:
+
+      Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200022.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Image Transmission
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615769/example.org"
+
+      --RAA14128.773615769/example.org
+
+      The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
+      Recipient <Tom_Recipient@example.org> with subject " Internet FAX
+      Full Mode Image Transmission" has been processed in Internet FAX
+      Full Mode.
+
+      --RAA14128.773615769/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200021.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically; processed
+      Media-Accept-Features:
+          (& (type="image/tiff")
+             (color=Binary)
+             (image-file-structure=TIFF)
+             (| (& (dpi=200) (dpi-xyratio=200/100) )
+                (& (dpi=200) (dpi-xyratio=1) )
+                (& (dpi=400) (dpi-xyratio=1) ) )
+             (| (image-coding=[MH,MR,MMR])
+                (& (image-coding=JBIG)
+                   (image-coding-constraint=JBIG-T85)
+                   (JBIG-stripe-size=128) ) )
+             (MRC-mode=0)
+             (paper-size=[A4,B4])
+             (ua-media=stationery) )
+
+      --RAA14128.773615769/example.org--
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 26]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+8.2 Internet fax with initial data usable
+
+   This example shows how the second and subsequent transfers between
+   the systems in the previous example might be conducted.  Using
+   knowledge gained from the previous exchange, the sender includes
+   profile-F data with its first contact.
+
+   Sender's initial message:
+
+      Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Content Negotiation
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      Disposition-Notification-Options:
+          Alternative-available=optional,permanent
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615765/ example.com"
+
+      --RAA14128.773615765/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+      Content-features:
+          (& (color=Binary)
+             (image-file-structure=TIFF-limited)
+             (dpi=400)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MMR)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+      Content-alternative:
+          (& (color=Binary)
+             (image-file-structure=TIFF-minimal)
+             (dpi=200)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MH)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+
+      [TIFF-FX Profile-F message goes here]
+
+      --RAA14128.773615765/ example.com--
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 27]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Receiver sends MDN confirmation of received message content:
+
+      Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200022.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Image Transmission
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615769/example.org"
+
+      --RAA14128.773615769/example.org
+
+      The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom
+      Recipient <Tom_Recipient@example.org> with subject "Internet FAX
+      Full Mode Image Transmission" has been processed in Internet FAX
+      Full Mode.
+
+      --RAA14128.773615769/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200021.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically; processed
+      Media-Accept-Features:
+          (& (type="image/tiff")
+             (color=Binary)
+             (image-file-structure=TIFF)
+             (| (& (dpi=200) (dpi-xyratio=200/100) )
+                (& (dpi=200) (dpi-xyratio=1) )
+                (& (dpi=400) (dpi-xyratio=1) ) )
+             (| (image-coding=[MH,MR,MMR])
+                (& (image-coding=JBIG)
+                   (image-coding-constraint=JBIG-T85)
+                   (JBIG-stripe-size=128) ) )
+             (MRC-mode=0)
+             (paper-size=[A4,B4])
+             (ua-media=stationery) )
+
+      --RAA14128.773615769/example.org--
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 28]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+8.3 Negotiate to lower receiver capability
+
+   In this example, the sender has incorrectly assumed that the receiver
+   has a higher capability, and must re-send lower capability data in
+   response to the receiver's response showing lesser capability.
+
+   An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image.  When
+   the receiver cannot handle this, it falls back to baseline profile-S.
+   As this is a baseline format, it is not necessary to declare that
+   capability with the original message.  When a receiver is faced with
+   data it cannot process from a negotiating sender, it can do no better
+   than to respond with a description of its actual capabilities and let
+   the sender determine the outcome.
+
+   Sender's initial message:
+
+      Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Negotiate Down
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      Disposition-Notification-Options:
+          Alternative-available=optional,permanent
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615765/ example.com"
+
+      --RAA14128.773615765/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+      Content-features:
+          (& (color=Binary)
+             (image-file-structure=TIFF-limited)
+             (dpi=400)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MMR)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+
+      [TIFF-FX Profile-F message goes here]
+
+      --RAA14128.773615765/ example.com--
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 29]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Receiver sends MDN response to initial message:
+
+      Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200020.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Negotiate Down
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615766/example.org"
+
+      --RAA14128.773615766/example.org
+
+      The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
+      Tom Recipient <Tom_Recipient@example.org> with subject "Internet
+      FAX Full Mode Content Negotiation" has been received.  An
+      alternative form of the message data is requested.
+
+      --RAA14128.773615766/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200019.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically;
+                   deleted/alternative-preferred
+      Media-Accept-Features:
+          (& (type="image/tiff")
+             (color=Binary)
+             (image-file-structure=TIFF-minimal)
+             (dpi=200)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MH)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+
+      --RAA14128.773615766/example.org--
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 30]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Sender's message with baseline content:
+
+      Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200021.12345@example.com>
+      Original-Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Image Transmission
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615768/ example.com"
+
+      --RAA14128.773615768/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+
+      [TIFF-FX profile-S message goes here]
+
+      --RAA14128.773615768/ example.com--
+
+   Receiver sends MDN confirmation of impoverished message content:
+
+      Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200022.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Image Transmission
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615769/example.org"
+
+      --RAA14128.773615769/example.org
+
+      The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
+      Recipient <Tom_Recipient@example.org> with subject " Internet FAX
+      Full Mode Image Transmission" has been processed in Internet FAX
+      Full Mode.
+
+      --RAA14128.773615769/example.org
+      Content-Type: message/disposition-notification
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 31]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200021.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically; processed
+      Media-Accept-Features:
+          (& (color=Binary)
+             (image-file-structure=TIFF-minimal)
+             (dpi=200)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MH)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+
+      --RAA14128.773615769/example.org--
+
+8.4 Sending an alternative content type
+
+   As noted in section 4, the sender can offer the data using a
+   different MIME content-type.  This example shows a profile-F (A4,
+   400x400dpi, MMR) image and a limited-colour PDF document offered as
+   alternatives to a baseline image/TIFF.
+
+   Sender's initial message:
+
+        (Note that the MIME content type is not specified for the
+        image/tiff alternative, being the same as that provided, but
+        is mentioned for the application/pdf alternative.)
+
+      Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Content Negotiation
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      Disposition-Notification-Options:
+          Alternative-available=optional,permanent
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615765/ example.com"
+
+      --RAA14128.773615765/ example.com
+      Content-type: image/tiff
+      Content-Transfer-Encoding: base64
+      Content-features:
+          (& (color=Binary)
+             (image-file-structure=TIFF-minimal)
+
+
+
+Klyne, et. al.              Standards Track                    [Page 32]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+             (dpi=200)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MH)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+      Content-alternative:
+          (& (color=Binary)
+             (image-file-structure=TIFF-limited)
+             (dpi=400)
+             (dpi-xyratio=1)
+             (paper-size=A4)
+             (image-coding=MMR)
+             (MRC-mode=0)
+             (ua-media=stationery) )
+      Content-alternative:
+          (& (type="application/pdf")
+             (color=Limited)
+             (dpi=400)
+             (paper-size=A4)
+             (ua-media=stationery) )
+
+      [TIFF-FX Profile-S message goes here]
+
+      --RAA14128.773615765/ example.com--
+
+   Receiver sends MDN response to initial message:
+
+        (Note that this response indicates an ability to handle the
+        PDF MIME content-types, but with only binary colour.)
+
+      Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200020.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Content Negotiation
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615766/example.org"
+
+      --RAA14128.773615766/example.org
+
+      The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
+      Tom Recipient <Tom_Recipient@example.org> with subject "Internet
+      FAX Full Mode Content Negotiation" has been received.  An
+      alternative form of the message data is requested.
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 33]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+      --RAA14128.773615766/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200019.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically;
+                   deleted/alternative-preferred
+      Media-Accept-Features:
+          (| (& (type="image/tiff")
+                (color=Binary)
+                (image-file-structure=TIFF-minimal)
+                (dpi=200)
+                (dpi-xyratio=1)
+                (image-coding=MH)
+                (MRC-mode=0)
+                (paper-size=A4)
+                (ua-media=stationery) )
+             (& (type="application/pdf")
+                (color=Binary)
+                (dpi-xyratio=1)
+                (dpi=[200,400])
+                (paper-size=[A4,B4])
+                (ua-media=stationery) ) )
+
+      --RAA14128.773615766/example.org--
+
+   Resend with alternative content-type:
+
+      Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
+      From: Jane Sender <Jane_Sender@example.com>
+      Message-Id: <199509200021.12345@example.com>
+      Original-Message-Id: <199509200019.12345@example.com>
+      Subject: Internet FAX Full Mode Image Transmission
+      To: Tom Recipient <Tom_Recipient@example.org>
+      Disposition-Notification-To: Jane_Sender@example.com
+      MIME-Version: 1.0
+      Content-Type: multipart/mixed;
+                    boundary="RAA14128.773615768/ example.com"
+
+      --RAA14128.773615768/ example.com
+      Content-type: application/pdf
+      Content-Transfer-Encoding: base64
+
+      [PDF data goes here]
+
+      --RAA14128.773615768/ example.com--
+
+
+
+Klyne, et. al.              Standards Track                    [Page 34]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   Receiver sends MDN confirmation of enhanced message content:
+
+        (Also indicating the PDF capability for future messages.)
+
+      Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
+      From: Tom Recipient <Tom_Recipient@example.org>
+      Message-Id: <199509200022.12345@example.org>
+      Subject: Re: Internet FAX Full Mode Image Transmission
+      To: Jane Sender <Jane_Sender@example.com>
+      MIME-Version: 1.0
+      Content-Type: multipart/report;
+                    report-type=disposition-notification;
+                    boundary="RAA14128.773615769/example.org"
+
+      --RAA14128.773615769/example.org
+
+      The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
+      Recipient <Tom_Recipient@example.org> with subject " Internet FAX
+      Full Mode Image Transmission" has been processed in Internet FAX
+      Full Mode.
+
+      --RAA14128.773615769/example.org
+      Content-Type: message/disposition-notification
+
+      Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
+      Original-Recipient: rfc822;Tom-Recipient@example.org
+      Final-Recipient: rfc822;Tom-Recipient@example.org
+      Original-Message-ID: <199509200021.12345@example.com>
+      Disposition: automatic-action/MDN-sent-automatically; processed
+      Media-Accept-Features:
+          (| (& (type="image/tiff")
+                (color=Binary)
+                (image-file-structure=TIFF-minimal)
+                (dpi=200)
+                (dpi-xyratio=1)
+                (image-coding=MH)
+                (MRC-mode=0)
+                (paper-size=A4)
+                (ua-media=stationery) )
+             (& (type="application/pdf")
+                (color=Binary)
+                (dpi-xyratio=1)
+                (dpi=[200,400])
+                (paper-size=[A4,B4])
+                (ua-media=stationery) ) )
+
+      --RAA14128.773615769/example.org--
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 35]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+9. IANA Considerations
+
+9.1 New message headers
+
+   This specification defines new email/MIME message headers:
+
+      Content-alternative
+      Original-Message-ID
+
+   As such, there being no registry of email headers, it is an update to
+   the specifications of RFC 2822 and RFC 2045.
+
+9.2 MDN extensions
+
+   This specification defines extensions to the Message Disposition
+   Notification (MDN) protocol.  The sections below are the registration
+   templates for these extensions, as required by RFC 2298 [4], section
+   10.
+
+9.2.1 Notification option 'Alternative-available'
+
+   (a)   Disposition-notification-option name:
+         Alternative-available
+
+   (b)   Syntax:
+         (see this document, section 6.1)
+
+   (c)   Character-encoding:
+         US-ASCII characters only are used
+
+   (d)   Semantics:
+         (see this document, section 6.1)
+
+9.2.2 Notification option 'Alternative-not-available'
+
+   (a)   Disposition-notification-option name:
+         Alternative-not-available
+
+   (b)   Syntax:
+         (see this document, section 6.1)
+
+   (c)   Character-encoding:
+         US-ASCII characters only are used
+
+   (d)   Semantics
+         (see this document, section 6.3)
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 36]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+9.2.3 Disposition modifier 'Alternative-preferred'
+
+   (a)   Disposition-modifier name:
+         Alternative-preferred
+
+   (b)   Semantics:
+         (see this document, section 6.2)
+
+9.2.4 Disposition modifier 'Original-lost'
+
+   (a)   Disposition-modifier name:
+         Original-lost
+
+   (b)   Semantics:
+         (see this document, section 6.4)
+
+10.  Internationalization considerations
+
+   This specification deals with protocol exchanges between mail user
+   agents, and as such does not deal primarily with human readable text.
+   But not all user agents may automatically handle the protocol
+   elements defined here, and may attempt to display text from the
+   protocol elements to the user.
+
+   The main candidate for this treatment is the text accompanying a
+   disposition notification response that requests alternative
+   information.  In normal use, the protocol design ensures that the
+   recipient can process this response automatically; exceptionally, a
+   receiving agent may display it to a user.
+
+11.  Security Considerations
+
+   Security considerations of this specification can be divided into two
+   main areas:
+
+   o  Privacy concerns with automated MDN response generation:  see
+      section 6.5 of this document, and the security considerations
+      section of RFC 2298 [4].
+
+   o  Risks of negotiation:  see the security considerations section
+      transaction.  If alternative data arrives subsequently, it may be
+      ignored or possibly also displayed or printed.  A successful
+      completion MDN may be sent to the sender.
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 37]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+12.  Acknowledgements
+
+   The basic structure of the negotiation described here was first
+   documented in a draft by Mr. Toru Maeda of Canon.
+
+   Helpful comments on earlier drafts were provided by Mr Hiroshi
+   Tamura, Ted Hardie and Larry Masinter.
+
+13.  References
+
+   [1]   Masinter, L. and D. Wing, "Extended Facsimile using Internet
+         Mail", RFC 2532, March 1999.
+
+   [2]   Wing, D., "Indicating Supported Media Features Using Extensions
+         to DSN and MDN", RFC 2530, March 1999.
+
+   [3]   Masinter, L., "Terminology and Goals for Internet Fax", RFC
+         2542, March 1999.
+
+   [4]   Fajman, R., "An Extensible Message Format for Message
+         Disposition Notifications", RFC 2298, March 1998.
+
+   [5]   Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
+         Registration Procedure", RFC 2506, March 1999.
+
+   [6]   Klyne, G., "A syntax for describing media feature sets", BCP
+         31, RFC 2533, March 1999.
+
+   [7]   Klyne, G., "Indicating media features for MIME content", RFC
+         2938, September 2000.
+
+   [8]  'Content-alternative' header (this memo, section 4)
+
+   [9]   MDN extension for alternative data (this memo, section 6)
+
+   [10]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", RFC 2234, November 1997.
+
+   [11]  McIntyre, L.,  Buckley, R., Venable, D., Zilles, S., Parsons,
+         G. and J. Rafferty, "File format for Internet fax", RFC 2301,
+         March 1998.
+
+   [12]  Toyoda K., Ohno H., Murai, J. and D. Wing, "A Simple Mode of
+         Facsimile Using Internet Mail", RFC 2305, March 1998.
+
+   [13]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+
+
+Klyne, et. al.              Standards Track                    [Page 38]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   [14]  Holtman, K. and A. Mutz, "Transparent Content Negotiation in
+         HTTP", RFC 2295, March 1998.
+
+   [15]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part 2: Media types", RFC 2046, November
+         1996.
+
+   [16]  Klyne, G. and L. McIntyre, "Content feature schema for Internet
+         fax V2", RFC 2879, August 2000.
+
+   [17]  Klyne, G., "Protocol-independent Content Negotiation
+         Framework", RFC 2703, September 1999.
+
+   [18]  Moore, K., "SMTP Service Extension for Delivery Status
+         Notifications", RFC 1891, January 1996.
+
+   [19]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+         2001.
+
+   [20]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [21]  Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using
+         Internet Mail", Work in Progress.
+
+   [22]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [23] 'Original-Message-ID' header for mail messages (this memo,
+         section 5)
+
+   [24]  Klyne, G., "MIME Content Types in Media Feature Expressions",
+         RFC 2913, September 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 39]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+Appendix A: Implementation issues
+
+   This section is not a normative part of this specification.  Rather,
+   it discusses some of the issues that were considered during its
+   design in a way that we hope will be useful to implementers.
+
+A.1 Receiver state
+
+   Probably the biggest implication for implementers of this proposal
+   compared with standard mail user agents is the need to maintain some
+   kind of state information at the receiver while content is being
+   negotiated.
+
+   By "receiver state", we mean that a receiver needs to remember that
+   it has received an initial message AND that it has requested an
+   alternative form of data.  Without this, when a receiver responds
+   with a request for an alternative data format there is a possibility
+   (if the response does not reach the sender) that the message will be
+   silently lost, despite its having been delivered to the receiving
+   MTA.
+
+   The matter of maintaining receiver state is particularly germane
+   because of the requirement to allow low-memory systems to participate
+   in the content negotiation.  Unlike traditional T.30 facsimile, where
+   the negotiation takes place within the duration of a single
+   connection, an extended time may be taken to complete a negotiation
+   in email.  State information must be maintained for all negotiations
+   outstanding at any time, and there is no theoretical upper bound on
+   how many there may be.
+
+   Keeping receiver state is probably not a problem for systems with
+   high capacity storage devices to hold message data and state
+   information.  The remainder of this section discusses strategies that
+   small-system designers might employ to place an upper bound on memory
+   that must be reserved for this information.  When a receiver is
+   really memory constrained then message loss remains a possibility,
+   but the mechanisms described here should ensure that it never happens
+   silently.
+
+   So what is this "receiver state"?  It must contain, as a minimum:
+
+   o  the fact that message data was received, and alternative data has
+      been requested,
+
+   o  a unique message identifier, and
+
+   o  the time at which an alternative format request was sent.
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 40]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   This allows the receiver to re-issue a request, or to report an
+   error, if requested alternative data does not arrive in a reasonable
+   time.
+
+   Receiver state may also include:
+
+   o  a copy of the data originally received.  This allows the receiver
+      to display the original data if an alternative is not received.
+
+   o  details of the data format supplied, and alternatives offered.
+      This permits improved diagnostics if alternative data is not
+      received.
+
+   If a receiver of a message with alternative content available does
+   not have enough memory to hold new negotiation state information, it
+   may fall back to non-negotiation behaviour, accept the data received
+   and send an MDN indicating disposition of that data (see sections
+   3.2.1, 3.2.2).
+
+   If a receiving system runs low on memory after entering into a
+   negotiation, a number of options may be possible:
+
+   o  display or print buffered data, if available, and complete the
+      transaction.  If alternative data arrives subsequently, it may be
+      ignored or possibly also displayed or printed.  A successful
+      completion MDN may be sent to the sender.
+
+   o  discard any buffered data, and continue waiting for alternative
+      data.  If alternative data does not subsequently arrive, a message
+      transfer failure should be declared.
+
+   o  abort the transfer and declare a message transfer failure:  a
+      diagnostic message must be displayed to the local user, and a
+      failure notification sent to the sender.
+
+A.2 Receiver buffering of message data
+
+   If a receiver is capable of buffering received message data while
+   waiting for an alternative, this is to be preferred because it
+   retains the option to display that data if an alternative is not
+   received (see above).
+
+   Partial message data should not be buffered for this purpose:
+   displaying part of the original message is not an allowable
+   substitute for displaying all of the received data.  (There may be
+   some value in keeping some of the original message data for
+   diagnostic purposes.)
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 41]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   If a receiver starts to buffer message data pending negotiation, then
+   finds that the entire message is too large to buffer, it may choose
+   to fall back to "extended mode" and display the incoming data as it
+   is received.
+
+   When a sender indicates availability of alternative data, it also
+   indicates whether it is permanently or transiently available.  The
+   intent of this is that if alternative data is transient, a receiver
+   should not discard original data received.  If necessary, it should
+   simply display the original data without requesting an alternative.
+
+A.3 Sender state
+
+   When a sender indicates that it can offer an alternative format of
+   message content, it accepts some responsibility for trying to ensure
+   that alternative is available if requested.  Thus, the message
+   content (both original and any alternative) should be stored for a
+   reasonable period, together with any corresponding Message-ID
+   value(s).
+
+   A request for retransmission must be accompanied by an Original-
+   Message-ID value that the sender can use to correlate with the
+   message data originally sent.
+
+A.4 Timeout of offer of alternatives
+
+   If the sender is operating with a high capacity message storage
+   device (e.g., a disk drive), and normally holds the data for extended
+   periods (several days or weeks) then it should indicate that the
+   alternative data is permanently available (see 6.1):  a recipient
+   seeing this may discard the original data, assuming that the sender
+   will most likely be able to re-transmit.
+
+   If the sender has limited memory capacity, and is likely to be able
+   to hold the data for no more than a few minutes or hours, it should
+   indicate that the alternative data is transiently available (see
+   6.1).  If there is doubt about a sender's ability to keep the message
+   content, it should indicate that availability of any alternative is
+   transient.
+
+A.5 Timeout of receiver capabilities
+
+   It should not be assumed that receiver capabilities declared during
+   negotiation are available indefinitely.
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 42]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+   In particular, any receiver capabilities declared on a final message
+   confirmation should be regarded as definitive, even if they differ
+   from the capabilities associated with the message just accepted.
+   These may be stored for future use.
+
+   Any receiver capabilities declared when requesting an alternative
+   format should not be stored for future use, as the receiver might be
+   selective about the purposes for which those capabilities may be
+   used.
+
+A.6 Relationship to timely delivery
+
+   Some of the issues of sender state maintenance may be simplified if
+   content negotiation is used in conjunction with a facility for timely
+   delivery (e.g., [21]).  If there is a known time window within which
+   a response should be received, the sender may be less conservative
+   about keeping information about outstanding offers of alternative
+   data for extended periods.  A sender that exploits timely delivery in
+   this way should indicate that the alternative is transiently
+   available.
+
+A.7 Ephemeral capabilities
+
+   Ephemeral capabilities may present some special problems.  Consider
+   the case of selection of a particular content variant that may depend
+   on an ephemeral setting.
+
+   Imagine someone sending a basic fax to a color fax machine,
+   indicating that a color alternative is available.  The color fax
+   discards the content and sends an MDN which says
+   "deleted/alternative-preferred" to the originator.  It then runs out
+   of colored ink.  The originating fax then sends a new message which
+   the colored fax cannot print.
+
+   Or consider an the email client in a phone with sound on/off as a
+   related problem.  When sound is ON, the phone may be able to accept
+   voice messages by email.
+
+   This negotiation framework has not been designed with ephemeral
+   capabilities in mind, but, with care, may be adaptable to deal with
+   them.
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 43]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+A.8 Situations where MDNs must not be auto-generated
+
+   Bearing in mind privacy concerns, implementers should be careful that
+   systems do not automatically enter into a negotiation exchange in a
+   way that may disclose the recipient's whereabouts without first
+   having obtained explicit permission.  For example, if receiving a
+   message depends in any way on the user's physical presence, automatic
+   negotiation should not be performed.
+
+   While it may be OK for an unattended fax machine to perform automated
+   negotiation, it is not OK for a PC software package to do so without
+   the users explicit permission as the PC may be switched on only when
+   the user is present.  This suggests that default settings in this
+   regard should take account of the type of system.
+
+Appendix B: Candidates for further enhancements
+
+   This appendix lists some possible features of content negotiation
+   that were considered, but not included in the current specification.
+   In most cases the reasons for exclusion were (a) that they could
+   introduce unanticipated additional complexities, and (b) no
+   compelling requirement was recognized.
+
+   o  Cache control indicator for recipient capabilities.  This would
+      instruct the sender, or other message system component, that
+      capability information in the current message is for the current
+      transaction only, and should NOT be remembered for future
+      transactions.  E.g., a recipient may not wish colour capability to
+      be used for routine communications.  (See also section A.5 above.)
+
+   o  Use of q-values [6] in media feature expressions for indicating
+      preference among alternatives available and/or receiver
+      preferences.
+
+   o  Partial re-sends.  There are proposals being developed for
+      "partial MDN" responses that can indicate disposition status on a
+      per-message-part basis.  This opens the possibility of partial
+      re-sends when alternative formats are requested for only some of
+      the message body parts.  The current specification assumes that
+      either none or all of message is re-sent when content negotiation
+      is used.
+
+   o  Allow negotiation with parties other than originally addressed
+      recipients of a message.
+
+   o  Negotiation response might indicate different receiver endpoint
+      with different capabilities.
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 44]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+Authors' Addresses
+
+   Graham Klyne (editor)
+   Clearswift Corporation,
+   1310 Waterside,
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom
+
+   Phone: +44 11 8903 8903
+   Fax:   +44 11 8903 9000
+   EMail: GK@ACM.ORG
+
+
+   Ryuji Iwazaki
+   TOSHIBA TEC CORPORATION
+   2-4-1, Shibakoen, Minato-ku,
+   Tokyo, 105-8524 Japan
+
+   Phone: +81 3 3438 6866
+   Fax:   +81 3 5402 6355
+   EMail:  iwa@rdl.toshibatec.co.jp
+
+
+   Dave Crocker
+   Brandenburg InternetWorking
+   675 Spruce Dr.
+   Sunnyvale, CA 94086 USA
+
+   Phone: +1 408 246 8253
+   Fax:   +1 408 249 6205
+   EMail: dcrocker@brandenburg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 45]
+
+RFC 3297      Content Negotiation for Messaging Services       July 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne, et. al.              Standards Track                    [Page 46]
+