[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 3297

IETF fax WG                  G. Klyne (editor), Baltimore Technologies
Internet draft                                 R. Iwazaki, Toshiba TEC
                                    D. Crocker, Brandenburg Consulting
                                                       29 January 2001
                                                    Expires: July 2001


         Content Negotiation for Internet Messaging Services
             <draft-ietf-fax-content-negotiation-04.txt>

Status of this memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC 2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-Drafts
  as reference material or to cite them other than as "work in
  progress".


     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


  To view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
  (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
  West Coast).

Copyright Notice

  Copyright (C) The Internet Society 2001.  All Rights Reserved.

Abstract

  This memo describes a content negotiation mechanism for facsimile,
  voice and other messaging services that use Internet e-mail.

  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 e-mail.







Klyne, Iwazaki, Crocker     Internet draft                    [Page 1]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


Discussion of this document

  Please send comments to:  <ietf-fax@imc.org>.

  To subscribe:  send a message with the body 'subscribe' to
  <ietf-fax-request@imc.org>.  The mailing list archive is at
  <http://www.imc.org/ietf-fax/>.


Table of contents

1. Introduction.............................................3
  1.1 Structure of this document ...........................4
  1.2 Document terminology and conventions .................5
     1.2.1 Terminology......................................5
     1.2.2 Design goals.....................................5
     1.2.3 Other document conventions.......................6
2. Background and goals.....................................6
  2.1 Background ...........................................6
     2.1.1 Fax and e-mail...................................6
     2.1.2 Current facilities in Internet Fax...............7
  2.2 Closing the loop .....................................7
  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..........................15
     3.2.3 Alternative preferred............................15
  3.3 Send alternative message data ........................17
  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 .....................21
  6.5 Automatic sending of MDN responses ...................22
7. Internet Fax Considerations..............................22
8. Examples.................................................22
  8.1 Sending enhanced Internet Fax image ..................22
  8.2 Internet fax with initial data usable ................26
  8.3 Negotiate to lower receiver capability ...............28
9. IANA Considerations......................................31
  9.1 New message headers ..................................31
  9.2 MDN extensions .......................................32





Klyne, Iwazaki, Crocker     Internet draft                    [Page 2]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     9.2.1 Notification option 'Alternative-available'......32
     9.2.2 Notification option 'Alternative-not-available'..32
     9.2.3 Disposition modifier 'Alternative-preferred'.....32
     9.2.4 Disposition modifier 'Original-lost'.............33
10. Internationalization considerations.....................33
11. Security considerations.................................33
12. Acknowledgements........................................33
13. References..............................................34
14. Authors' addresses......................................36
Appendix A: Implementation issues...........................37
  A.1 Receiver state .......................................37
  A.2 Receiver buffering of message data ...................38
  A.3 Sender state .........................................39
  A.4 Timeout of offer of alternatives .....................39
  A.5 Timeout of receiver capabilities .....................39
  A.6 Relationship to timely delivery ......................40
  A.7 Ephemeral capabilities ...............................40
  A.8 Situations where MDNs must not be auto-generated .....40
Appendix B: Candidates for further enhancements.............41
Appendix C: Amendment history...............................42
Full copyright statement....................................44


1. Introduction

  This memo describes a mechanism for e-mail based content
  negotiation to provide 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 e-mail protocols.  "Indicating
  Supported Media Features Using Extensions to DSN and MDN" [2]
  describes a mechanism for providing the sender with 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 e-mail (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.





Klyne, Iwazaki, Crocker     Internet draft                    [Page 3]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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 stored 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 replacing
  the message data originally transmitted.

  When the sender does not have 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.

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 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 conjunction with other content negotiation
  protocols.  This may be moved to a separate document.

  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].






Klyne, Iwazaki, Crocker     Internet draft                    [Page 4]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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.

  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.








Klyne, Iwazaki, Crocker     Internet draft                    [Page 5]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  [[[Editorial comments and questions about outstanding issues are
  provided in triple brackets like this.  These working comments
  should be resolved and removed prior to final publication.]]]


2. Background and goals

2.1 Background

2.1.1 Fax and e-mail

  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 e-mail 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.

  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 challenges addressed by this specification is how to adapt
  the e-mail 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 e-mail message.  There are
  some important uses of e-mail 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
  e-mail model.

2.1.2 Current facilities in Internet Fax

  "Extended Facsimile using Internet Mail" [1] provides for 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].





