rfc3297.txt

RFC 的详细文档！

Network Working Group                                           G. Klyne
Request for Comments: 3297                        Clearswift Corporation
Category: Standards Track                                     R. Iwazaki
                                                             Toshiba TEC
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                               July 2002


       Content Negotiation for Messaging Services based on Email

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

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

   Services such as facsimile and voice messaging need to cope with new
   message content formats, yet need to ensure that the content of any
   given message is renderable by the receiving agent.  The mechanism
   described here aims to meet these needs in a fashion that is fully
   compatible with the current behaviour and expectations of Internet
   email.

Table of Contents

   1. Introduction................................................... 3
     1.1 Structure of this document ................................. 4
     1.2 Document terminology and conventions ....................... 4
        1.2.1 Terminology............................................ 4
        1.2.2 Design goals........................................... 5
        1.2.3 Other document conventions............................. 5
   2. Background and goals........................................... 5
     2.1 Background ................................................. 5
        2.1.1 Fax and email.......................................... 5
        2.1.2 Current facilities in Internet Fax..................... 6
     2.2 Closing the loop ........................................... 6



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


     2.3 Goals for content negotiation .............................. 8
   3. Framework for content negotiation..............................10
     3.1 Send data with an indication of alternatives ...............11
        3.1.1 Choice of default data format..........................12
        3.1.2 MDN request indicating alternate data formats..........12
        3.1.3 Information about alternative data formats.............13
     3.2 Receiver options ...........................................14
        3.2.1 Alternatives not recognized............................14
        3.2.2 Alternative not desired................................14
        3.2.3 Alternative preferred..................................14
     3.3 Send alternative message data ..............................16
     3.4 Confirm receipt of resent message data .....................17
   4. The Content-alternative header.................................18
   5. The Original-Message-ID message header.........................18
   6. MDN extension for alternative data.............................19
     6.1 Indicating readiness to send alternative data ..............19
     6.2 Indicating a preference for alternative data ...............20
     6.3 Indicating alternative data is no longer available .........21
     6.4 Indicating loss of original data ...........................22
     6.5 Automatic sending of MDN responses .........................22
   7. Internet Fax Considerations....................................22
   8. Examples.......................................................23
     8.1 Sending enhanced Internet Fax image ........................23
     8.2 Internet fax with initial data usable ......................27
     8.3 Negotiate to lower receiver capability .....................28
     8.4 Sending an alternative content type ........................32
   9. IANA Considerations............................................36
     9.1 New message headers ........................................36
     9.2 MDN extensions .............................................36
        9.2.1 Notification option 'Alternative-available'............36
        9.2.2 Notification option 'Alternative-not-available'........36
        9.2.3 Disposition modifier 'Alternative-preferred'...........37
        9.2.4 Disposition modifier 'Original-lost'...................37
   10. Internationalization considerations...........................37
   11. Security Considerations.......................................37
   12. Acknowledgements..............................................38
   13. References....................................................38
   Appendix A: Implementation issues.................................40
     A.1 Receiver state .............................................40
     A.2 Receiver buffering of message data .........................41
     A.3 Sender state ...............................................42
     A.4 Timeout of offer of alternatives ...........................42
     A.5 Timeout of receiver capabilities ...........................42
     A.6 Relationship to timely delivery ............................43
     A.7 Ephemeral capabilities .....................................43
     A.8 Situations where MDNs must not be auto-generated ...........44
   Appendix B: Candidates for further enhancements...................44
   Authors' Addresses................................................45



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


   Full Copyright Statement..........................................46

1. Introduction

   This memo describes a mechanism for email based content negotiation
   which provides an Internet fax facility comparable to that of
   traditional facsimile, which may be used by other messaging services
   that need similar facilities.

   "Extended Facsimile using Internet Mail" [1] specifies the transfer
   of image data using Internet email protocols.  "Indicating Supported
   Media Features Using Extensions to DSN and MDN" [2] describes a
   mechanism for providing the sender with the details of a receiver's
   capabilities.  The capability information thus provided, if stored by
   the sender, can be used in subsequent transfers between the same
   sender and receiver.

   Many communications are one-off or infrequent transfers between a
   given sender and receiver, and cannot benefit from this "do better
   next time" approach.

   An alternative facility available in email (though not widely
   implemented) is for the sender to use 'multipart/alternative' [15] to
   send a message in several different formats, and allow the receiver
   to choose.  Apart from the obvious drawback of network bandwidth use,
   this approach does not of itself allow the sender to truly tailor its
   message to a given receiver, or to obtain confirmation that any of
   the alternatives sent was usable by the receiver.

   This memo describes a mechanism that allows better-than-baseline data
   formats to be sent in the first communication between a sender and
   receiver.  The same mechanism can also achieve a usable message
   transfer when the sender has based the initial transmission on
   incorrect information about the receiver's capabilities.  It allows
   the sender of a message to indicate availability of alternative
   formats, and the receiver to indicate that an alternative format
   should be provided to replace the message data originally
   transmitted.

   When the sender does not have the correct information about a
   receiver's capabilities, the mechanism described here may incur an
   additional message round trip.  An important goal of this mechanism
   is to allow enough information to be provided to determine whether or
   not the extra round trip is required.







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


1.1 Structure of this document

   The main part of this memo addresses the following areas:

   Section 2 describes some of the background, and sets out some
   specific goals that are addressed in this specification.

   Section 3 describes the proposed content negotiation framework,
   indicating the flow of information between a sender and receiver.

   Section 4 contains a detailed description of the 'Content-
   alternative' header that is used to convey information about
   alternative available formats.  This description is intended to stand
   independently of the rest of this specification, with a view to being
   usable in conjunction with other content negotiation protocols.

   Section 5 describes a new mail message header, 'Original-Message-ID',
   which is used to correlate alternative data sent during negotiation
   with the original message data, and to distinguish the continuation
   of an old message transaction from the start of a new transaction.

   Section 6 describes extensions to the Message Disposition
   Notification (MDN) framework [4] that support negotiation between the
   communicating parties.

1.2 Document terminology and conventions

1.2.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [22].

   Capability exchange
      An exchange of information between communicating parties
      indicating the kinds of information they can generate or consume.

   Capability identification
      Provision of information by the a receiving agent that indicates
      the kinds of message data that it can accept for presentation to a
      user.

   Content negotiation
      An exchange of information (negotiation metadata) which leads to
      selection of the appropriate representation (variant) when
      transferring a data resource.





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


   Message transaction

      A sequence of exchanges between a message sender and receiver that
      accomplish the transfer of message data.

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

1.2.2 Design goals

   In discussing the goals for content negotiation, {1}, {2}, {3}
   notation is used, per RFC 2542, "Terminology and Goals for Internet
   Fax" [3].  The meanings associated with these notations are:

   {1}   there is general agreement that this is a critical
         characteristic of any definition of content negotiation for
         Internet Fax.

   {2}   most believe that this is an important characteristic of
         content negotiation for Internet Fax.

   {3}   there is general belief that this is a useful feature of
         content negotiation for Internet Fax, but that other factors
         might override;  a definition that does not provide this
         element is acceptable.

1.2.3 Other document conventions

   NOTE:  Comments like this provide additional nonessential information
   about the rationale behind this document.  Such information is not
   needed for building a conformant implementation, but may help those
   who wish to understand the design in greater depth.

2. Background and goals

2.1 Background

2.1.1 Fax and email

   One of the goals of the work to define a facsimile service using
   Internet mail has been to deliver benefits of the traditional Group 3
   Fax service in an email environment.  Traditional Group 3 Fax leans
   heavily on the idea that an online exchange of information discloses
   a receiver's capabilities to the sender before any message data is
   transmitted.






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


   By contrast, Internet mail has been developed to operate in a
   different fashion, without any expectation that the sender and
   receiver will exchange information prior to message transfer.  One
   consequence of this is that all mail messages must contain some kind
   of meaningful message data:  messages that are sent simply to elicit
   information from a receiving message handling agent are not generally
   acceptable in the Internet mail environment.

   To guarantee some level of interoperability, Group 3 Fax and Internet
   mail rely on all receivers being able to deal with some baseline
   format (i.e., a basic image format or plain ASCII text,
   respectively).  The role of capability exchange or content
   negotiation is to permit better-than baseline capabilities to be
   employed where available.

   One of the challenges addressed by this specification is how to adapt
   the email environment to provide a fax-like service.  A sender must
   not make any a priori assumption that the receiver can recognize
   anything other than a simple email message.  There are some important
   uses of email that are fundamentally incompatible with the fax model
   of message passing and content negotiation (notably mailing lists).
   So we need to have a way of recognizing when content negotiation is
   possible, without breaking the existing email model.

2.1.2 Current facilities in Internet Fax

   "Extended Facsimile using Internet Mail" [1] provides for a limited
   provision of receiver capability information to the sender of a
   message, using an extension to Message Disposition Notifications
   [2,4], employing media feature tags [5] and media feature expressions
   [6].