Network Working Group K. Toyoda / PCC Draft
D. Crocker / Brandenburg
draft-ietf-fax-esmtp-conneg-13.txt January 2005
Expires: <06-05>
SMTP and MIME Extensions
For Content Conversion
STATUS OF THIS MEMO
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2003). All Rights
Reserved.
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 a related form,
with the same or constrained information, such as
changing from color to black and white. In a store-
and-forward environment, it can be convenient to have
this conversion performed by an intermediary. This
specification integrates two ESMTP extensions and
three MIME content headers, defining a cooperative
service that permits authorized, accountable content
form conversion by intermediaries.
CONTENTS
1. Introduction
1.1. Background
1.2. Overview
1.3. Notational Conventions
2. Applicability
3. Service Specification
3.1. Sending Permission
3.2. Returning Capabilities
3.3. Next-Hop Non-Support of Service
4. Content Conversion Permission SMTP Extension
4.1. Content Conversion Permission Service Extension
Definition
4.2. CONPERM Parameter to Mail-From
4.3. Syntax
5. Content Negotiation SMTP extension
5.1. Content Negotiation Service Extension Definition
5.2. CONNEG parameter to RCPT-TO
5.3. Syntax
6. MIME Content-Features Header
7. MIME Content-Convert Header
8. MIME Content-Previous Header
9. Examples
8.1. CONPERM Negotiation
8.2. Example CONNEG Negotiation
8.3. Content-Previous
10. IANA Considerations
11. Security Considerations
12. Acknowledgements
13. References
14. Authors' Addresses
15. Intellectual Property Statement
16. Full Copyright Statement
Appendix A: CONNEG with Direct SMTP
Appendix B. USING Combinations of the Extensions
1. INTRODUCTION
Internet specifications typically define common
capabilities that are supported by all participants
for a particular service. This permits sending basic
data without needing to know the additional
capabilities supported by individual recipients.
However, knowing those capabilities permits sending
additional types of data and data of enhanced richness.
Otherwise, a message originator is faced with sending
content in a form the recipient cannot process or with
sending 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.
1.1. Background
MIME enables distinguishing and labeling different
types of content. However an email originator cannot know
whether a recipient is able to support (interpret) any
particular data type. In order to permit basic use of
MIME, a minimum set of data types are specified as its
support base. How is an originator to know whether a
recipient can support any other types?
A mechanism for describing MIME types is specified in
[FEAT]. A mechanism that permits an originator to query
a recipient about the types it supports, by using email
messages for the control exchange, is specified in
[CONMSG]. In particular, this permits a recipient to
propagate information about its capabilities back to an
originator. Obviously, using end-to-end email messages
for the control exchange introduces considerable
latency and some unreliability.
An alternative approach is for an originator to use the
"best" form of data that it can, to include the same types
of permitted representation information used in [CONMSG],
and hope that the recipient, or an intermediary, can translate
this into a form that is 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.
1.2. Overview
An originator describes desirable content forms, in
MIME content descriptors. It further may give
"permission", to any intermediary or the recipient, to
convert the content to only 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 message content to a
form that is both supported by the target system and is
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 is performing the conversions. This
is made more complex by needing to distinguish between
such directions being merely advisory, versus having
them intended as requirements. Conversions that are
specified as advisory are performed if possible, but
they do not alter message delivery. In contrast,
conversion specifications that are treated as a
requirement prohibit delivery if the recipient will be
unable to process the content.
These possibilities interact to form different
processing scenarios, in the event 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. Hence, information on behalf of the recipient
is used to guide the details of conversion, but not to
decide whether to deliver the message.
This is intended to continue 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 the 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 headers (Content-Convert, Content-
Previous and Content-Features) that specify appropriate
content headers and record conversions that have been
performed.
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 that can be
derived from the original, but that the device cannot render
the original form.
The mechanism can impose significant resource requirements on
an intermediary doing 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 headers, 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.
An originator specifies preferred content-types through
the Content-Convert MIME content header. The content
headers 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 that can
be supported on behalf of 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 [DSN,
DSNFMT, DSNCOD] 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
headers 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. If the
originator includes a Content-Convert header, then they must
also include a Content-Feature header, to describe the current
form of the content. Intermediaries MAY interpret the presence of
this header as authorization to perform conversions. When
Content- Convert headers are the sole means for guiding
conversions by intermediaries, then they serve only as
advisories. In particular, failure to satisfy the
guidance of these headers does not affect final delivery.
The originator MAY also specify transit-service
enforcement of conversion limitations by using the
ESMTP CONPERM service extension when posting a new
message. Conversions MUST be limited to those
specified in MIME Content-Convert headers, in each of
the MIME body-parts for which conversion is authorized.
If conversion is needed, but an authorized conversion
cannot be performed, then the message is returned to
the originator. If CONPERM is not used, then failure
to perform an authorized conversion does 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. Therefore they
are issued through the ESMTP MAIL-FROM request. CONNEG
response 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 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 headers. The current form of the
content is described in MIME Content-Features headers.
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 and other 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 CONPERM or MAY re-
initiate CONPERM use, when they have knowledge about
possible variations in 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
otherwise be necessary. For example, transformation x could
change content form A to content form B, and then
transformation y change B to C. However it is possible that
transformation y could 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 [DSN]. 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 headers 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 be required to perform conversion but be
unable to do so. This will result intermediary will be
required to perform conversion but will be 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
Successful use of CONPERM does not require that
conversion take place along the message transfer path.
Rather, it requires that conversion take place whenever
a next-hop server reports capabilities that can be supported on
behalf of the recipient, through CONNEG, and 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. Hence the recipient is given the original
form of the content, along with an explicit list of
conversions that the originator deems acceptable.
An SMTP server MAY offer ESMTP CONPERM, without being
able to perform conversions, if it knows that
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 announcement 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 substantial mechanism between the
recipeint and the 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 that are 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 headers of the message being converted, the details
of these conversions are part of the recipient/server
mechanism that is outside the scope of the current
specification.
When a message is being processed according to the
CONPERM mechanism, if a next-hop ESMTP server responds
that it supports CONNEG, then the SMTP client:
(1) MUST request CONNEG information
(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 headers, the Client MUST:
(1) Add a Content-Previous header and a Content-Features
header to each MIME body-part that has been converted.
removing any existing Content-Features header.
(2) Either:
* Send a single copy to the next-hop SMTP server, using a
best capabilities that are supported to 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 that are 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
* 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
and does not support 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). [DSN,
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.
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 for each MIME body-part for 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"
(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, and 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:
(1) If the message will be subject to CONPERM at the next
hop, the Client MAY to transmit the original content
to the next hop, continuing 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 that indicates the previous body-part
form and a Content-Features header, 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
simply supported by the recipient, if the server can
ensure that the form of content finally 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 is
for RCPT-TO information other than CONNEG. Additional
response lines are for CONNEG. In order 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 covers the
same range of specifications permitted in [CONMSG].
5.3. Syntax
Content_Negotiation = "CONNEG"
Capability = <<as per [SYN]>>
6. MIME CONTENT-FEATURES HEADER
The Content-Features header describes the characteristics
of the current version of the content for the MIME
body-part in which the header occurs. There is a separate
Content-Features header for each MIME body-part.
The specification for this header is contained in
[FEAT].
7. MIME CONTENT-CONVERT HEADER
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 MUST be carried unmodified and
delivered to the recipient. In its absence the content
originator has provided 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 conversions, per
[SYN] RFC2533.Filter syntax>>
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 is present, then a Content-
Features header MUST also be present, to describe the
current form of the Content.
8. MIME CONTENT-PREVIOUS HEADER
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 that is part of the
MIME body-part with the converted content. There is
a separate header for each, converted MIME body-part.
When an intermediary has performed conversion, the
intermediary MUST record details of the result of the
conversion that was performed, by creating or revising
the Content-Features header for the MIME body-part that
was converted.
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, per
[SYN], without alternatives>>
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, for a body-part, from an already-
existing Content-Features header in that body-part,
before that header 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
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)
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. IANA CONSIDERATIONS
There are no IANA considerations regarding this document.
11. 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. It is
intended that these mechanisms permit disclosure of
information that can safely be public; hence there is
no inherent need for security measures.
Information that should receive restricted distribution
is still able to be disclosed. It is, therefore, 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, since 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 upon 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 have not previously been
possible. Intermediaries already can and do make conversions
on their own initiative. Hence the mechanism introduces
essentially no security concerns, other than divulging
recipient preferences.
12. 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.
13. REFERENCES
Normative:
[ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC2119, March 1997
[CONMSG] Klyne, G., Iwazaki, R., Crocker. D., ,
"Content Negotiation for Messaging
Services based on Email", RFC 3297, July
2002.
[DISP] Masinter, L., Holtman, K., Mutz, A. and
D. Wing, "Media Features for Display,
Print, and Fax", RFC 2534, March 1999.
[DSN] Moore, K. "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status
Notifications (DSNs)", RFC 3461, January 2003
[DSNFMT] K. Moore and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications",
RFC 3464, January 2003.
[DSNSMTP] Moore, K. "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)",RFC 3461, January 2003
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status
Codes", RFC3463, January 2003.
[ESMTP1] Klensin, J., Freed, N., Rose, M.,
Stefferud, E. and D. Crocker, "SMTP
Service Extensions", 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
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
[TAG] Holtman, K., Mutz, A. and T. Hardie,
"Media Feature Tag Registration
Procedure", RFC 2506, March 1999.
[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>
Informative:
[RFC3238] Floyd, S., Daigle, L., "IAB Architectural
and Policy Considerations for Open Pluggable
Edge Services", RFC 3238, January 2002
14. AUTHORS' ADDRESSES
Kiyoshi Toyoda
Panasonic Communications Co., Ltd.
4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
toyoda.kiyoshi@jp.panasonic.com
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
Tel: +1.408.246.8253
dcrocker@bbiw.net
15. INTELLECTUAL PROPERTY STATEMENT
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
16. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (year). 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.
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 it 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. Therefore it
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:
* 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 it connects to.
* 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 some scenarios
which might call for using fewer than the complete set that is
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
4. MIME Content-Previous Header
5. MIME Content-Features Header
B.1 Specifying Suggested Conversion Constraints
Use of the MIME Content-Convert header specifies the originator's
preferences, should conversion be performed. This does not impose
any requirements on the conversion, but instead 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.
Note that the presence of both these mechanisms does not require
that conversions be performed. Rather, it constrains conversions,
should they occur.
B.3 Accepting All Forms of Content
Although it is unlikely that any device is always able to process
every type of existing content, some devices can be upgraded
easily, such as by adding plug-in. Hence such a device
effectively is able to process all content.
For such devices, it is better to refrain from issuing a CONNEG
assertion. Instead, the CONPERM request should be propagated all
the way 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 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.
Datatracker
Report a datatracker bug
draft-ietf-fax-esmtp-conneg-13
Proposed Standard
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4141.
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors |
Dave Crocker
,
Kiyoshi Toyoda
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | Proposed Standard | ||
| Other formats | |||
| Additional resources | Mailing list discussion |