Klyne, Iwazaki, Crocker     Internet draft                    [Page 6]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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.

  Many Internet e-mail 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 makes 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 e-mail is to establish that consenting
  parties can recognize a closed loop situation, and hence their
  responsibilities to close the loop.












Klyne, Iwazaki, Crocker     Internet draft                    [Page 7]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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.

  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.











Klyne, Iwazaki, Crocker     Internet draft                    [Page 8]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Further goals are:

  (a)  Must {1} interwork with existing simple mode Internet fax
       systems.

  (b)  Must {1} interwork with existing e-mail 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 e-mail
       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.

  (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 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. TIFF-S 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 e-mail based applications;  e.g.
       regular e-mail, voice messaging, unified messaging, etc.






Klyne, Iwazaki, Crocker     Internet draft                    [Page 9]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  (h)  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 far as possible, existing e-mail 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 implement able in low memory
       devices.  That is, it should not depend on any party being
       able to buffer arbitrary amounts of message data.

       (It may be not 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 other best 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).






Klyne, Iwazaki, Crocker     Internet draft                   [Page 10]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


          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 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.

  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 e-mail, and follows
       the same pattern as 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 e-mail 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.







Klyne, Iwazaki, Crocker     Internet draft                   [Page 11]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  (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,
  to allow 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
  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 transfer 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

  Choice of the default format sent is essentially the same as that
  available to a simple mode Internet Fax sender per RFC 2305 [12].
  This essentially requires that TIFF Profile S [11] be sent unless
  the sender has prior knowledge of other TIFF fields or values
  supported by the recipient.

  "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].





Klyne, Iwazaki, Crocker     Internet draft                   [Page 12]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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.

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 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.

       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.









Klyne, Iwazaki, Crocker     Internet draft                   [Page 13]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


       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 might
       be used with some completely different content
       negotiation protocol that is nothing to do with e-mail 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.

  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 e-mail 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 e-mail 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.









Klyne, Iwazaki, Crocker     Internet draft                   [Page 14]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


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
  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.






Klyne, Iwazaki, Crocker     Internet draft                   [Page 15]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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

  (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 e-mail 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.







Klyne, Iwazaki, Crocker     Internet draft                   [Page 16]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


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.

  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.

  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 sender
  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.

  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.











Klyne, Iwazaki, Crocker     Internet draft                   [Page 17]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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".

  [[[Is this the correct final disposition value here?]]]


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.


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 822, section 4.6.1).









Klyne, Iwazaki, Crocker     Internet draft                   [Page 18]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  The syntax for this header is:

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

  where 'msg-id' is defined by RFC822 as:

     msg-id = "<" addr-spec ">"

  The 'msg-id' value given must be identical to that supplied in the
  Message-ID: header of the original message fir 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, Iwazaki, Crocker     Internet draft                   [Page 19]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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, Iwazaki, Crocker     Internet draft                   [Page 20]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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.

6.3 Indicating alternative data is no longer available

  A sender that receives a request for alternative data that is no
  longer available 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
  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] containg the value from the 'Message-ID:' header of the
  original message.

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 lack memory to store
  the original while waiting for an alternative to be sent, it sends
  a message disposition notification containing the following field:





Klyne, Iwazaki, Crocker     Internet draft                   [Page 21]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     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

  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 e-mail context,
  any valid media features MAY be used.


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.














Klyne, Iwazaki, Crocker     Internet draft                   [Page 22]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Sender's initial message:

     Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
     From: Jane Sender <Jane_Sender@huge.com>
     Message-Id: <199509200019.12345@huge.com>
     Subject: Internet FAX Full Mode Content Negotiation
     To: Tom Recipient <Tom_Recipient@mega.edu>
     Disposition-Notification-To: Jane_Sender@huge.com
     Disposition-Notification-Options:
         Alternative-available=optional,permanent
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="RAA14128.773615765/ huge.com"

     --RAA14128.773615765/ huge.com
     Content-type: image/tiff; application=faxbw
     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/ huge.com--
















Klyne, Iwazaki, Crocker     Internet draft                   [Page 23]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Receiver sends MDN response to initial message:

     Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
     From: Tom Recipient <Tom_Recipient@mega.edu>
     Message-Id: <199509200020.12345@mega.edu>
     Subject: Re: Internet FAX Full Mode Content Negotiation
     To: Jane Sender <Jane_Sender@huge.com>
     MIME-Version: 1.0
     Content-Type: multipart/report;
                   report-type=disposition-notification;
                   boundary="RAA14128.773615766/mega.edu"

     --RAA14128.773615766/mega.edu

     The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
     Tom Recipient <Tom_Recipient@mega.edu> with subject "Internet FAX
     Full Mode Content Negotiation" has been received.  An alternative
     form of the message data is requested.

     --RAA14128.773615766/mega.edu
     Content-Type: message/disposition-notification

     Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
     Original-Recipient: rfc822;Tom-Recipient@mega.edu
     Final-Recipient: rfc822;Tom-Recipient@mega.edu
     Original-Message-ID: <199509200019.12345@huge.com>
     Disposition: automatic-action/MDN-sent-automatically;
                  deleted/alternative-preferred
     Media-Accept-Features:
         (& (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/mega.edu--












Klyne, Iwazaki, Crocker     Internet draft                   [Page 24]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Sender's message with enhanced content:

     Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
     From: Jane Sender <Jane_Sender@huge.com>
     Message-Id: <199509200021.12345@huge.com>
     Original-Message-Id: <199509200019.12345@huge.com>
     Subject: Internet FAX Full Mode Image Transmission
     To: Tom Recipient <Tom_Recipient@mega.edu>
     Disposition-Notification-To: Jane_Sender@huge.com
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="RAA14128.773615768/ huge.com"

     --RAA14128.773615768/ huge.com
     Content-type: image/tiff; application=faxbw
     Content-Transfer-Encoding: base64

     [TIFF-FX profile-F message goes here]

     --RAA14128.773615768/ huge.com--

  Receiver sends MDN confirmation of enhanced message content:

     Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
     From: Tom Recipient <Tom_Recipient@mega.edu>
     Message-Id: <199509200022.12345@mega.edu>
     Subject: Re: Internet FAX Full Mode Image Transmission
     To: Jane Sender <Jane_Sender@huge.com>
     MIME-Version: 1.0
     Content-Type: multipart/report;
                   report-type=disposition-notification;
                   boundary="RAA14128.773615769/mega.edu"

     --RAA14128.773615769/mega.edu

     The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
     Recipient <Tom_Recipient@mega.edu> with subject " Internet FAX
     Full Mode Image Transmission" has been processed in Internet FAX
     Full Mode.

     --RAA14128.773615769/mega.edu
     Content-Type: message/disposition-notification













Klyne, Iwazaki, Crocker     Internet draft                   [Page 25]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
     Original-Recipient: rfc822;Tom-Recipient@mega.edu
     Final-Recipient: rfc822;Tom-Recipient@mega.edu
     Original-Message-ID: <199509200021.12345@huge.com>
     Disposition: automatic-action/MDN-sent-automatically; processed
     Media-Accept-Features:
         (& (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/mega.edu--

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@huge.com>
     Message-Id: <199509200019.12345@huge.com>
     Subject: Internet FAX Full Mode Content Negotiation
     To: Tom Recipient <Tom_Recipient@mega.edu>
     Disposition-Notification-To: Jane_Sender@huge.com
     Disposition-Notification-Options:
         Alternative-available=optional,permanent
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="RAA14128.773615765/ huge.com"














Klyne, Iwazaki, Crocker     Internet draft                   [Page 26]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     --RAA14128.773615765/ huge.com
     Content-type: image/tiff; application=faxbw
     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/ huge.com--

  Receiver sends MDN confirmation of received message content:

     Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
     From: Tom Recipient <Tom_Recipient@mega.edu>
     Message-Id: <199509200022.12345@mega.edu>
     Subject: Re: Internet FAX Full Mode Image Transmission
     To: Jane Sender <Jane_Sender@huge.com>
     MIME-Version: 1.0
     Content-Type: multipart/report;
                   report-type=disposition-notification;
                   boundary="RAA14128.773615769/mega.edu"

     --RAA14128.773615769/mega.edu

     The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom
     Recipient <Tom_Recipient@mega.edu> with subject "Internet FAX
     Full Mode Image Transmission" has been processed in Internet FAX
     Full Mode.

     --RAA14128.773615769/mega.edu
     Content-Type: message/disposition-notification








Klyne, Iwazaki, Crocker     Internet draft                   [Page 27]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
     Original-Recipient: rfc822;Tom-Recipient@mega.edu
     Final-Recipient: rfc822;Tom-Recipient@mega.edu
     Original-Message-ID: <199509200021.12345@huge.com>
     Disposition: automatic-action/MDN-sent-automatically; processed
     Media-Accept-Features:
         (& (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/mega.edu--

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 the the receiver's response showing lesser
  capability.

  An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image.
  When the receiver cannpot 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.

  [[[... or is it???  Should we cater for a sending system that can
  negotiate, but does not have capability to send fax baseline
  capability?  I.e. is it reasonable for a receiving system to simply
  assume that the sender can offer a baseline alternative?]]]


















Klyne, Iwazaki, Crocker     Internet draft                   [Page 28]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Sender's initial message:

     Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
     From: Jane Sender <Jane_Sender@huge.com>
     Message-Id: <199509200019.12345@huge.com>
     Subject: Internet FAX Full Mode Negotiate Down
     To: Tom Recipient <Tom_Recipient@mega.edu>
     Disposition-Notification-To: Jane_Sender@huge.com
     Disposition-Notification-Options:
         Alternative-available=optional,permanent
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="RAA14128.773615765/ huge.com"

     --RAA14128.773615765/ huge.com
     Content-type: image/tiff; application=faxbw
     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/ huge.com--

  Receiver sends MDN response to initial message:

     Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
     From: Tom Recipient <Tom_Recipient@mega.edu>
     Message-Id: <199509200020.12345@mega.edu>
     Subject: Re: Internet FAX Full Mode Negotiate Down
     To: Jane Sender <Jane_Sender@huge.com>
     MIME-Version: 1.0
     Content-Type: multipart/report;
                   report-type=disposition-notification;
                   boundary="RAA14128.773615766/mega.edu"

     --RAA14128.773615766/mega.edu

     The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
     Tom Recipient <Tom_Recipient@mega.edu> with subject "Internet FAX
     Full Mode Content Negotiation" has been received.  An alternative
     form of the message data is requested.






Klyne, Iwazaki, Crocker     Internet draft                   [Page 29]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


     --RAA14128.773615766/mega.edu
     Content-Type: message/disposition-notification

     Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
     Original-Recipient: rfc822;Tom-Recipient@mega.edu
     Final-Recipient: rfc822;Tom-Recipient@mega.edu
     Original-Message-ID: <199509200019.12345@huge.com>
     Disposition: automatic-action/MDN-sent-automatically;
                  deleted/alternative-preferred
     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.773615766/mega.edu--

  Sender's message with baseline content:

     Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
     From: Jane Sender <Jane_Sender@huge.com>
     Message-Id: <199509200021.12345@huge.com>
     Original-Message-Id: <199509200019.12345@huge.com>
     Subject: Internet FAX Full Mode Image Transmission
     To: Tom Recipient <Tom_Recipient@mega.edu>
     Disposition-Notification-To: Jane_Sender@huge.com
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="RAA14128.773615768/ huge.com"

     --RAA14128.773615768/ huge.com
     Content-type: image/tiff; application=faxbw
     Content-Transfer-Encoding: base64

     [TIFF-FX profile-S message goes here]

     --RAA14128.773615768/ huge.com--














Klyne, Iwazaki, Crocker     Internet draft                   [Page 30]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  Receiver sends MDN confirmation of impoverished message content:

     Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
     From: Tom Recipient <Tom_Recipient@mega.edu>
     Message-Id: <199509200022.12345@mega.edu>
     Subject: Re: Internet FAX Full Mode Image Transmission
     To: Jane Sender <Jane_Sender@huge.com>
     MIME-Version: 1.0
     Content-Type: multipart/report;
                   report-type=disposition-notification;
                   boundary="RAA14128.773615769/mega.edu"

     --RAA14128.773615769/mega.edu

     The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
     Recipient <Tom_Recipient@mega.edu> with subject " Internet FAX
     Full Mode Image Transmission" has been processed in Internet FAX
     Full Mode.

     --RAA14128.773615769/mega.edu
     Content-Type: message/disposition-notification

     Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
     Original-Recipient: rfc822;Tom-Recipient@mega.edu
     Final-Recipient: rfc822;Tom-Recipient@mega.edu
     Original-Message-ID: <199509200021.12345@huge.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/mega.edu--


9. IANA Considerations

9.1 New message headers

  This specification defines new email/MIME message headers:

     Content-alternative
     Original-Message-ID







Klyne, Iwazaki, Crocker     Internet draft                   [Page 31]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  As such, there being no registry of email headers, it is an update
  to the specifications of RFC822 and RFC2045.

  [[[How should this be handled, IANA-wise???]]]

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)

9.2.3 Disposition modifier 'Alternative-preferred'

  (a) Disposition-modifier name:
      Alternative-preferred

  (b) Semantics:
      (see this document, section 6.2)








Klyne, Iwazaki, Crocker     Internet draft                   [Page 32]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


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 humamn 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
      of RFC 2532 [1];  also of RFC 2703 [17], RFC 2506 [6] and RFC
      2533 [5].


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 and Ted Hardie.










Klyne, Iwazaki, Crocker     Internet draft                   [Page 33]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


13. References

[1]  RFC 2532, "Extended Facsimile using Internet Mail"
     L. Masinter, Xerox Corporation
     D. Wing, Cisco Systems
     March 1999.

[2]  RFC 2530, "Indicating Supported Media Features Using Extensions
     to DSN and MDN"
     D. Wing, Cisco Systems
     March 1999.

[3]  RFC 2542, "Terminology and Goals for Internet Fax"
     L. Masinter, Xerox Corporation
     March 1999.

[4]  RFC 2298, "An Extensible Message Format for Message Disposition
     Notifications"
     R. Fajman, National Institutes of Health
     March 1998.

[5]  RFC 2506, "Media Feature Tag Registration Procedure"
     Koen Holtman, TUE
     Andrew Mutz, Hewlett-Packard
     Ted Hardie, NASA
     March 1999.

[6]  RFC 2533, "A syntax for describing media feature sets"
     Graham Klyne, 5GM/Content Technologies
     March 1999.

[7]  "Indicating media features for MIME content"
     Graham Klyne, Content Technologies
     Internet draft: <draft-ietf-conneg-content-features-01.txt>
     Work in progress, April 1999.

[8]  'Content-alternative' header (this memo, section 4)

[9]  MDN extension for alternative data (this memo, section 6)

[10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF"
     D. Crocker (editor), Internet Mail Consortium
     P. Overell, Demon Internet Ltd.
     November 1997.











Klyne, Iwazaki, Crocker     Internet draft                   [Page 34]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


[11] RFC 2301, "File format for Internet fax"
     L. McIntyre,
     R. Buckley,
     D. Venable, Xerox Corporation
     S. Zilles, Adobe Systems, Inc.
     G. Parsons, Northern Telecom
     J. Rafferty, Human Communications
     March 1998.

[12] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
     K. Toyoda
     H. Ohno
     J. Murai, WIDE Project
     D. Wing, Cisco Systems
     March 1998.

[13] RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1"
     R. Fielding, UC Irvine
     J. Gettys, Compaq/W3C
     J. Mogul, Compaq
     H. Frystyk, W3C/MIT
     L. Masinter, Xerox
     P. Leach, Microsoft
     T. Berners-Lee, W3C/MIT
     June 1999.
     (Accept headers are described in section 14.1; section 12
     discusses content negotiation possibilities in HTTP.)

[14] RFC 2295, "Transparent Content Negotiation in HTTP"
     Koen Holtman, TUE
     Andrew Mutz, Hewlett Packard
     March 1998.

[15] RFC 2046, "Multipurpose Internet Mail Extensions (MIME)
     Part 2: Media types"
     N. Freed, Innosoft
     N. Borenstein, First Virtual
     November 1996.

[16] RFC 2531, "Content feature schema for Internet fax"
     Graham Klyne, 5GM/Content Technologies
     Lloyd McIntyre, Xerox Corporation
     March 1998.

[17] RFC 2703, "Protocol-independent Content Negotiation Framework"
     Graham Klyne, 5GM/Content Technologies
     September 1999.
     (This memo indicates terminology, framework and goals for content
     negotiation independent of any particular transfer protocol with
     which it may be deployed.)





Klyne, Iwazaki, Crocker     Internet draft                   [Page 35]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


[18] RFC 1891, "SMTP Service Extension for Delivery Status
     Notifications"
     K. Moore, University of Tennessee
     January 1996.

[19] RFC 821, "Simple Mail Transfer Protocol"
     Jonathan B. Postel, ISI/USC
     August 1982.

[20] RFC 822, "Standard for the Format of ARPA Internet Text Messages"
     David H. Crocker, University of Delaware
     August 1982.

[21] "Timely Delivery for Facsimile Using Internet Mail"
     Graham Klyne, Baltimore Technologies
     Internet draft: <draft-ietf-fax-timely-delivery-00.txt>
     Work in progress, October 1999.

[22] RFC 2119, "Key words for use in RFCs to Indicate Requirement
     Levels"
     S. Bradner, Harvard University
     March 1997.

[23] 'Original-Message-ID' header for mail messages (this memo,
     section 5)


14. Authors' addresses

  Graham Klyne (editor)
  Baltimore Technologies - Content Security Group,
  1220 Parkview,
  Arlington Business Park
  Theale
  Reading, RG7 4SA
  United Kingdom.
  Telephone: +44 118 930 1300
  Facsimile: +44 118 930 1301
  E-mail:    GK@ACM.ORG

  Ryuji Iwazaki
  TOSHIBA TEC CORPORATION
  2-4-1, Shibakoen, Minato-ku,
  Tokyo, 105-8524 Japan
  Tel:    +81 3 3438 6866
  Fax:    +81 3 3438 6861
  E-mail: iwa@rdl.toshibatec.co.jp

  D. Crocker
  Brandenburg Consulting





Klyne, Iwazaki, Crocker     Internet draft                   [Page 36]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  675 Spruce Dr.
  Sunnyvale, CA 94086 USA
  Phone:    +1 408 246 8253
  Fax:      +1 408 249 6205
  EMail:    dcrocker@brandenburg.com


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 e-mail.  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,





Klyne, Iwazaki, Crocker     Internet draft                   [Page 37]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  o  a unique message identifier, and

  o  the time at which an alternative format request was sent.

  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 prefered 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






Klyne, Iwazaki, Crocker     Internet draft                   [Page 38]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  some value in keeping some of the original message data for
  diagnostic purposes.)

  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
  receipient seing 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.

  In particular, any receiver capabilities declared on a final
  message confirmation should be regarded as definitive, even if they





Klyne, Iwazaki, Crocker     Internet draft                   [Page 39]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  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

  Ephemaral 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
  capabilties in mind, but, with care, may be adaptable to deal with
  them.

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.







Klyne, Iwazaki, Crocker     Internet draft                   [Page 40]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  While it may be OK for an unattended fax machine to perform
  automated nagotiation, 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, Iwazaki, Crocker     Internet draft                   [Page 41]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


Appendix C: Amendment history

  00a  30-Sep-1999  Memo initially created.

  00b  15-Oct-1999  Incorporated co-author material.  Added examples.
                    Added background section about open- and closed-
                    loop operations.  Cleaned up some text.  Develop
                    section describing the MDN extensions.  Complete
                    reference details.

  00c  19-Oct-1999  Acknowledgement and editorial changes.  Re-written
                    abstract and revised introductory text.

  01a  12-Nov-1999  Make consistent date and time values in the
                    examples.  Fix mailing list description.

  01b  09-Mar-2000  Add text clarifying the role of sender and
                    receiver in selecting alternative formats, the use
                    of multiple 'Content-alternative' headers.  Also
                    add some notes about sender behaviour when sending
                    an alternative data format.  Updated author
                    contact information.  Added reference to
                    multipart/alternative in the introduction.  Added
                    text in section 3.1 about retention of data by the
                    sender.  Added some comments to the implementation
                    notes section.  Added emphemeral capability
                    scenario suggested by Ted Hardie for consideration
                    under implementation notes.

  02a  11-Jul-2000  Change title of memo.  Re-work abstract and
                    introduction.  Add some text to the terminology
                    section;  also cite RFC 2703 here.  Minor
                    editorial changes.  Remove suggestion of allowing
                    comma separated list for 'Content-alternative'
                    header (following style of Content-features'
                    defined separately).

  02b  14-Jul-2000  Added revisions arising from comments by Tamura-
                    san:  text about receiver state issues;  note
                    about distinguishing initial message from re-send
                    of alternative data;  added requirement for
                    message-ID header;  add discussion of receiver
                    options in case of insufficient memory.

  03a  12-Sep-2000  Incorporate review comments.  Move implementation
                    issues to appendix.









Klyne, Iwazaki, Crocker     Internet draft                   [Page 42]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  03b  03-Oct-2000  Limit negotiation response to original addressees
                    (for now).  Add use of Original-message-ID: header
                    to link re-send of alternative data to original
                    message.  Add new disposition modifier option to
                    indicate alternatives previously offered are no
                    longer available.  Add description of final
                    confirmation following re-send.  Resolve many
                    small outstanding design decisions.

  03c  05-Oct-2000  Include 'Original-Message-ID:' header in re-send
                    of first example.

  04a  17-Oct-2000  Fix error in description of recipient processing
                    when data is no longer available.

  04b  23-Jan-2001  Define Original-Message-ID header.  Add negotiate-
                    down example.  Flesh out text of IANA
                    considerations, internationalization
                    considerations and security considerations
                    sections.  Write up outstanding implementation
                    issues (NOTE: transient receiver capabilities seem
                    to be addressed rather neatly by A.5).

  04c  29-Jan-2001  Add note to discuss range of alternatives to be
                    disclosed using the Content-alternatives header.

  REVIEW CHECKLIST:

  (Points to be checked more widely on or before final review)

  o  Cache-control for recipient features? (e.g. colour offered for
     selected senders only). (3.2.3)

  o  Check the correct final disposition for lost message data (3.4)

  o  Define Content-alternative in a separate document? (Possibly,
     because it might be used separately from the content negotiation
     framework;  e.g. in a fashion similar to the HTTP vary: header.)
     (4)

  o  Describe interaction between Content-alternative and
     message/partial.  Is the discussion in RFC 2298 section 2.5
     sufficient? (4)

  o  Special considerations for defining composite document
     characteristics (e.g. MRC) in Content-alternative headers? (4)

  o  Add E164 address type for reporting fax offramp disposal?  (6.2)







Klyne, Iwazaki, Crocker     Internet draft                   [Page 43]

Content Negotiation for Internet Fax                   29 January 2001
<draft-ietf-fax-content-negotiation-04.txt>


  o  Discuss the options that should be exposed using Content-
     alternative;  e.g. is it necessary to declare 'baseline'
     capabilities.


Full copyright statement

  Copyright (C) The Internet Society 2001.  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.























Klyne, Iwazaki, Crocker     Internet draft                   [Page 44]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/