rfc3297.txt

RFC 的详细文档！

   This mechanism provides for receiver capabilities to be disclosed
   after a message has been received and processed.  This information
   can be used for subsequent transmissions to the same receiver.  But
   many communications are one-off messages from a given sender to a
   given receiver, and cannot benefit from this.

2.2 Closing the loop

   Classic Internet mail is an "open loop" process:  no information is
   returned back to the point from which the message is sent.  This has
   been unkindly --but accurately-- characterized as "send and pray",
   since it lacks confirmation.

   Sending a message and obtaining confirmation that the message has
   been received is a "closed loop" process:  the confirmation sent back
   to the sender creates a loop around which information is passed.



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


   Many Internet email agents are not designed to participate in a
   closed loop process, and thus have no responsibility to respond to
   receipt of a message.  Later additions to Internet standards, notably
   Delivery Service Notification [18] and Message Disposition
   Notification [4], specify means for certain confirmation responses to
   be sent back to the sender, thereby closing the loop.  However
   conformance to these enhancements is optional and full deployment is
   in the future.

   DSN must be fully implemented by the entire infrastructure; further
   when support is lacking, the message is still sent on in open-loop
   fashion.  Sometimes, transmission and delivery should instead be
   aborted and the fact be reported to the sender.

   Due to privacy considerations for end-users, MDN usage is entirely
   voluntary.

   Content negotiation is a closed loop function (for the purposes of
   this proposal -- see section 2.3, item (f)), and requires that the
   recipient of a message make some response to the sender.  Since
   content negotiation must retro-fit a closed-loop function over
   Internet mail's voluntary and high-latency environment, a challenge
   for content negotiation in email is to establish that consenting
   parties can recognize a closed loop situation, and hence recognize
   their responsibilities to close the loop.

   Three different loops can be identified in a content negotiation:

              Sender                      Receiver
                |                             |
         Initial message ------>------------  v
                |                             |
               (1) ------------<--- Request alternative data
                |                             |
        Send alternative ------>------------ (2)
                |                             |
               (3) ------------<------ Confirm receipt
                                       of usable data

   (1)   Sender receives acknowledgement that negotiable content has
         been received

   (2)   Receiver receives confirmation that its request for data has
         been received.

   (3)   Sender receives confirmation that received data is processable,
         or has been processed.




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


   Although the content negotiation process is initiated by the sender,
   it is not established until loop (1) is closed with an indication
   that the receiver desires alternative content.

   If content sent with the original message from the sender is
   processable by the receiver, and a confirmation is sent, then the
   entire process is reduced to a simple send/confirm loop:

                  Sender                      Receiver
                    |                             |
             Initial message ------>------------  v
                    |                             |
                   (3) ------------<------ Confirm receipt
                                           of usable data

2.3 Goals for content negotiation

   The primary goal {1} is to provide a mechanism that allows arbitrary
   enhanced content features to be used with Internet fax systems.  The
   mechanism should {2} support introduction of new features over time,
   particularly those that are adopted for Group 3 fax.

   Further goals are:

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

   (b)   Must {1} interwork with existing email clients.

         The term "interwork" used above means that the mechanism must
         be introduced in a way that may be ignored by existing systems,
         and systems enhanced to use the negotiation mechanisms will
         behave in a fashion that is expected by existing systems.
         (I.e., existing clients are not expected in any way to
         participate in or be aware of content negotiation.)

   (c)   Must {1} avoid transmission of "administrative non messages".
         (I.e., only messages that contain meaningful content for the
         end user may be sent unless it is known that the receiving
         system will interpret them, and not attempt to display them.)
         This requirement has been stated very strongly by the email
         community.

         This means that a sender must not assume that a receiver can
         understand the capability exchange protocol elements, so must
         always start by sending some meaningful message data.





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


   (d)   Avoid {1} multiple renderings of a message.  In situations
         where multiple versions of a message are transferred, the
         receiver must be able to reliably decide on a single version to
         be displayed.

   (e)   Minimize {2} round trips needed to complete a transmission.
         Ideally {3} every enhanced transmission will result in simply
         sending data that the recipient can process, and receiving a
         confirmation response.

   (f)   The solution adopted should not {3} transmit multiple versions
         of the same data.  In particular, it must not {1} rely on
         routinely sending multiple instances of the same data in a
         single message.

         This does not prohibit sending multiple versions of the same
         data, but it must not be a requirement to do so.  A sender may
         choose to send multiple versions together (e.g., plain text and
         some other format), but the capability exchange mechanism
         selected must not depend on such behaviour.

   (g)   The solution adopted should {2} be consistent with and
         applicable to other Internet email based applications; e.g.,
         regular email, voice messaging, unified messaging, etc.

   (h)   Allow for a graceful recovery from stale cache information.  A
         sender might use historic information to send non-baseline data
         with an initial message.  If this turns out to be unusable by
         the recipient, it should still be possible {3} for the baseline
         data, or some other acceptable format, to be selected and
         transferred.

   (i)   The mechanism defined should {2} operate cleanly in conjunction
         with the mechanisms already defined for extended mode Internet
         fax (extended DSN and MDN [2], etc.).

   (j)   As much as possible, existing email mechanisms should {3} be
         used rather than inventing new ones.  (It is clear that some
         new mechanisms will be needed, but they should be defined
         cautiously.)

   (k)   The mechanism should {2} be implementable in low memory
         devices.  That is, it should not depend on any party being able
         to buffer arbitrary amounts of message data.







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


         (It may not be possible to completely satisfy this goal in a
         sending system.  But if the sender does not have enough memory
         to buffer some given message, it can choose to not offer
         content negotiation.)

