doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc4141.txt b/doc/rfc/rfc4141.txt
new file mode 100644
index 0000000..5ab6f4e
--- /dev/null
+++ b/doc/rfc/rfc4141.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                          K. Toyoda
+Request for Comments: 4141                                           PCC
+Category: Standards Track                                     D. Crocker
+                                                             Brandenburg
+                                                           November 2005
+
+
+            SMTP and MIME Extensions for Content Conversion
+
+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 (2005).
+
+Abstract
+
+   A message originator sometimes sends content in a form the recipient
+   cannot process or would prefer not to process a form of lower quality
+   than is preferred.  Such content needs to be converted to an
+   acceptable form, with the same information or constrained information
+   (e.g., changing from color to black and white).  In a store-and-
+   forward environment, it may be convenient to have this conversion
+   performed by an intermediary.  This specification integrates two
+   ESMTP extensions and three MIME content header fields, which defines
+   a cooperative service that permits authorized, accountable content
+   form conversion by intermediaries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 1]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1. Background. . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.2. Overview. . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.3. Notational Conventions. . . . . . . . . . . . . . . . . .  5
+   2.  Applicability. . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Service Specification. . . . . . . . . . . . . . . . . . . . .  5
+       3.1. Sending Permission. . . . . . . . . . . . . . . . . . . .  9
+       3.2. Returning Capabilities. . . . . . . . . . . . . . . . . . 10
+       3.3. Next-Hop Non-Support of Service . . . . . . . . . . . . . 12
+   4.  Content Conversion Permission SMTP Extension . . . . . . . . . 12
+       4.1. Content Conversion Permission Service Extension
+            Definition. . . . . . . . . . . . . . . . . . . . . . . . 12
+       4.2. CONPERM Parameter to Mail-From. . . . . . . . . . . . . . 13
+       4.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.  Content Negotiation SMTP Extension . . . . . . . . . . . . . . 13
+       5.1. Content Negotiation Service Extension Definition. . . . . 13
+       5.2. CONNEG Parameter to RCPT-TO . . . . . . . . . . . . . . . 14
+       5.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 15
+   6.  MIME Content-Features Header Field . . . . . . . . . . . . . . 16
+   7.  MIME Content-Convert Header Field. . . . . . . . . . . . . . . 16
+   8.  MIME Content-Previous Header Field . . . . . . . . . . . . . . 16
+   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       9.1. CONPERM Negotiation . . . . . . . . . . . . . . . . . . . 17
+       9.2. Example CONNEG Negotiation. . . . . . . . . . . . . . . . 18
+       9.3. Content-Previous. . . . . . . . . . . . . . . . . . . . . 19
+   10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   Appendix A. CONNEG with Direct SMTP. . . . . . . . . . . . . . . . 22
+   Appendix B. USING Combinations of the Extensions . . . . . . . . . 23
+   Appendix C. MIME Content-Type Registrations. . . . . . . . . . . . 24
+
+1.  Introduction
+
+   Internet specifications typically define common capabilities for a
+   particular service that are supported by all participants.  This
+   permits the sending of basic data without knowing which additional
+   capabilities individual recipients support.  However, knowing those
+   capabilities permits the sending of additional types of data and data
+   of enhanced richness.  Otherwise, a message originator will send
+   content in a form the recipient cannot process or will send multiple
+   forms of data.  This specification extends the work of [CONMSG],
+   which permits a recipient to solicit alternative content forms from
+   the originator.  The current specification enables MIME content
+   conversion by intermediaries, on behalf of a message originator and a
+   message recipient.
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 2]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+1.1.  Background
+
+   MIME enables the distinguishing and labeling of different types of
+   content [IMF, MEDTYP].  However, an email originator cannot know
+   whether a recipient is able to support (interpret) a particular data
+   type.  To permit the basic use of MIME, a minimum set of data types
+   is specified as its support base.  How will an originator know
+   whether a recipient can support any other data types?
+
+   A mechanism for describing MIME types is specified in [FEAT].
+   [CONMSG] specifies a mechanism that permits an originator to query a
+   recipient about the types it supports using email messages for the
+   control exchange.  This permits a recipient to propagate information
+   about its capabilities back to an originator.  For the control
+   exchange, using end-to-end email messages introduces considerable
+   latency and some unreliability.
+
+   An alternative approach is for an originator to use the "best" form
+   of data that it can, and to include the same types of permitted
+   representation information used in [CONMSG].  Hopefully, the
+   recipient, or an intermediary, can translate this into a form
+   supported by a limited recipient.  This specification defines such a
+   mechanism.  It defines a means of matching message content form to
+   the capabilities of a recipient device or system, by using MIME
+   content descriptors and the optional use of an SMTP-based negotiation
+   mechanism [ESMTP1, ESMTP2].
+
+1.2.  Overview
+
+   An originator describes desirable content forms in MIME content
+   descriptors.  It may give "permission", to any intermediary or the
+   recipient, to convert the content to one of those forms.  Separately,
+   an SMTP server may report the target's content capabilities back to
+   the SMTP client.  The client is then able to convert the message
+   content into a form that is both supported by the target system and
+   acceptable to the originator.
+
+   A conversion service needs to balance between directions provided by
+   the originator, directions provided on behalf of the recipient, and
+   capabilities of the intermediary that performs the conversions.  This
+   is complicated by the need to determine whether the directions are
+   advisory or whether they are intended to be requirements.
+   Conversions specified as advisory are performed if possible, but they
+   do not alter message delivery.  In contrast, conversion
+   specifications that are treated as a requirement will prohibit
+   delivery if the recipient will not be able to process the content.
+
+
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 3]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   These possibilities interact to form different processing scenarios,
+   in the event that the intermediary cannot satisfy the desires of both
+   the originator and the recipient:
+
+                 Table 1: FAILURE HANDLING
+
+            \  RECEIVER|          |          |
+             +-------+ |  Advise  | Require  |
+            ORIGINATOR\|          |          |
+            -----------+----------+----------+
+                       | Deliver  | Deliver  |
+            Advise     | original | original |
+                       | content  | content  |
+            -----------+----------+----------+
+                       | Return   | Return   |
+            Require    | w/out    | w/out    |
+                       | delivery | delivery |
+            -----------+----------+----------+
+
+   This table reflects a policy that determines failure handling solely
+   based on the direction provided by the originator.  Thus, information
+   on behalf of the recipient is used to guide the details of
+   conversion, but not delivery of the message.
+
+   This is intended to continue the existing email practice of
+   delivering content that a recipient might not be able to process.
+   Clearly, the above table could be modified to reflect a different
+   policy.  However, that would limit backward compatibility experienced
+   by users.
+
+   This specification provides mechanisms to support a controlled,
+   transit-time mail content conversion service, through a series of
+   mechanisms.  These include:
+
+      *  an optional ESMTP hop-by-hop service that uses the CONPERM SMTP
+         service extensions, issued by the originator,
+
+      *  an optional ESMTP hop-by-hop service that uses the CONNEG SMTP
+         service extensions, issued on behalf of the recipient, and
+
+      *  three MIME Content header fields (Content-Convert, Content-
+         Previous and *  Content-Features) that specify appropriate
+         content header fields and record conversions that have been
+         performed.
+
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 4]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+              Figure 1:  EXAMPLE RELAY ENVIRONMENT
+
+         +------------+                      +-----------+
+         | Originator |                      | Recipient |
+         +------------+                      +-----------+
+              ||Posting                   Delivering/\
+              \/                                    ||
+          +--------+    +-----------------+    +--------+
+          |  SMTP  |    |    SMTP Relay   |    |  SMTP  |
+          | Client |--->| Server | Client |--->| Server |
+          +--------+    +--------+--------+    +--------+
+
+1.3.  Notational Conventions
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
+   this document are to be interpreted as defined in "Key words for use
+   in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+2.  Applicability
+
+   This specification defines a cooperative mechanism that facilitates
+   early transformation of content.  The mechanism can be used to save
+   bandwidth and to permit rendering on recipient devices that have
+   limited capabilities.  In the first case, the assumption is that
+   conversion will produce smaller content.  In the latter case, the
+   assumption is that the recipient device can render content in a form
+   derived from the original, but cannot render the original form.
+
+   The mechanism can impose significant resource requirements on
+   intermediaries performing conversions.  Further, the intermediary
+   accepts responsibility for conversion prior to knowing whether it can
+   perform the conversion.  Also note that conversion is not possible
+   for content that has been digitally signed or encrypted, unless the
+   converting intermediary can decode and re-code the content.
+
+3.  Service Specification
+
+   This service integrates two ESMTP extensions and three MIME content
+   header fields, in order to permit authorized, accountable content
+   form conversion by intermediaries.  Intermediaries are ESMTP hosts
+   (clients and servers) along the transmission path between an
+   originator and a recipient.
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 5]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   An originator specifies preferred content-types through the Content-
+   Convert MIME content header field.  The content header fields occur
+   in each MIME body-part to which they apply.  That is, each MIME
+   body-part contains its own record of conversion guidance and history.
+
+   The originator's preferences are raised to the level of requirement
+   through the ESMTP CONPERM service extension.  The CONPERM mechanism
+   is only needed when an originator requires that conversion
+   limitations be enforced by the mail transfer service.  If an
+   acceptable content type cannot be delivered, then no delivery is to
+   take place.
+
+   Target system capabilities are communicated in SMTP sessions through
+   the ESMTP CONNEG service extension.  This information is used to
+   restrict the range of conversions that may be performed, but does not
+   affect delivery.
+
+   When CONPERM is used, conversions are performed by the first ESMTP
+   host that can obtain both the originator's permission and information
+   about the capabilities supported by the recipient.  If a relay or
+   client is unable to transmit the message to a next-hop that supports
+   CONPERM or to perform appropriate conversion, then it terminates
+   message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the
+   originator, with status code 5.6.3 (Conversion required but not
+   supported).
+
+   When an SMTP relay or server performs content conversion, it records
+   which specific conversions are made into Content-Previous and
+   Content-Features MIME header fields associated with each converted
+   MIME body-part.
+
+   If a message is protected by strong content authentication or privacy
+   techniques, then an intermediary that converts message content MUST
+   ensure that the results of its processing are similarly protected.
+   Otherwise it MUST NOT perform conversion.
+
+   Originator Action:
+
+           An originator specifies desired conversion results through
+      the MIME Content-Convert header field.  If the originator includes
+      a Content-Convert header field, then it must also include a
+      Content-Feature header field, to indicate the current form of the
+      content.  Intermediaries MAY interpret the presence of this header
+      field as authorization to perform conversions.  When Content-
+      Convert header fields are the sole means for guiding conversions
+      by intermediaries, then they serve only as advisories.  Failure to
+      satisfy the guidance of these header fields does not affect final
+      delivery.
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 6]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+           When posting a new message, the originator MAY specify
+      transit-service enforcement of conversion limitations by using the
+      ESMTP CONPERM service extension.  In each of the MIME body-parts
+      for which conversion is authorized, conversions MUST be limited to
+      those specified in MIME Content-Convert header fields.  If
+      conversion is needed, but an authorized conversion cannot be
+      performed, then the message will be returned to the originator.
+      If CONPERM is not used, then failure to perform an authorized
+      conversion will not affect normal delivery handling.
+
+                          Figure 2: CONPERM USAGE
+
+               +------------+
+               | Originator |
+               +------------+
+                SMTP  ||
+                 or   || CONPERM
+               SUBMIT \/
+                  +--------+            +----------------+
+                  |  SMTP  |   SMTP     |    SMTP Relay  |
+                  | Client |----------->| Server |       |
+                  +--------+  CONPERM   +--------+-------+
+
+   Recipient Action:
+
+           With the ESMTP mail transfer service, capabilities that can
+      be supported on behalf of the recipient SHOULD be communicated to
+      intermediaries by the ESMTP CONNEG service extension.
+
+                      Figure 3: CONNEG USAGE
+
+                                        +-----------+
+                                        | Recipient |
+                                        +-----------+
+                                  Capabilities||
+                                              \/
+               +----------------+         +--------+
+               |   SMTP Relay   |  CONNEG |  SMTP  |
+               |       | Client |<--------| Server |
+               +-------+--------+         +--------+
+
+
+   Intermediary Actions:
+
+           An intermediary MAY be given CONPERM direction when receiving
+      a message, and MAY be given CONNEG guidance before sending the
+      message.  CONPERM and CONNEG operate on a per-message basis and
+      are issued through the ESMTP MAIL-FROM request.  CONNEG response
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 7]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+      information is provided on a per-recipient basis, through the
+      response to ESMTP RCPT-TO.
+
+           Conversion MUST be performed by the first CONPERM
+      intermediary that obtains the CONNEG capability information.  The
+      MIME Content-Type MUST conform to the result of the converted
+      content, as per [MEDTYP].  When an intermediary obtains different
+      capability information for different recipients of the same
+      message, it MAY either:
+
+         *  Create a single, converted copy of the content that can be
+            supported by all of the recipients, or
+
+         *  Create multiple converted copies, matching the capabilities
+            of subsets of the recipients.  Each version is then sent
+            separately to an appropriate subset of the recipients, using
+            separate, standard SMTP sessions with separate, standard
+            RFC2821.Rcpt-To lists of addresses.
+
+           A record of conversions is placed into MIME Content-Previous
+      header fields.  The current form of the content is described in
+      MIME Content-Features header fields.
+
+           A special case of differential capabilities occurs when an
+      intermediary receives capability information about some
+      recipients, but no information about others.  An example of this
+      scenario can occur when sending a message to some recipients
+      within one's own organization, along with recipients located
+      elsewhere.  The intermediary might have capability information
+      about the local recipients, but will not have any for distant
+      recipients.  This is treated as a variation of the handling that
+      is required for situations in which the permissible conversions
+      are the null set -- that is, no valid conversions are possible for
+      a recipient.
+
+      Rather than simply failing transmission to the recipients for
+      which there is no capability information, the intermediary MAY
+      choose to split the list of addressees into subsets of separate,
+      standard RFC2821.Rcpt-To lists and separate, standard SMTP
+      sessions, and then continue the transmission of the original
+      content to those recipients via the continued use of the CONPERM
+      mechanism.  Hence, the handling for such recipients is performed
+      as if no CONNEG transaction took place.
+
+           Once an intermediary has performed conversion, it MAY
+      terminate use of CONPERM.  However, some relay environments, such
+      as those re-directing mail to a new target device, will benefit
+      from further conversion.  Intermediaries MAY continue to use
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 8]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+      CONPERM or MAY re-initiate CONPERM use when they have knowledge of
+      possible variations in a target device.
+
+         NOTE: A new, transformed version of content may have less
+         information than the earlier version.  Of course, a sequence of
+         transformations may lose additional information at each step.
+         Perhaps surprisingly, this can result in more loss than might
+         be necessary.  For example, transformation x could change
+         content form A to content form B; then transformation y changes
+         B to C.  However, it is possible that transformation y might
+         have accepted form A directly and produced form D, which has
+         more of the original information than C.
+
+         NOTE: An originator MAY validate any conversions that are made
+         by requesting a positive [DSNSMTP].  If the DSN request
+         includes the "RET" parameter, the delivery agent SHOULD return
+         an exact copy of the delivered (converted) message content.
+         This will permit the originator to inspect the results of any
+         conversion(s).
+
+3.1.  Sending Permission
+
+   A message originator that permits content conversion by
+   intermediaries MAY use the CONPERM ESMTP service extension and
+   Content-Convert MIME header fields to indicate what conversions are
+   permitted by intermediaries.  Other mechanisms, by which a message
+   originator communicates this permission to the SMTP message transfer
+   service, are outside the scope of this specification.
+
+         NOTE: This option requires that a server make an open-ended
+         commitment to ensure that acceptable conversions are performed.
+         In particular, it is possible that an intermediary will be
+         required to perform conversion, but be unable to do so.  The
+         result will be that the intermediary will be required to
+         perform conversion, but it will be performed in undelivered
+         mail.
+
+   When an ESMTP client is authorized to participate in the CONPERM
+   service, it MUST interact with the next SMTP hop server about:
+
+      *  The server's ability to enforce authorized conversions, through
+         ESMTP CONPERM
+
+      *  The capabilities supported for the target device or system,
+         through ESMTP CONNEG
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                     [Page 9]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   Successful use of CONPERM does not require that conversion take place
+   along the message transfer path.  Rather, it requires that conversion
+   take place when a next-hop server reports capabilities that can be
+   supported on behalf of the recipient (through CONNEG) and that those
+   capabilities do not include support for the current representation of
+   the content.
+
+            NOTE: It is acceptable to have every SMTP server --
+            including the last-hop server -- support CONPERM, with none
+            offering CONNEG.  In this case, the message is delivered to
+            the recipient in its original form.  Any possible
+            conversions to be performed are left to the recipient.
+            Thus, the recipient is given the original form of the
+            content, along with an explicit list of conversions deemed
+            acceptable by the originator.
+
+   An SMTP server MAY offer ESMTP CONPERM, without being able to perform
+   conversions, if it knows conversions can be performed along the
+   remainder of the transfer path, or by the target device or system.
+
+3.2.  Returning Capabilities
+
+   A target recipient device or system arranges announcements of its
+   content form capabilities to the SMTP service through a means outside
+   the scope of this specification.  Note that enabling a server to
+   issue CONNEG information on behalf of the recipient may require a
+   substantial mechanism between the recipient and server.  When an
+   ESMTP server knows a target's capabilities, it MAY offer the CONNEG
+   ESMTP service extension.
+
+            NOTE: One aspect of that mechanism, between the recipient
+            and an ESMTP server offering the CONNEG ESMTP service
+            extension could include offering capabilities beyond those
+            directly supported by the recipient.  In particular, the
+            server -- or other intermediaries between the server and the
+            recipient -- could support capabilities that they can
+            convert to a recipient's capability.  As long as the result
+            is acceptable to the set specified in the relevant Content-
+            Convert header fields of the message being converted, the
+            details of these conversions are part of the
+            recipient/server mechanism, and fall outside the scope of
+            the current specification.
+
+   If a next-hop ESMTP server responds that it supports CONNEG when a
+   message is being processed according to the CONPERM mechanism, then
+   the SMTP client:
+
+      1) MUST request CONNEG information
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 10]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+      2) MUST perform the requisite conversions, if possible, before
+         sending the message to the next-hop SMTP server
+
+      3) MUST fail message processing, if any conversion for the message
+         fails, and MUST return a failure DSN to the originator with
+         status code 5.6.5  (Conversion failed).
+
+   When performing conversions, as specified in Content-Convert MIME
+   header fields, the Client MUST:
+
+      1) Add a Content-Previous header field and a Content-Features
+         header field to each MIME body-part that has been converted,
+         removing any existing Content-Features header fields.
+
+      2) Either:
+
+            *  Send a single copy to the next-hop SMTP server, using the
+               best capabilities supported by all recipients along that
+               path, or
+
+            *  Separate the transfers into multiple, standard
+               RFC2821.Rcpt-To and ESMTP sessions, in order to provide
+               the best conversions possible for subsets of the
+               recipients.
+
+   If the transfers are to be separated, then the current session MUST
+   be terminated, and new sessions conducted for each subset.
+
+   The conversions to be performed are determined by the intersection of
+   three lists:
+
+      *  Conversions permitted by the originator
+
+      *  Content capabilities of the target
+
+      *  Conversions that can be performed by the SMTP client host
+
+   Failed Conversion
+
+      If the result of this intersection is the null set of
+      representations, for an addressee, then delivery to that addressee
+      MUST be handled as a conversion failure.
+
+      If handling is subject to the CONPERM mechanism and:
+
+         *  the next-hop SMTP host does not indicate that it can
+            represent the target's capabilities through CONNEG, but
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 11]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+         *  does respond that it can support CONPERM, then the client
+            SMTP MUST send the existing content, if all other SMTP
+            transmission requirements are satisfied.
+
+      If handling is not subject to the CONPERM mechanism, then
+      conversion failures do not affect message delivery.
+
+3.3.  Next-Hop Non-Support of Service
+
+   If a Client is participating in the CONPERM mechanism, but the next-
+   hop SMTP server does not support CONPERM or CONNEG, then the SMTP
+   client
+
+      1) MUST terminate the session to the next-hop SMTP server, without
+         sending the message
+
+      2) MUST return a DSN notification to the originator, with status
+         code 5.6.3 (Conversion required but not supported).  [DSNSMTP,
+         DSNFMT, SYSCOD]
+
+   If a Client is participating in the CONPERM mechanism and the next-
+   hop SMTP server supports CONNEG, but provides no capabilities for an
+   individual RCPT-TO addressee, then the SMTP client's processing for
+   that recipient MUST be either to:
+
+      1) Treat the addressee as a conversion failure, or
+
+      2) Separate the addressee from the address list that is processed
+         according to CONNEG, and continue to process the addressee
+         according to CONPERM.
+
+4.  Content Conversion Permission SMTP Extension
+
+4.1.  Content Conversion Permission Service Extension Definition
+
+   1) The name of the SMTP service extension is
+
+      "Content-Conversion-Permission"
+
+   2) The EHLO keyword value associated with this extension is
+
+      "CONPERM"
+
+   3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM
+      command.
+
+   4) The server responds with acceptance or rejection of support for
+      CONPERM, for this message.
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 12]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+4.2.  CONPERM Parameter to Mail-From
+
+   Parameter:
+
+      CONPERM
+
+   Arguments:
+
+           There are no arguments.  Specification of permitted
+      conversions is located in a Content-Convert header field for each
+      MIME body-part in which conversion is permitted.
+
+   Client Action:
+
+           If the server issued a 250-CONPERM as part of its EHLO
+      response for the current session, and the client is participating
+      in the CONPERM service for this message -- such as by having
+      received the message with a CONPERM requirement -- then the client
+      MUST issue the CONPERM parameter in the MAIL-FROM.  If the server
+      does not issue 250-CONPERM, and the client is participating in the
+      CONPERM service for this message, then the client MUST treat the
+      transmission as permanently rejected.
+
+   Server Action:
+
+           If the client specifies CONPERM in the MAIL-FROM, but the
+      server does not support the CONPERM parameter, the server MUST
+      reject the MAIL-FROM command with a 504-CONPERM reply.
+
+           If the client issues the CONPERM parameter in the MAIL-FROM,
+      then the server MUST conform to this specification.  Either it
+      MUST relay the message according to CONPERM, or it MUST convert
+      the message according to CONNEG information.
+
+4.3.  Syntax
+
+   Content-Conversion-Permission =    "CONPERM"
+
+5.  Content Negotiation SMTP Extension
+
+5.1.  Content Negotiation Service Extension Definition
+
+   1) The name of the SMTP service extension is:
+
+      "Content-Negotiation"
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 13]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   2) The EHLO keyword value associated with this extension is:
+
+      "CONNEG"
+
+   3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO
+      command.
+
+   4) The server responds with a report indicating the content
+      capabilities that can be received on behalf of the recipient
+      device or system, associated with the target RCPT-TO address.
+
+5.2.  CONNEG Parameter to RCPT-TO
+
+   Parameter:
+
+      CONNEG
+
+   Arguments:
+
+      There are no arguments.
+
+   Client Action:
+
+           If a message is subject to CONPERM requirements and the
+      server issues a 250-CONNEG, as part of its EHLO response for the
+      current session, the client MUST issue the CONNEG parameter in the
+      RCPT-TO request.  If the message is not subject to CONPERM
+      requirements, and the server issues a 250-CONNEG, the client MAY
+      issue the CONNEG parameter with RCPT-TO.
+
+           If the client issues the CONNEG parameter with RCPT-TO, then
+      it MUST honor the capabilities returned in the CONNEG RCPT-TO
+      replies for that message.  In addition, it MUST convert the
+      message content, if the current form of the content is not
+      included in the capabilities listed, on behalf of the recipient.
+
+           The conversions that are performed are determined by the
+      intersection of the:
+
+         *  Conversions permitted by the originator
+
+         *  Content capabilities of the target
+
+         *  Conversions that can be performed by the SMTP client host
+
+      If the result of this intersection is the null set of
+      representations, then the Client processing depends upon whether
+      the next-hop server has offered CONPERM, as well as CONNEG:
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 14]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+         1) If the message will be subject to CONPERM at the next hop,
+            the Client MAY transmit the original content to the next hop
+            and continue CONPERM requirements.
+
+         2) Otherwise, the Client MUST treat the conversion as failed.
+
+           If the result of the intersection is not null, the client
+      SHOULD convert the data to the "highest" level of capability of
+      the server.  Determination of the level that is highest is left to
+      the discretion of the host performing the conversion.
+
+           Each converted MIME body-part MUST have a Content-Previous
+      header field that indicates the previous body-part form and a
+      Content-Features header field, indicating the new body-part form.
+
+   Server Action:
+
+           If the client specifies CONNEG in the RCPT-TO, but the server
+      does not support the CONNEG parameter, the server MUST reject the
+      RCPT-TO addressees with 504 replies.
+
+           If the server does support the CONNEG parameter, and it knows
+      the capabilities of the target device or system, then it MUST
+      provide that information through CONNEG.  The server MAY provide a
+      broader list than is supported by the recipient if the server can
+      ensure that the form of content delivered can be processed by the
+      recipient, while still satisfying the constraints of the author's
+      Content-Convert specification(s).
+
+           The response to a CONNEG RCPT-TO request will be multi-line
+      RCPT-TO replies.  For successful (250) responses, at least the
+      first line of the response must contain RCPT-TO information other
+      than CONNEG.  Additional response lines are for CONNEG.  To avoid
+      problems due to variations in line buffer sizes, the total
+      parametric listing must be provided as a series of lines, each
+      beginning with "250-CONNEG", except for the last line, which is
+      "250 CONNEG".
+
+           The contents of the capability listing MUST conform to the
+      specifications in [SYN] and cover the same range of specifications
+      permitted in [CONMSG].
+
+5.3.  Syntax
+
+      Content-Negotiation =    "CONNEG"
+      Capability =             { <filter> specification,
+                                 as per [SYN] }
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 15]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+6.  MIME Content-Features Header Field
+
+   The Content-Features header field describes the characteristics of
+   the current version of the content for the MIME body-part in which
+   the header field occurs.  There is a separate Content-Features header
+   field for each MIME body-part.  The specification for this header
+   field is contained in [FEAT].
+
+7.  MIME Content-Convert Header Field
+
+   Content-Convert is a header field that specifies preferred
+   conversions for the associated content.  It MAY be used without the
+   other mechanisms defined in this document.  If present, this header
+   field MUST be carried unmodified and delivered to the recipient.  In
+   its absence, the content originator provides no guidance about
+   content conversions, and intermediaries SHOULD NOT perform content
+   conversion.
+
+   In the extended ABNF notation, the Content-Convert header field is
+   defined as follows:
+
+      Convert =                "Content-convert" ":"
+                               permitted
+
+      Permitted =              "ANY" / "NONE" / permitted-list
+
+      permitted-list =         { explicit list of permitted
+                                  final forms, using <filter>
+                                  syntax in [SYN] }
+
+   If the permitted conversions are specified as "ANY", then the
+   intermediary may perform any conversions it deems appropriate.
+
+   If the permitted conversions are specified as "NONE", then the
+   intermediary SHOULD NOT perform any conversions to this MIME body-
+   part, even when the target device or system does not support the
+   original form of the content.
+
+   If a Content-Convert header field is present, then a Content-Features
+   header field MUST also be present to describe the current form of the
+   Content.
+
+8.  MIME Content-Previous Header Field
+
+   When an intermediary has performed conversion of the associated
+   content, the intermediary MUST record details of the previous
+   representation, from which the conversion was performed.  This
+   information is placed in a Content-Previous header field that is part
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 16]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   of the MIME body-part with the converted content.  There is a
+   separate header field for each converted MIME body-part.
+
+   When an intermediary has performed conversion, the intermediary MUST
+   record details of the result of the conversion by creating or
+   revising the Content-Features header field for the converted MIME
+   body-part.
+
+   In the extended [ABNF] notation, the Content-Previous header field is
+   defined as follows:
+
+      previous =          "Content-Previous" [CFWS] ":"
+                          [CFWS]
+                          date by type
+
+      date =              "Date " [CFWS] date-time [CFWS] ";"
+                          [CFWS]
+
+      by =                "By " [CFWS] domain [CFWS] ";"
+                          [CFWS]
+
+      type =              { content characteristics, using
+                            <filter> syntax in [SYN] }
+
+   The Date field specifies the date and time at which the indicated
+   representation was converted into a newer representation.
+
+   The By field specifies the domain name of the intermediary that
+   performed the conversion.
+
+   An intermediary MAY choose to derive the Content-Previous header
+   field, for a body-part, from an already-existing Content-Features
+   header field in that body-part, before that header field is replaced
+   with the description of the current representation.
+
+9.  Examples
+
+9.1.  CONPERM Negotiation
+
+   S: 220 example.com IFAX
+   C: EHLO example.com
+   S: 250- example.com
+   S: 250-DSN
+   S: 250 CONPERM
+   C: MAIL FROM:May@some.example.com CONPERM
+   S: 250 <May@some.example.com> originator ok
+   C: RCPT TO:<June@some.example.com>
+   S: 250-<June@some.example.com> recipient ok
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 17]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   C: DATA
+   S: 354 okay, send data
+   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
+      Per:
+      (  image-file-structure=TIFF-minimal
+         dpi=400
+         image-coding=JBIG
+         size-x=2150/254
+         paper-size=letter
+      )
+      with MIME body-parts including:
+      Content-Convert:
+         (&(image-file-structure=TIFF-minimal)
+           (MRC-mode=0)
+           (color=Binary)
+           (|(&(dpi=204)
+               (dpi-xyratio=[204/98,204/196]) )
+             (&(dpi=200)
+               (dpi-xyratio=[200/100,1]) )
+             (&(dpi=400)
+               (dpi-xyratio=1) ) )
+           (|(image-coding=[MH,MR,MMR])
+             (&(image-coding=JBIG)
+               (image-coding-constraint=JBIG-T85)
+               (JBIG-stripe-size=128) ) )
+           (size-x<=2150/254)
+           (paper-size=[letter,A4])
+           (ua-media=stationery) )
+      >>
+   S: 250 message accepted
+   C: QUIT
+   S: 221 goodbye
+
+9.2.  Example CONNEG Negotiation
+
+   S: 220 example.com IFAX
+   C: EHLO example.com
+   S: 250- example.com
+   S: 250-DSN
+   S: 250 CONNEG
+   C: MAIL FROM:<May@some.example.com>
+   S: 250 <May@some.example.com> originator ok
+   C: RCPT TO:<June@ifax1.jp> CONNEG
+   S: 250-<June@some.example.com> recipient ok
+   S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
+   S: 250-CONNEG   (MRC-mode=0)
+   S: 250-CONNEG   (color=Binary)
+   S: 250-CONNEG   (|(&(dpi=204)
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 18]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
+   S: 250-CONNEG     (&(dpi=200)
+   S: 250-CONNEG       (dpi-xyratio=[200/100,1]) ) )
+   S: 250-CONNEG   (image-coding=[MH,MR,MMR])
+   S: 250-CONNEG   (size-x<=2150/254)
+   S: 250-CONNEG   (paper-size=[letter,A4])
+   S: 250 CONNEG   (ua-media=stationery) )
+   C: DATA
+   S: 354 okay, send data
+   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
+        Per:
+        (  image-file-structure=TIFF-minimal
+           dpi=400
+           image-coding=JBIG
+           size-x=2150/254
+           paper-size=letter
+         )
+      >>
+   S: 250 message accepted
+   C: QUIT
+   S: 221 goodbye
+
+9.3.  Content-Previous
+
+   Content-Previous:
+      Date  Tue, 1 Jul 2001 10:52:37 +0200;
+      By    relay.example.com;
+      (&(image-file-structure=TIFF-minimal)
+        (MRC-mode=0)
+        (color=Binary)
+        (&(dpi=400)
+          (dpi-xyratio=1) )
+        (&(image-coding=JBIG)
+          (image-coding-constraint=JBIG-T85)
+          (JBIG-stripe-size=128) )
+        (size-x=2150/254)
+        (paper-size=A4)
+        (ua-media=stationery) )
+
+10.  Security Considerations
+
+   This service calls for disclosure of capabilities, on behalf of
+   recipients.  Mechanisms for determining the requestor's and the
+   respondent's authenticated identity are outside the scope of this
+   specification.  These mechanisms are intended to permit disclosure of
+   information that is safe for public distribution; hence, there is no
+   inherent need for security measures.
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 19]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   Information that should have restricted distribution is still able to
+   be disclosed.  Therefore, it is the responsibility of the disclosing
+   ESMTP server or disclosing ESMTP client to determine whether
+   additional security measures should be applied to the use of this
+   ESMTP option.
+
+   Use of the ESMTP CONNEG option permits content transformation by an
+   intermediary, along the mail transfer path.  When the contents are
+   encrypted, the intermediary cannot perform the conversion, because it
+   is not expected to have access to the relevant secret keying
+   material.  When the contents are signed, but not encrypted,
+   conversion will invalidate the signature.  This specification
+   provides for potentially unbounded computation by intermediary MTAs,
+   depending on the nature and amount of conversion required.  Further,
+   this computation burden might provide an opportunity for denial-of-
+   service attacks, given that Internet mail typically permits
+   intermediaries to receive messages from all Internet sources.
+
+   This specification provides for content conversion by unspecified
+   intermediaries.  Use of this mechanism carries significant risk.
+   Although intermediaries always have the ability to perform damaging
+   transformations, use of this specification could result in more
+   exploration of that potential and, therefore, more misbehavior.  Use
+   of intermediaries is discussed in [RFC3238].
+
+   CONPERM/CONNEG provide a cooperative mechanism, rather than enabling
+   intermediary actions that were not previously possible.
+   Intermediaries already make conversions on their own initiative.
+   Hence, the mechanism introduces essentially no security concerns,
+   other than divulging recipient preferences.
+
+11.  Acknowledgements
+
+   Graham Klyne and Eric Burger provided extensive, diligent reviews and
+   suggestions.  Keith Moore, Giat Hana, and Joel Halpern provided
+   feedback that resulted in improving the specification's integration
+   into established email practice.
+
+12.  References
+
+12.1.  Normative References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 20]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   [CONMSG]   Klyne, G., Iwazaki, R., and D. Crocker, "Content
+              Negotiation for Messaging Services based on Email", RFC
+              3297, July 2002.
+
+   [DSNSMTP]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
+              Extension for Delivery Status Notifications (DSNs)", RFC
+              3461, January 2003.
+
+   [DSNFMT]   Moore, K. and G. Vaudreuil, "An Extensible Message Format
+              for Delivery Status Notifications", RFC 3464, January
+              2003.
+
+   [SYSCOD]   Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+              3463, January 2003.
+
+   [ESMTP1]   Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
+              Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+              November 1995.
+
+   [ESMTP2]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [FEAT]     Klyne, G., "Indicating Media Features for MIME Content",
+              RFC 2912, September 2000.
+
+   [IMF]      Resnick, P., "Internet Message Format", RFC 2822, April
+              2001.
+
+   [SYN]      Klyne, G., "A Syntax for Describing Media Feature Sets",
+              RFC 2533, March 1999.
+
+   [MEDTYP]   IANA, "MIME Media Types",
+              <http://www.iana.org/assignments/media-types>
+
+   [CFWS]     Alvestrand, H., "Content Language Headers", RFC 3282, May
+              2002.
+
+12.2.  Informative References
+
+   [RFC3238]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
+              Considerations for Open Pluggable Edge Services", RFC
+              3238, January 2002.
+
+
+
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 21]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+Appendix A.  CONNEG with Direct SMTP
+
+   This Appendix is descriptive.  It only provides discussion of usage
+   issues permitted or required by the normative text
+
+   In some configurations, it is possible to have direct, email-based
+   interactions, where the originator's system conducts a direct,
+   interactive TCP connection with the recipient's system.  This
+   configuration permits a use of the content form negotiation service
+   that conforms to the specification here, but permits some
+   simplifications.  This single SMTP session does not have the
+   complexity of multiple, relaying sessions and therefore does not have
+   the requirement for propagating permissions to intermediaries.
+
+   The Originator's system provides user-level functions for the
+   originator, and it contains the SMTP Client for sending messages.
+   Hence, the formal step of email "posting" is a process that is
+   internal or virtual, within the Originating system.  The recipient's
+   service contains the user-level functions for the recipient, and
+   contains the SMTP server for receiving messages.  Hence, the formal
+   steps of email "delivering" and "receipt" are internal or virtual,
+   within the Receiving system.
+
+                    Figure 4: DIRECT CONNEG
+
+         Originating system          Receiving system
+        +------------------+       +------------------+
+        |  +------------+  |       |   +-----------+  |
+        |  | Originator |  |       |   | Recipient |  |
+        |  +------------+  |       |   +-----------+  |
+        |       ||Posting  |       |      /\Receiving |
+        |       \/         |       |      ||          |
+        |   +---------+    |       |    +--------+    |
+        |   |  SMTP   |<---|-------|----|  SMTP  |    |
+        |   | Client  |----|-------|--->| Server |    |
+        |   +---------+    |       |    +--------+    |
+        +------------------+       +------------------+
+
+   In this case, CONPERM is not needed because the SMTP Client is part
+   of the originating system and already has the necessary permission.
+   Similarly, the SMTP server will be certain to know the recipient's
+   capabilities, because the server is part of the receiving system.
+
+   Therefore, Direct Mode email transmission can achieve content
+   capability and form matching by having:
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 22]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+      *  Originating systems that conform to this specification and a
+         communication process between originator and recipient that is
+         the same as would take place between a last-hop SMTP Relay and
+         the Delivering SMTP server to which it is connected.
+
+      *  That is, the Client and Server MUST employ CONNEG and the
+         Client MUST perform any requisite conversions.
+
+Appendix B.  Using Combinations of the Extensions
+
+   This specification defines a number of mechanisms.  It is not
+   required that they all be used together.  For example, the difference
+   between listing preferred conversions -- versus specifying enforced
+   limitations to conversions -- is discussed in the Introduction.  This
+   Appendix further describes scenarios that might call for using fewer
+   than the complete set defined in this specification.  It also
+   summarizes the conditions which mandate that an intermediary perform
+   conversion.
+
+   This Appendix is descriptive.  It only provides discussion of usage
+   issues permitted or required by the normative text
+
+   The available mechanisms are:
+
+      1. CONPERM Parameter to Mail-From
+      2. CONNEG parameter to RCPT-TO
+      3. MIME Content-Convert Header Field
+      4. MIME Content-Previous Header Field
+      5. MIME Content-Features Header Field
+
+B.1.  Specifying Suggested Conversion Constraints
+
+   Use of the MIME Content-Convert header field specifies the
+   originator's preferences, should conversion be performed.  This does
+   not impose any requirements on the conversion; it is merely advisory.
+
+B.2.  Specifying Required Conversion Constraints
+
+   When the MIME Content-Convert specification is coupled with the ESMTP
+   CONPERM option, then the originator's specification of preferred
+   conversions rises to the level of requirement.  No other conversions
+   are permitted, except those specified in the Content-Convert header
+   field.
+
+      Note that the presence of both mechanisms does not require that
+      conversions be performed.  Rather, it constrains conversions,
+      should they occur.
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 23]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+B.3.  Accepting All Forms of Content
+
+   Although it is unlikely that any device will always able to process
+   every type of existing content, some devices can be upgraded easily
+   (e.g., adding plug-in).  Hence, such a device is able to process all
+   content effectively.
+
+   For such devices, it is better to refrain from issuing a CONNEG
+   assertion.  Instead, the CONPERM request should be propagated to the
+   target device.
+
+B.4.  When Conversion is Required
+
+   A node is required to perform conversion when:
+
+      1. At least one MIME Content-Covert header field is present in the
+         message,
+
+      2. ESMTP CONPERM is in force at the node processing the message,
+
+      3. ESMTP CONNEG is also in force at the same node,
+
+      4. The current content form is not cited in the CONNEG list,
+
+      5. At least one content form is present, both in the Content-
+         Convert list and the CONNEG list, and
+
+      6. The intermediary is able to convert from the current form to
+         one of the forms listed in both Content-Convert and CONNEG.
+
+Appendix C.  MIME Content-Type Registrations
+
+C.1.  Content-Convert
+
+   Header field name:
+      Content-Convert
+
+   Applicable protocol:
+      Mail (RFC 2822)
+
+   Status:
+      Proposed Standard
+
+   Author/Change controller:
+      IETF
+
+   Specification document(s):
+      RFC 4141.
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 24]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+   Related information:
+      None.
+
+C.2.  Content-Previous
+
+   Header field name:
+      Content-Previous
+
+   Applicable protocol:
+      Mail (RFC 2822)
+
+   Status:
+      Proposed Standard
+
+   Author/Change controller:
+      IETF
+
+   Specification document(s):
+      RFC 4141, Section 8
+
+   Related information:
+      None.
+
+Authors' Addresses
+
+   Kiyoshi Toyoda
+   Panasonic Communications Co., Ltd.
+   4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
+
+   EMail: toyoda.kiyoshi@jp.panasonic.com
+
+
+   Dave Crocker
+   Brandenburg InternetWorking
+   675 Spruce Drive
+   Sunnyvale, CA  94086  USA
+
+   Phone: +1.408.246.8253
+   EMail: dcrocker@bbiw.net
+
+
+
+
+
+
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 25]
+
+RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Toyoda & Crocker            Standards Track                    [Page 26]
+