path: root/doc/rfc/rfc3297.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L