3. Framework for content negotiation

   This section starts with an outline of the negotiation process, and
   provides greater detail about each stage in following sub-sections.

   1. Sender sends initial message data with an indication of
      alternative formats available (section 3.1).  Initial data MAY be
      a baseline or some other guess of what the recipient can handle.

   2. The receiver has three main options:

      (a)   Does not recognize the optional alternative formats, and
            passively accepts the data as sent (section 3.2.1).

      (b)   Does recognize the alternatives offered, and actively
            accepts the data as sent (section 3.2.2).

      (c)   Recognizes the alternatives offered, and determines that it
            prefers to receive an alternative format.  An MDN response
            is sent (i) indicating that the original data was not
            processed, and (ii) containing receiver capability
            information so that the sender may select a suitable
            alternative (section 3.2.3).

            Note that only recipients named in 'to:', 'cc:' or 'bcc:'
            headers in the original message may request alternative data
            formats in this way.  Recipients not named in the original
            message headers MUST NOT attempt to initiate content
            negotiation.

            NOTE: the prohibition on initiation of negotiation by
            recipients other than those explicitly addressed is to avoid
            the sender from having to deal with negotiation requests
            from unexpected parties.

   3. On receipt of an MDN response indicating preference for an
      alternative data format, the sender MUST select and transmit
      message data matched to the receiver's declared capabilities, or
      send an indication that the receiver's request cannot be honoured.
      When sending alternative data, the sender suppresses the
      indication that alternative data is available, so the negotiation
      process cannot loop.




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


   4. On receipt of final data from the sender, the receiver sends an
      MDN response indicating acceptance (or otherwise) of the data
      received.

         NOTE:  the receiver does not choose the particular data format
         to be received;  that choice rests with the sender.  We find
         that this approach is simpler than having the receiver choose
         an alternative, because it builds upon existing mechanisms in
         email, and follows the same pattern as a traditional Group 3
         fax.  Further, it deals with situations where the range of
         alternatives may be difficult to describe.

         This approach is similar to server driven negotiation in HTTP
         using "Accept" headers [13].  This is distinct to the agent-
         driven style of negotiation provided for HTTP as part of
         Transparent Content Negotiation [14], or which might be
         constructed in email using "multipart/alternative" and
         "message/external-body" MIME types [15].

3.1 Send data with an indication of alternatives

   A sender that is prepared to provide alternative message data formats
   MUST send the following message elements:

   (a)   a default message data format,

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

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

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

   (e)   an indication that it is prepared to send different message
         data, using an 'Alternative-available' MDN option field [9],
         and

   (f)   an indication of the alternative data formats available, in the
         form of 'Content-alternative' header(s) [8].  Note:  more than
         one Content-alternative' header MAY be specified; see section
         3.1.3 for more information.

   Having indicated the availability of alternative data formats, the
   sender is expected to hold the necessary information for some time,
   allowing the receiver an opportunity to request such data.  But,
   unless it so indicates (see [9]), the sender is not expected to hold
   this information indefinitely;  the exact length of time such
   information should be held is not specified here.  Thus, the



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


   possibility exists that a request for alternative information may
   arrive too late, and the sender will then send an indication that the
   data is no longer available.  If message transference is being
   completed within a predetermined time interval (e.g., using [21]),
   then the sender should normally maintain the data for at least that
   period.

3.1.1 Choice of default data format

   The normal default format is text/plain.  This is the format sent
   unless the sender has prior knowledge or expectation of other content
   formats supported by the recipient.  Some uses of email presume some