Network Working Group K. Toyoda, MGCS
Internet Draft D. Crocker, Brandenburg
draft-ietf-fax-esmtp-conneg-04.txt Feb 2003
Expires: <7-03>
SMTP Service Extensions
for Fax Content Negotiation
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of
RFC2026. 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 (2003). All Rights
Reserved.
SUMMARY
A message originator sometimes wishes to send content
that is in a form the recipient cannot process. In
order for the recipient to process the content, the
content must be converted to a related form, with the
same or with restricted 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.
CONTENTS
1. Introduction
2. Conventions
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-CONVERT Header
7. MIME Content-Converted Header
8. EXAMPLES
8.1. CONPERM Negotiation
8.2. Example CONNEG Negotiation
8.3. Content-Converted
9. IANA Considerations
10. Security Considerations
11. Acknowledgements
12. References (Normative)
13. AuthorsÆ Addresses
14. Full Copyright Statement
Appendix A: CONNEG with Direct SMTP
1. INTRODUCTION
A message originator sometimes wishes to send content
that is in a form the recipient cannot process. This
specification enables MIME content conversion on behalf
of a message originator and a message recipient. It
defines a means of matching message content form to the
capabilities of a recipient device or system, through
an SMTP-based negotiation mechanism. An SMTP client is
given permission by an email originator to request and
use information about content capabilities of the
target device or system that is serviced by an SMTP
server. An SMTP server reports the targetÆs content
capabilities back to the SMTP client, and the client is
then able to convert message content to a form that is
supported by the target device or system.
This specification provides mechanisms to support such
a conversion service, through an ESMTP hop-by-hop
service. It uses two SMTP service extensions: CONPERM
and CONNEG, and two MIME Content headers: Content-
Conversion and Content-Converted
An example email relay environment is shown here:
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+
SMTP host permission to perform specified content
conversions is communicated by message senders, through
the ESMTP CONPERM service extension and MIME Content-
Conversion headers. Target device or system
capabilities are communicated in SMTP sessions through
the ESMTP CONNEG service extension.
Conversions are performed by the first ESMTP host that
can obtain both the senderÆs permission and the
recipientÆs capabilities. When an SMTP relay or
server performs content conversion, it records which
specific conversions are made, into Content-Converted
MIME headers associated with each, converted MIME body-
part.
[[EditorÆs note: The specification does not
provide for sending an MDN back to the originator,
when a conversion is performed. Without
CONPERM/CONNEG, conversions are performed by the
recipient. Therefore it is acceptable to ensure
that the recipient, rather than the originator, is
informed of conversions. This is achieved with
Content-Converted. Informing the Originator of
conversions could generate a substantial increase
in email control traffic. Note that conversion by
a recipient does not currently result in
notification of the originator.]]
When 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] to the
originator.
2. 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].
3. SERVICE SPECIFICATION
This service integrates two ESMTP extensions and two
MIME content-types, 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.
Authorization is provided to intermediaries by the
originator, through ESMTP CONPERM. Authorized
conversions are specified in MIME Content-Convert
headers. Recipient capabilities are communicated to
intermediaries by ESMTP CONNEG, and a record of
conversions is placed into MIME Content-Converted
headers.
CONPERM and CONNEG operate on a per-message basis.
Therefore they are issued through the ESMTP MAIL-FROM
and RCPT-TO request. CONNEG response information is
provided on a per-recipient basis, through the response
to ESMTP RCPT-TO.
Conversion is performed by the first intermediary that
obtains recipient capability information. When an
intermediary obtains different capability information
for different recipients of the same message, it has
the choice of creating a single, converted copy of the
content that can be supported by all of the recipients,
or it can create multiple converted copies, each
version sent separately, and matching a subset of the
recipients.
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 required when the permissible conversions
are the null set. However, rather than simply failing
transmission to the recipients for which there is no
capability information, the intermediary MAY choose to
send the original content to those recipients, via the
CONPERM mechanism.
3.1. Sending Permission
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+
A message originator that permits content conversion by
intermediaries MAY use the CONPERM ESMTP service
extension and Content-Conversion 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.
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 support authorized conversions,
through ESMTP CONPERM
* The capabilities supported for the target device or
system, through ESMTP CONNEG
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+
3.2. Returning Capabilities
A target recipient device or system communicates its
capabilities to the SMTP service through a means
outside the scope of this specification. When an ESMTP
server knows a targetÆs capabilities, it MAY offer the
CONNEG ESMTP service extension.
When a message is being processed according to this
specification, 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 before sending
the message to the next-hop SMTP server
(3) MUST add a Content-Converted header to each MIME body-
part that has been converted and must specify the previous
form of the body-part and the current form.
When performing conversions, the Client MUST either:
(1) Send a single copy to the next-hop SMTP server, using a
best capabilities that are supported to all recipients along
that path, or
(2) Separate the transfers, to provide the best conversions
possible for subsets of the recipient.
If the transfers are 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 sender
* 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, for an addressee, then delivery to
that addressee MUST be handled as a failure.
If 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.
3.3. Next-Hop Non-Support of Service
If a Client is participating in this service, 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 that
content negotiation could not be performed.
If a Client is participating in this service 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 rejected, 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-
Conversion 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 of the content
capabilities of the device or system that embodies each
target RCPT-TO address.
5.2. CONNEG parameter to RCPT-TO
Parameter:
CONNEG
Arguments:
There are no arguments.
Client Action:
If 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 specified
in the CONNEG RCPT-TO replies for that message, and
convert the message content, so that the target can
accept the data.
The conversions that are performed are determined
by the intersection of the:
* Conversions permitted by the sender
* 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 message is subject to CONPERM
processing:
(1) If the message is subject to CONPERM, the Client MAY
continue to transmit the original content, according to
CONPERM.
(2) Otherwise, the Client MUST treat the address as
rejected.
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
server.
The client MUST record the nature of the
conversion by using the MIME Content-Converted header
for each converted MIME body-part, indicating the
previous and 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 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 [FAX].
5.3. Syntax
Content_Negotiation = "CONNEG"
Capability = <<as per [FAX]>>
6. MIME CONTENT-CONVERT HEADER
Content-Convert is an optional header field that
specifies permitted conversions for the associated
content. In its absence, the content originator has
provided no guidance about content conversions.
Therefore intermediaries SHOULD NOT perform content
conversion.
It is desirable to keep the set of possible disposition
types small and well defined, to avoid needless
complexity. Even so, evolving usage will likely require
the definition of additional disposition types or
parameters, so the set of disposition values is
extensible; see below.
In the extended ABNF notation, the Content-Convert
header field is defined as follows:
Convert = "Content-convert" ":"
permitted
Permitted = "ANY" / <<permitted
conversions, per [FAX]>>
If the permitted conversions are specified as "ANY"
then the intermediary may perform any conversions it
deems appropriate.
7. MIME CONTENT-CONVERTED HEADER
When an intermediary has performed conversion of the
associated content, the intermediary MUST record the
nature of the conversion that was performed. This
information is placed in a Content-Converted header
associated with the converted content.
In the extended ABNF notation, the Content-Converted
header field is defined as follows:
converted = "Content-converted" [CFWS] ":"
[CFWS]
"Date " [CFWS] date-time [CFWS]";"
[CFWS]
"By " [CFWS] domain [CFWS]";"
[CFWS]
"Old " [CFWS] type [CFWS]";" [CFWS]
"New " [CFWS] type [CFWS]
domain = <<Per [IMF], domain name of
intermediary that performed
conversion>>
date-time = <<Per [IMF], date and time at which
conversion was performed>>
type = <<content characteristics, per
[FAX], without alternatives>>
8. EXAMPLES
8.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> sender 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
8.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> sender 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
8.3. Content-Converted
Content-converted:
Date Tue, 1 Jul 2001 10:52:37 +0200 ;
By relay.example.com ;
Old
(&(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) ) ;
New
(&(image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(&(dpi=200)
(dpi-xyratio=1) )
(image-coding=MMR)
(size-x=2150/254)
(paper-size=letter)
(ua-media=stationery) )
9. IANA CONSIDERATIONS
This memo is not intended to create any new issues for
IANA.
10. SECURITY CONSIDERATIONS
This service calls for participants to disclose their
capabilities. 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
public information; hence there is no particular need
for security measures.
However there is nothing to prevent disclosure of
sensitive information that should receive restricted
distribution. 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.
11. ACKNOWLEDGEMENTS
Graham Klyne and Eric Burger provided diligent review
and useful suggestions.
12. REFERENCES (NORMATIVE)
[DISPLAY] Masinter, L., Holtman, K., Mutz, A. and
D. Wing, "Media Features for Display,
Print, and Fax", RFC 2534, March 1999.
[DSN] Moore, K., "SMTP Service Extension for
Delivery Status Notifications", RFC
1892, January 1996.
[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.
[FAX] McIntyre, L. and G. Klyne, "Content
Feature Schema for Internet Fax", RFC
2879, August 2000
[IMF] Resnick, P., "Internet Message Format",
RFC 2822, April 2001
[TAG] Holtman, K., Mutz, A. and T. Hardie,
"Media Feature Tag Registration
Procedure", RFC 2506, March 1999.
[SETS] Klyne, G., "A syntax for describing
media feature sets", RFC 2533, March
1999.
13. AUTHORSÆ ADDRESSES
Kiyoshi Toyoda
Network Technology Development Center
Panasonic Communications Co., Ltd.
2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan
tel: +81-3-5434-7161
fax: +81-3-5434-7156
toyoda.kiyoshi@jp.panasonic.com
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
Tel: +1.408.246.8253
dcrocker@brandenburg.com
14. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and
derivative works. However, this document itself may
not be modified in any way, such as by removing the
copyright notice or references to the Internet Society
or other Internet organizations, except as needed for
the purpose of developing Internet standards in which
case the procedures for copyrights defined in the
Internet Standards process must be followed, or as
required to translate it into languages other than
English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
APPENDIX A: CONNEG WITH DIRECT SMTP
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 CONPERM/CONNEG that conforms to the
specification here, but it also permits some
simplifications, because there is a single SMTP
session, rather than multiple, relaying sessions.
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.
The figure below shows these relationships:
Originating system Receiving system
+------------------+ +-----------------+
| +------------+ | | +-----------+ |
| | Originator | | | | Recipient | |
| +------------+ | | +-----------+ |
| ||Posting | | /\Receipt |
| \/ | | || |
| +---------+ | | +--------+ |
| | 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.
* For Originating systems that conform to this
specification and are operating in a Direct SMTP mode, the
communication process between originator and recipient is
the same as would take place between the last-hop SMTP Relay
and the Delivering SMTP server. That is, the Client and
Server MUST employ CONNEG and the Client MUST perform any
requisite conversions.
Datatracker
Report a datatracker bug
draft-ietf-fax-esmtp-conneg-04
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4141.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |