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

Versions: 00 01 02 03 04 RFC 3297

IETF fax WG                    G. Klyne (editor), Content Technologies
Internet draft                                 R. Iwazaki, Toshiba TEC
                                    D. Crocker, Brandenburg Consulting
                                                          14 July 2000
                                                Expires: December 2000


         Content Negotiation for Internet Messaging Services
             <draft-ietf-fax-content-negotiation-02.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 2000.  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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


Table of contents

1. Introduction.............................................3
  1.1 Structure of this document ...........................4
  1.2 Document terminology and conventions .................4
     1.2.1 Terminology......................................4
     1.2.2 Design goals.....................................5
     1.2.3 Other document conventions.......................5
  1.3 Discussion of this document ..........................5
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...............6
  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......................15
     3.2.2 Alternative not desired..........................15
     3.2.3 Alternative preferred............................15
  3.3 Send alternative message data ........................16
  3.4 Implementation issues ................................17
     3.4.1 Receiver state...................................17
     3.4.2 Receiver buffering of message data...............19
     3.4.x Other issues.....................................19
4. The Content-alternative header...........................20
5. MDN extension for alternative data.......................20
  5.1 Indicating readiness to send alternative data ........21
  5.2 Indicating a preference for alternative data .........22
6. Internet Fax Considerations..............................23
7. Examples.................................................23
  7.1 Sending enhanced Internet Fax image ..................23
  7.2 Internet fax with initial data usable ................26
  7.3 Other example??? .....................................28
8. IANA Considerations......................................28
9. Internationalization considerations......................28
10. Security considerations.................................28
11. Acknowledgements........................................28
12. References..............................................29
13. Authors' addresses......................................31
Appendix A: Amendment history...............................32
Full copyright statement....................................34









Klyne, Iwazaki, Crocker     Internet draft                    [Page 2]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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.

  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.













Klyne, Iwazaki, Crocker     Internet draft                    [Page 3]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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 extensions to the Message Disposition
  Notification (MDN) framework [4] that are used to allow negotiation
  between the communicating parties.

1.2 Document terminology and conventions

1.2.1 Terminology

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

  [[[Others?]]]

  RFC 2703 [17] introduces several other terms related to content
  negotiation.











Klyne, Iwazaki, Crocker     Internet draft                    [Page 4]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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.

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

1.3 Discussion of this document

  Discussion of this document should take place on the Internet fax
  mailing list hosted by the Internet Mail Consortium (IMC).  Please
  send comments regarding this document to:

      ietf-fax@imc.org

  To subscribe to this list, send a message with the body 'subscribe'
  to "ietf-fax-request@imc.org".

  To see what has gone on before you subscribed, please see the
  mailing list archive at:

      http://www.imc.org/ietf-fax/










Klyne, Iwazaki, Crocker     Internet draft                    [Page 5]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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

  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






Klyne, Iwazaki, Crocker     Internet draft                    [Page 6]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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 mechansism 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 trasmission 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 consistemt 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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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 implementable 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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  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.

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

  [[[?Require use of Original-recipient header.  Only receivers that
  match this may request alternative data formats.  This reinforces
  the 1:1 nature of a negotiation transaction?  (This is spec.ed for
  gateways and may be inappropriate here.)]]]

  [[[?Consider whether to handle case of forwarded message?]]]

  [[[?To ensure consistency of results, require content-id with body
  part to which alternative capabilities are attached, to be noted in
  MDN response?]]]

3.1 Send data with an indication of alternatives

  A sender that is prepared to provide alternative message data
  formats sends:

  (a)  a default message data format,

  (b)  message identification, in the form of a Message-ID header.

  (c)  appropriate 'Content-features' header(s) [7] describing the
       default message data sent,

  (d)  a request for Message Disposition Notification [4],






Klyne, Iwazaki, Crocker     Internet draft                   [Page 11]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  (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 will presumably hold the necessary information for some
  time, to allow the receiver an opportunity to request such data.
  But 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
  avalable.  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.

  [[[Use feature expression parameter to indicate TTL?  Or use
  parameter on MDN request?]]]

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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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 avalable --
       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
       avalable.

       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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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
       negototiation 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 and 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 shows how the 'Content-features:'
  and 'Content-alternative:' MIME headers may be used to describe the
  content provided and available alternatives.

  [[[Q-factor values, per RFC 2533, in the 'Content-alternative:'
  expressions might be used to distinguish between "definitive" and
  "approximate" alternatives.]]]

  [[[Expiration time on alternatives list.  Else recipient is in non-
  deterministic position.  Also, cache control on recipient
  capabilities?]]]

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.











Klyne, Iwazaki, Crocker     Internet draft                   [Page 14]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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.

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 similar to 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 resends may not use this option).

  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 MUST be sent
  containing:

  o  an 'Alternative-preferred' disposition modifier [9] indicating
     that some data format other than that originally sent is
     preferred, 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.

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







Klyne, Iwazaki, Crocker     Internet draft                   [Page 15]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  Corrective action may be any of the following:

  (a)  resend the MDN response, and continue waiting for an
       alternative,

  (b)  generate an error response indicating loss of data, or

  (c)  present the data originally supplied (if it is still
       available).  This would be the preferred action, may not be
       possible for receivers with limited memory.

  See section 3.4.1 for further discussion of receiver behaviour
  options.

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

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 the alternative message data is the same as that originally
  sent, it SHOULD still be retransmitted 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 not an 'Alternative-available' option.

  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.





Klyne, Iwazaki, Crocker     Internet draft                   [Page 16]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  [[[Discuss this last paragraph.]]]

  [[[When sending alternative data, should this fact be indicated?
  How is the resend tied to the original send.]]]

  [[[The mechanisms are described above in terms of the entire
  message.  With MDN extensions that are being considered for finer-
  grained disposition notification at the level of individual message
  body parts (e.g. the separate parts of a MIME multipart/mixed),
  this mechanism can be extended to provide independent negotiation
  for each body part, because the 'Content-features:' and 'Content-
  alternative:' can be applied to inner body parts.]]]

  [[[Does it make sense to do a partial retransmission?  I think this
  would be a receiver option, based on which message parts it
  indicates have been discarded.  If it can buffer then partial
  retransmission is sensible.]]]

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

3.4.1 Receiver state

  Probably the biggest implication for implementers of this proposal
  compared with standard SMTP 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.








Klyne, Iwazaki, Crocker     Internet draft                   [Page 17]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  Keeping receiver state is probably not a problem for systems with
  high capacity storage devices to hold message data and state
  information.  The remainder of this section discusses strategies
  that small-system designers might employ to place an upper bound on
  memory that must be reserved for this information.  When a receiver
  is really memory constrained then message loss remains a
  possibility, but the mechanisms described here should ensure that
  it never happens silently.

  So what is this "receiver state"?  It must contain, as a minimum:

  o  the fact that message data was received, and alternative data has
     been requested,

  o  a unique message identifier, and

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

  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.







Klyne, Iwazaki, Crocker     Internet draft                   [Page 18]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  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.

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

3.4.x Other issues...

  -- Sender state

  [[[Maintenance of information about outsanding offers of
  alternative data formats.]]]

  -- Timeout of offer of alternatives

  [[[Expand on note at end of section 3.1.  Sender alternatives and
  choices?  Consider facility to indicate expiry of alternatives.]]]

  -- Timeout of receiver capabilities

  [[[Consider facility to indicate expiry of receiver capabilities.
  Also, cache-control options, for temporary capabilities.]]]

  -- Relationship to timely delivery

  [[[What optimizations are possible (if any) when delivery and
  response is known to take no more than a few seconds?]]]

  -- Ephemeral capabilities

  [[[Consider the case of selection of a particular variant which may
  depend on an ephemeral setting.  Imagine someone sending a basic
  fax to a color fax machine and indicating that a color alternative
  is available.  The color fax discards the content and sends an MDN





Klyne, Iwazaki, Crocker     Internet draft                   [Page 19]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  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. (This may sound
  stretched, but consider it from the email client in a phone with
  sound on/off as a related problem).]]]

  -- Partial vs whole-message resend

  -- Recipient is fax machine vs e-mail UA

  -- Reinforce situations where MDNs must not be auto-generated

  -- Fax offramp issues


4. The Content-alternative header

  [[[May be moved to a separate document.]]]

  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.

  [[[Define 'ext-param' for feature cache control/expiry?]]]

  [[[Need to consider how to express composite document capabilities,
  specifically to assert a number of feature expressions that must be
  simultaneously satisfied for a document to be processed, as in the
  case of an MRC containing hi-res B/W and low-res colour.  The
  approach currently under consideration is a metalogic level
  encapsulating media feature expressions]]]

  [[[Discuss use with 'message/partial'?]]]








Klyne, Iwazaki, Crocker     Internet draft                   [Page 20]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


5. MDN extension for alternative data

  [[[May be moved to a separate document]]]

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

5.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,(TRUE)

  [[[Is the parameter value really mandatory?  RFC2298 syntax says
  so.  If so, what value should be used (what variations might be
  required).  Think carefully, this is a solution looking for a
  problem.  For now, I would prefer the option value to be optional.
  If the value is required, its syntax should not preclude useful
  extensions later.  Use parameter to indicate return mailbox?  Note
  that RFC2298 allows auto-response to a single mailbox only.]]]

  [[[Use the parameter value to indicate an expiry time?]]]







Klyne, Iwazaki, Crocker     Internet draft                   [Page 21]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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

5.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 discards message data because it prefers 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

  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.

  [[[Discuss constraints on sending this response automatically.]]]

  [[[Add E164 address type for fax offramp to fax machine as final
  recipient?]]]






Klyne, Iwazaki, Crocker     Internet draft                   [Page 22]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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


7. Examples

7.1 Sending enhanced Internet Fax image

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

  Sender's initial message:

     Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
     From: Jane Sender <Jane_Sender@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,[[[xxx]]]
     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) )












Klyne, Iwazaki, Crocker     Internet draft                   [Page 23]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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

  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













Klyne, Iwazaki, Crocker     Internet draft                   [Page 24]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


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

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






Klyne, Iwazaki, Crocker     Internet draft                   [Page 25]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


     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)
            (| (& (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--

7.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,[[[xxx]]]
     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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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--

7.3 Other example???

  [[[Showing negotiate-down]]]


8. IANA Considerations

  [[[TBD: MIME header and MDN extension registrations]]]

  [[[See RFC 2298, section 10]]]


9. Internationalization considerations

  [[[TBD?]]]


10. Security considerations

  [[[TBD]]]


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

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


12. 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 5)

[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 29]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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 30]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.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, Content Technologies
     Internet draft: <draft-ietf-fax-timely-delivery-00.txt>
     Work in progress, October 1999.


13. Authors' addresses

  Graham Klyne (editor)
  Content Technologies Ltd.
  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
  675 Spruce Dr.
  Sunnyvale, CA 94086 USA
  Phone:    +1 408 246 8253
  Fax:      +1 408 249 6205
  EMail:    dcrocker@brandenburg.com








Klyne, Iwazaki, Crocker     Internet draft                   [Page 31]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


Appendix A: 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 resend
                    of alternative data;  added requirement for
                    message-ID header;  add discussion of receiver
                    options in case of insufficient memory.

  TODO:

  o  Review use of RFC 2119 language

  o  Complete terminology (1.2.1)






Klyne, Iwazaki, Crocker     Internet draft                   [Page 32]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  o  Require use of 'Original-recipient' header, and limit negotiation
     to receivers named there? (3)

  o  Allow negotiation with forwarded messages? (3)

  o  Require use of content-id to be noted by requests for alternative
     formats? (3)

  o  TTL for alternative-feature sets? (3.1)

  o  Use q-values to distinguish 'definitive' from 'informative'
     format options? (3.1.3)

  o  Cache-control for alternative feature sets? (e.g. colour offered
     for selected recipients only). (3.1.3)

  o  Confirm action when sender cannot honour request for alternative
     (e.g. offer timed out). (3.3)

  o  How to differentiate alternative data (e.g. don't show
     alternative available)? (3.3)

  o  How to relate resend to original send? (3.3)

  o  Consideration of partial resends (i.e. selected body parts only)?
     (3.3)

  o  Write up "implementation issues" -- when outstanding issues are
     decided. (3.4)

  o  Cache-control, timeout for receiver capabilities? (3.4)

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

  o  Consideration of composite document structures (e.g. MRC) in
     Content-alternative header?  (This is really a media feature
     expression issue that is not fully resolved.  The current syntax
     is a particular trade-off between reasonable simplicity and
     comprehensive functionality.) (4)

  o  Describe interaction between Content-alternative and
     message/partial. (4)

  o  Define MDN extensions in separate document?  (Probably not, since
     they are not really useful separately from this negotiation
     framework.) (5)






Klyne, Iwazaki, Crocker     Internet draft                   [Page 33]

Content Negotiation for Internet Fax                      14 July 2000
<draft-ietf-fax-content-negotiation-02.txt>


  o  Consider use of MDN option parameter:  request MDN expert input.
     (5.1)

  o  Time-limit on offer of alternative data?  (This raises clock-
     synchronization and message transit time issues.) (5.1)

  o  Add text about automated transmission of MDN responses for
     content negotiation.  (5.2)

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

  o  Negotiate-down example? (7.3)

  o  IANA considerations. (8)

  o  Internationalization considerations (if any). (9)

  o  Security considerations. (10)


Full copyright statement

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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/