idnits 2.17.1 draft-ietf-fax-esmtp-conneg-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 38), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1236 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 294: '... content MUST ensure that the resu...' RFC 2119 keyword, line 295: '...d. Otherwise it MUST NOT perform conv...' RFC 2119 keyword, line 303: '.... Intermediaries MAY interpret the pre...' RFC 2119 keyword, line 310: '... The originator MAY also specify tran...' RFC 2119 keyword, line 313: '...ge. Conversions MUST be limited to th...' (52 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 911 has weird spacing: '... By rel...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7043 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CONMSG' on line 987 looks like a reference -- Missing reference section? 'FEAT' on line 1015 looks like a reference -- Missing reference section? 'KEYWORDS' on line 984 looks like a reference -- Missing reference section? 'DSN' on line 995 looks like a reference -- Missing reference section? 'DSNFMT' on line 998 looks like a reference -- Missing reference section? 'DSNCOD' on line 284 looks like a reference -- Missing reference section? 'MEDTYP' on line 1029 looks like a reference -- Missing reference section? 'SYN' on line 1027 looks like a reference -- Missing reference section? 'ABNF' on line 982 looks like a reference -- Missing reference section? 'RFC3238' on line 1033 looks like a reference -- Missing reference section? 'DISP' on line 992 looks like a reference -- Missing reference section? 'DSNSMTP' on line 1001 looks like a reference -- Missing reference section? 'SYSCOD' on line 1021 looks like a reference -- Missing reference section? 'ESMTP1' on line 1008 looks like a reference -- Missing reference section? 'ESMTP2' on line 1013 looks like a reference -- Missing reference section? 'IMF' on line 1019 looks like a reference -- Missing reference section? 'TAG' on line 1024 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Toyoda / PCC Draft 2 D. Crocker / Brandenburg 3 draft-ietf-fax-esmtp-conneg-12.txt December 2004 4 Expires: <02-05> 6 SMTP and MIME Extensions 7 For Content Conversion 9 STATUS OF THIS MEMO 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 COPYRIGHT NOTICE 37 Copyright (C) The Internet Society (2003). All Rights 38 Reserved. 40 ABSTRACT 42 A message originator sometimes sends content in a form 43 the recipient cannot process or would prefer not to 44 process a form of lower quality than is preferred. 45 Such content needs to be converted to a related form, 46 with the same or constrained information, such as 47 changing from color to black and white. In a store- 48 and-forward environment, it can be convenient to have 49 this conversion performed by an intermediary. This 50 specification integrates two ESMTP extensions and 51 three MIME content headers, defining a cooperative 52 service that permits authorized, accountable content 53 form conversion by intermediaries. 55 CONTENTS 56 1. Introduction 57 1.1. Background 58 1.2. Overview 59 1.3. Conventions 60 2. Applicability 61 3. Service Specification 62 3.1. Sending Permission 63 3.2. Returning Capabilities 64 3.3. Next-Hop Non-Support of Service 65 4. Content Conversion Permission SMTP Extension 66 4.1. Content Conversion Permission Service Extension 67 Definition 68 4.2. CONPERM Parameter to Mail-From 69 4.3. Syntax 70 5. Content Negotiation SMTP extension 71 5.1. Content Negotiation Service Extension Definition 72 5.2. CONNEG parameter to RCPT-TO 73 5.3. Syntax 74 6. MIME Content-Features Header 75 7. MIME Content-Convert Header 76 8. MIME Content-Previous Header 77 9. Examples 78 8.1. CONPERM Negotiation 79 8.2. Example CONNEG Negotiation 80 8.3. Content-Previous 81 10. IANA Considerations 82 11. Security Considerations 83 12. Acknowledgements 84 13. References 85 14. Authors' Addresses 86 15. Intellectual Property Statement 87 16. Full Copyright Statement 88 Appendix A: CONNEG with Direct SMTP 89 Appendix B. USING Combinations of the Extensions 91 1. INTRODUCTION 93 Internet specifications typically define common 94 capabilities that are supported by all participants 95 for a particular service. This permits sending basic 96 data without needing to know the additional 97 capabilities supported by individual recipients. 98 However, knowing those capabilities permits sending 99 additional types of data and data of enhanced richness. 100 Otherwise, a message originator is faced with sending 101 content in a form the recipient cannot process or with 102 sending multiple forms of data. This specification extends 103 the work of [CONMSG] which permits a recipient to solicit 104 alternative content forms from the originator. The current 105 specification enables MIME content conversion by 106 intermediaries, on behalf of a message originator and a 107 message recipient. 109 1.1. Background 111 MIME enables distinguishing and labeling different 112 types of content. However an email originator cannot know 113 whether a recipient is able to support (interpret) any 114 particular data type. In order to permit basic use of 115 MIME, a minimum set of data types are specified as its 116 support base. How is an originator to know whether a 117 recipient can support any other types? 119 A mechanism for describing MIME types is specified in 120 [FEAT]. A mechanism that permits an originator to query 121 a recipient about the types it supports, by using email 122 messages for the control exchange, is specified in 123 [CONMSG]. In particular, this permits a recipient to 124 propagate information about its capabilities back to an 125 originator. Obviously, using end-to-end email messages 126 for the control exchange introduces considerable 127 latency and some unreliability. 129 An alternative approach is for an originator to use the 130 "best" form of data that it can, to include the same types 131 of permitted representation information used in [CONMSG], 132 and hope that the recipient, or an intermediary, can translate 133 this into a form that is supported by a limited recipient. 134 This specification defines such a mechanism. It defines a 135 means of matching message content form to the capabilities of 136 a recipient device or system, by using MIME content descriptors 137 and the optional use of an SMTP-based negotiation mechanism. 139 1.2. Overview 141 An originator describes desirable content forms, in 142 MIME content descriptors. It further may give 143 "permission", to any intermediary or the recipient, to 144 convert the content to only one of those forms. 145 Separately, an SMTP server may report the target's 146 content capabilities back to the SMTP client. The 147 client is then able to convert message content to a 148 form that is both supported by the target system and is 149 acceptable to the originator. 151 A conversion service needs to balance between 152 directions provided by the originator, directions 153 provided by the recipient, and capabilities of the 154 intermediary that is performing the conversions. This 155 is made more complex by needing to distinguish between 156 such directions being merely advisory, versus having 157 them intended as requirements. Conversions that are 158 specified as advisory are performed if possible, but 159 they do not alter message delivery. In contrast, 160 conversion specifications that are treated as a 161 requirement prohibit delivery if the recipient will be 162 unable to process the content. 164 These possibilities interact to form different 165 processing scenarios, in the event the intermediary 166 cannot satisfy the desires of both the originator and 167 the recipient: 169 Table 1: FAILURE HANDLING 171 \ RECEIVER| | | 172 +-------+ | Advise | Require | 173 ORIGINATOR\| | | 174 -----------+----------+----------+ 175 | Deliver | Deliver | 176 Advise | original | original | 177 | content | content | 178 -----------+----------+----------+ 179 | Return | Return | 180 Require | w/out | w/out | 181 | delivery | delivery | 182 -----------+----------+----------+ 184 This table reflects a policy that determines failure 185 handling solely based on the direction provided by the 186 originator. Hence, information from the recipient is 187 used to guide the details of conversion, but not to 188 decide whether to deliver the message. 190 This is intended to continue existing email practise of 191 delivering content that a recipient might not be able 192 to process. Clearly the above table could be modified 193 to reflect a different policy. However that would 194 limit the backward compatibility experienced by users. 196 This specification provides mechanisms to support a 197 controlled, transit-time mail content conversion 198 service, through a series of mechanisms. These 199 include: 201 * an optional ESMTP hop-by-hop service that uses the 202 CONPERM SMTP service extensions, issued by the originator, 203 * an optional ESMTP hop-by-hop service that uses the 204 CONNEG SMTP service extensions, issued by the recipient, and 205 * three MIME Content headers (Content-Convert, Content- 206 Previous and Content-Features) that specify appropriate 207 content headers and record conversions that have been 208 performed. 210 Figure 1: EXAMPLE RELAY ENVIRONMENT 212 +------------+ +-----------+ 213 | Originator | | Recipient | 214 +------------+ +-----------+ 215 ||Posting Delivering/\ 216 \/ || 217 +--------+ +-----------------+ +--------+ 218 | SMTP | | SMTP Relay | | SMTP | 219 | Client |--->| Server | Client |--->| Server | 220 +--------+ +--------+--------+ +--------+ 222 1.3. Conventions 224 In examples, "C:" and "S:" indicate lines sent by the 225 client and server respectively. 227 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 228 NOT" and "MAY" in this document are to be interpreted 229 as defined in "Key words for use in RFCs to Indicate 230 Requirement Levels" [KEYWORDS]. 232 2. APPLICABILITY 233 This specification defines a cooperative mechanism that 234 facilitates early transformation of content. The mechanism 235 can be used to save bandwidth and to permit rendering on 236 recipient devices that have limited capabilities. In the 237 first case, the assumption is that conversion will produce 238 smaller content. In the latter case, the assumption is that 239 the recipient device can render content in a form that can be 240 derived from the original, but that the device cannot render 241 the original form. 242 The mechanism can impose significant resource requirements on 243 an intermediary doing conversions. Further, the intermediary 244 accepts responsibility for conversion prior to knowing 245 whether it can perform the conversion. Also note that 246 conversion is not possible for content that has been 247 digitally signed or encrypted, unless the converting 248 intermediary can decode and re-code the content. 250 3. SERVICE SPECIFICATION 252 This service integrates two ESMTP extensions and three 253 MIME content headers, to permit authorized, accountable 254 content form conversion by intermediaries. 255 Intermediaries are ESMTP hosts (clients and servers) 256 along the transmission path between an originator and a 257 recipient. 259 An originator specifies preferred content-types through 260 the Content-Convert MIME content header. The content 261 headers occur in each MIME body-part to which they 262 apply. That is, each MIME body-part contains its own 263 record of conversion guidance and history. 265 The originator's preferences are raised to the level 266 of requirement, through the ESMTP CONPERM service 267 extension. The CONPERM mechanism is only needed when 268 an originator requires that conversion limitations be 269 enforced by the mail transfer service. If an acceptable 270 content type cannot be delivered, then no delivery is to 271 take place. 273 Target system capabilities are communicated in SMTP 274 sessions through the ESMTP CONNEG service extension. 275 This information is used to restrict the range of 276 conversions that may be performed, but does not affect 277 delivery. 279 When CONPERM is used, conversions are performed by the first ESMTP 280 host that can obtain both the originator's permission and the 281 recipient's capabilities. If a relay or client is unable to 282 transmit the message to a next-hop that supports CONPERM or to 283 perform appropriate conversion, then it terminates message 284 transmission and returns a [DSN, DSNFMT, DSNCOD] to the originator, 285 with status code 5.6.3 (Conversion required but not supported). 287 When an SMTP relay or server performs content 288 conversion, it records which specific conversions are 289 made, into Content-Previous and Content-Features MIME 290 headers associated with each, converted MIME body-part. 292 If a message is protected by strong content authentication or 293 privacy techniques, then an intermediary that converts message 294 content MUST ensure that the results of its processing are 295 similarly protected. Otherwise it MUST NOT perform conversion. 297 Originator Action: 299 An originator specifies desired conversion 300 results, through the MIME Content-Convert header. If the 301 originator includes a Content-Convert header, then they must 302 also include a Content-Feature header, to describe the current 303 form of the content. Intermediaries MAY interpret the presence of 304 this header as authorization to perform conversions. When 305 Content- Convert headers are the sole means for guiding 306 conversions by intermediaries, then they serve only as 307 advisories. In particular, failure to satisfy the 308 guidance of these headers does not affect final delivery. 310 The originator MAY also specify transit-service 311 enforcement of conversion limitations by using the 312 ESMTP CONPERM service extension when posting a new 313 message. Conversions MUST be limited to those 314 specified in MIME Content-Convert headers, in each of 315 the MIME body-parts for which conversion is authorized. 316 If conversion is needed, but an authorized conversion 317 cannot be performed, then the message is returned to 318 the originator. If CONPERM is not used, then failure 319 to perform an authorized conversion does not affect 320 normal delivery handling. 322 Figure 2: CONPERM USAGE 324 +------------+ 325 | Originator | 326 +------------+ 327 SMTP || 328 or || CONPERM 329 SUBMIT \/ 330 +--------+ +----------------+ 331 | SMTP | SMTP | SMTP Relay | 332 | Client |----------->| Server | | 333 +--------+ CONPERM +--------+-------+ 335 Recipient Action: 337 With the ESMTP mail transfer service, recipient 338 capabilities SHOULD be communicated to intermediaries by 339 the ESMTP CONNEG service extension. 341 Figure 3: CONNEG USAGE 342 +-----------+ 343 | Recipient | 344 +-----------+ 345 Capabilities|| 346 \/ 347 +----------------+ +--------+ 348 | SMTP Relay | CONNEG | SMTP | 349 | | Client |<--------| Server | 350 +-------+--------+ +--------+ 352 Intermediary Actions: 354 An intermediary MAY be given CONPERM direction 355 when receiving a message, and MAY be given CONNEG 356 guidance, before sending the message. CONPERM and 357 CONNEG operate on a per-message basis. Therefore they 358 are issued through the ESMTP MAIL-FROM request. CONNEG 359 response information is provided on a per-recipient 360 basis, through the response to ESMTP RCPT-TO. 362 Conversion MUST be performed by the first CONPERM intermediary 363 that obtains CONNEG recipient capability information. The MIME 364 Content-Type MUST conform to the result of the converted content, 365 as per [MEDTYP]. When an intermediary obtains different capability 366 information for different recipients of the same message, it MAY 367 either: 369 * Create a single, converted copy of the content that can 370 be supported by all of the recipients, or 371 * Create multiple converted copies, matching the 372 capabilities of subsets of the recipients. Each version is 373 then sent separately, to an appropriate subset of the 374 recipients, using separate, standard SMTP sessions with 375 separate, standard RFC2821.Rcpt-To lists of addresses. 377 A record of conversions is placed into MIME 378 Content-Previous headers. The current form of the 379 content is described in MIME Content-Features headers. 380 A special case of differential capabilities occurs 381 when an intermediary receives capability information 382 about some recipients, but no information about others. 383 An example of this scenario can occur when sending a 384 message to some recipients within one's own 385 organization and other recipients located elsewhere. 386 The intermediary might have capability information 387 about the local recipients, but will not have any for 388 distant recipients. This is treated as a variation of 389 the handling that is required for situations in which 390 the permissible conversions are the null set -- that is, 391 no valid conversions are possible for a recipient. 393 Rather than simply failing transmission to the recipients for 394 which there is no capability information, the intermediary MAY 395 choose to split the list of addressees into subsets of separate, 396 standard RFC2821.Rcpt-To lists and separate, standard SMTP 397 sessions, and then continue the transmission of the original 398 content to those recipients, via the continued use of the CONPERM 399 mechanism. Hence, the handling for such recipients is performed 400 as if no CONNEG transaction took place. 402 Once an intermediary has performed conversion, it 403 MAY terminate use of CONPERM. However some relay 404 environments, such as those re-directing mail to a new 405 target device, will benefit from further conversion. 406 Intermediaries MAY continue to use CONPERM or MAY re- 407 initiate CONPERM use, when they have knowledge about 408 possible variations in target device. 409 NOTE: 411 A new, transformed version of content may have less 412 information than the earlier version. Of course, a sequence of 413 transformations may lose additional information at each step. 414 Perhaps surprisingly, this can result in more loss than might 415 otherwise be necessary. For example, transformation x could 416 change content form A to content form B, and then 417 transformation y change B to C. However it is possible that 418 transformation y could have accepted form A directly and 419 produced form D which has more of the original information 420 than C. 421 NOTE: 422 An originator MAY validate any conversions that are made by 423 requesting a positive [DSN]. If the DSN request includes the 424 "RET" parameter, the delivery agent SHOULD return an exact copy 425 of the delivered (converted) message content. This will permit 426 the originator to inspect the results of any conversion(s). 428 3.1. Sending Permission 430 A message originator that permits content conversion by 431 intermediaries MAY use the CONPERM ESMTP service 432 extension and Content-Convert MIME headers to indicate 433 what conversions are permitted by intermediaries. 434 Other mechanisms by which a message originator 435 communicates this permission to the SMTP message 436 transfer service are outside the scope of this 437 specification. 438 NOTE: 439 This option requires that a server make an open-ended 440 commitment to ensure that acceptable conversions are 441 performed. In particular, it is possible that an 442 intermediary be required to perform conversion but be 443 unable to do so. This will result intermediary will be 444 required to perform conversion but will be in undelivered 445 mail. 447 When an ESMTP client is authorized to participate in 448 the CONPERM service it MUST interact with the next SMTP 449 hop server, about: 451 * The server's ability to enforce authorized conversions, 452 through ESMTP CONPERM 453 * The capabilities supported for the target device or 454 system, through ESMTP CONNEG 456 Successful use of CONPERM does not require that 457 conversion take place along the message transfer path. 458 Rather, it requires that conversion take place whenever 459 a next-hop server reports recipient capabilities, 460 through CONNEG, and those capabilities do not include 461 support for the current representation of the content. 463 It is acceptable to have every SMTP server -- including 464 the last-hop server -- support CONPERM, with none 465 offering CONNEG. In this case, the message is 466 delivered to the recipient in its original form. Any 467 possible conversions to be performed are left to the 468 recipient. Hence the recipient is given the original 469 form of the content, along with an explicit list of 470 conversions that the originator deems acceptable. 472 An SMTP server MAY offer ESMTP CONPERM, without being 473 able to perform conversions, if it knows that 474 conversions can be performed along the remainder of the 475 transfer path, or by the target device or system. 477 3.2. Returning Capabilities 479 A target recipient device or system communicates its 480 content form capabilities to the SMTP service through a 481 means outside the scope of this specification. Note that 482 the mechanism for enabling a server to issue CONNEG information 483 may require substantial mechanism between MUA and server. When an 484 ESMTP server knows a target's capabilities, it MAY offer the 485 CONNEG ESMTP service extension. 487 When a message is being processed according to the 488 CONPERM mechanism, if a next-hop ESMTP server responds 489 that it supports CONNEG, then the SMTP client: 491 (1) MUST request CONNEG information 492 (2) MUST perform the requisite conversions, if possible, 493 before sending the message to the next-hop SMTP server 494 (3) MUST fail message processing, if any conversion for the 495 message fails and MUST return a failure DSN to the 496 originator, with status code 5.6.5 (Conversion failed). 498 When performing conversions, as specified in Content- 499 Convert MIME headers, the Client MUST: 501 (1) Add a Content-Previous header and a Content-Features 502 header to each MIME body-part that has been converted. 503 removing any existing Content-Features header. 504 (2) Either: 506 * Send a single copy to the next-hop SMTP server, using a 507 best capabilities that are supported to all recipients 508 along that path, or 509 * Separate the transfers into multiple, standard 510 RFC2821.Rcpt-To and ESMTP sessions, in order to provide 511 the best conversions possible for subsets of the 512 recipients. 514 If the transfers are to be separated, then the current 515 session MUST be terminated, and new sessions conducted 516 for each subset. 518 The conversions that are performed are determined by 519 the intersection of three lists: 521 * Conversions permitted by the originator 522 * Content capabilities of the target 523 * Conversions that can be performed by the SMTP client 524 host 526 Failed Conversion 528 If the result of this intersection is the null set of 529 representations, for an addressee, then delivery to 530 that addressee MUST be handled as a conversion failure. 532 If handling is subject to the CONPERM mechanism and: 534 * the next-hop SMTP host does not indicate that it can 535 represent the target's capabilities through CONNEG, but 536 * does respond that it can support CONPERM, 538 then the client SMTP MUST send the existing content, 539 if all other SMTP transmission requirements are 540 satisfied. 542 If handling is not subject to the CONPERM mechanism, 543 then conversion failures do not affect message 544 delivery. 546 3.3. Next-Hop Non-Support of Service 548 If a Client is participating in the CONPERM mechanism, 549 but the next-hop SMTP server does not support CONPERM 550 and does not support CONNEG, then the SMTP client 552 (1) MUST terminate the session to the next-hop SMTP server, 553 without sending the message 555 (2) MUST return a DSN notification to the originator, with status 556 code 5.6.3 (Conversion required but not supported). [DSN, 557 DSNFMT, SYSCOD] 559 If a Client is participating in the CONPERM mechanism 560 and the next-hop SMTP server supports CONNEG but 561 provides no capabilities for an individual RCPT-TO 562 addressee, then the SMTP client's processing for that 563 recipient MUST be either to: 565 (1) Treat the addressee as a conversion failure, or 566 (2) Separate the addressee from the address list that is 567 processed according to CONNEG, and continue to process the 568 addressee according to CONPERM. 570 4. CONTENT CONVERSION PERMISSION SMTP EXTENSION 572 4.1. Content Conversion Permission Service Extension 573 Definition 575 (1) The name of the SMTP service extension is 577 "Content_Conversion_Permission" 579 (2) The EHLO keyword value associated with this extension 580 is 582 "CONPERM" 584 (3) A parameter using the keyword "CONPERM" is added to the 585 MAIL-FROM command. 587 (4) The server responds with acceptance or rejection of 588 support for CONPERM, for this message. 590 4.2. CONPERM Parameter to Mail-From 592 Parameter: 594 CONPERM 596 Arguments: 598 There are no arguments. Specification of 599 permitted conversions is located in a Content-Convert 600 header for each MIME body-part for which conversion is 601 permitted. 603 Client Action: 605 If the server issued a 250-CONPERM, as part of its 606 EHLO response for the current session and the client is 607 participating in the CONPERM service for this message - 608 - such as by having received the message with a CONPERM 609 requirement -- then the client MUST issue the CONPERM 610 parameter in the MAIL-FROM. If the server does not 611 issue 250-CONPERM, and the client is participating in 612 the CONPERM service for this message, then the client 613 MUST treat the transmission as permanently rejected. 615 Server Action: 617 If the client specifies CONPERM in the MAIL-FROM, 618 but the server does not support the CONPERM parameter, 619 the server MUST reject the MAIL-FROM command with a 504- 620 CONPERM reply. 622 If the client issues the CONPERM parameter in the 623 MAIL-FROM, then the server MUST conform to this 624 specification. Either it MUST relay the message 625 according to CONPERM, or it MUST convert the message 626 according to CONNEG information. 628 4.3. Syntax 630 Content_Conversion_Permission = "CONPERM" 632 5. CONTENT NEGOTIATION SMTP EXTENSION 633 5.1. Content Negotiation Service Extension Definition 635 (1) The name of the SMTP service extension is: 637 "Content_Negotiation" 639 (2) The EHLO keyword value associated with this extension 640 is: 642 "CONNEG" 644 (3) A parameter using the keyword "CONNEG" is added to the 645 RCPT-TO command 646 (4) The server responds with a report of the content 647 capabilities of each device or system that embodies 648 the corresponding target RCPT-TO address 650 5.2. CONNEG parameter to RCPT-TO 652 Parameter: 654 CONNEG 656 Arguments: 658 There are no arguments. 660 Client Action: 662 If a message is subject to CONPERM requirements and 663 the server issues a 250-CONNEG, as part of its EHLO 664 response for the current session, the client MUST issue 665 the CONNEG parameter in the RCPT-TO request. If the 666 message is not subject to CONPERM requirements and the 667 server issues a 250-CONNEG, the client MAY issue the 668 CONNEG parameter with RCPT-TO. 670 If the client issues the CONNEG parameter with 671 RCPT-TO, then it MUST honor the capabilities returned 672 in the CONNEG RCPT-TO replies for that message, and it 673 MUST convert the message content, if the current form 674 of the content is not included in the recipient 675 capabilities. 677 The conversions that are performed are determined 678 by the intersection of the: 680 * Conversions permitted by the originator 681 * Content capabilities of the target 682 * Conversions that can be performed by the SMTP client 683 host 685 If the result of this intersection is the null set 686 of representations, then the Client processing depends 687 upon whether the next-hop server has offered CONPERM, as well as 688 CONNEG: 689 (1) If the message will be subject to CONPERM at the next 690 hop, the Client MAY to transmit the original content 691 to the next hop, continuing CONPERM requirements. 692 (2) Otherwise, the Client MUST treat the conversion as 693 failed. 695 If the result of the intersection is not null, the 696 client SHOULD convert the data to the "highest" level 697 of capability of the server. Determination of the 698 level that is highest is left to the discretion of the 699 host performing the conversion. 701 Each converted MIME body-part, MUST have a Content- 702 Previous header that indicates the previous body-part 703 form and a Content-Features header, indicating the new 704 body-part form. 706 Server Action: 708 If the client specifies CONNEG in the RCPT-TO, but 709 the server does not support the CONNEG parameter, the 710 server MUST reject the RCPT-TO addressees with 504 711 replies. 713 If the server does support the CONNEG parameter 714 and it knows the capabilities of the target device or 715 system, then it MUST provide that information through 716 CONNEG. 718 The response to a CONNEG RCPT-TO request will be 719 multi-line RCPT-TO replies. For successful (250) 720 responses, at least the first line of the response is 721 for RCPT-TO information other than CONNEG. Additional 722 response lines are for CONNEG. In order to avoid 723 problems due to variations in line buffer sizes, the 724 total parametric listing must be provided as a series 725 of lines, each beginning with "250-CONNEG" except for 726 the last line, which is "250 CONNEG". 727 The contents of the capability listing MUST 728 conform to the specifications in [SYN] and covers the 729 same range of specifications permitted in [CONMSG]. 731 5.3. Syntax 733 Content_Negotiation = "CONNEG" 734 Capability = <> 736 6. MIME CONTENT-FEATURES HEADER 738 The Content-Features header describes the characteristics 739 of the current version of the content for the MIME 740 body-part in which the header occurs. There is a separate 741 Content-Features header for each MIME body-part. 742 The specification for this header is contained in 743 [FEAT]. 745 7. MIME CONTENT-CONVERT HEADER 747 Content-Convert is a header field that specifies preferred 748 conversions for the associated content. It MAY be used 749 without the other mechanisms defined in this document. 750 If present, this header MUST be carried unmodified and 751 delivered to the recipient. In its absence the content 752 originator has provided no guidance about content conversions, 753 and intermediaries SHOULD NOT perform content conversion. 755 In the extended ABNF notation, the Content-Convert 756 header field is defined as follows: 758 Convert = "Content-convert" ":" 759 permitted 761 Permitted = "ANY" / "NONE" / 762 <> 765 If the permitted conversions are specified as "ANY" 766 then the intermediary may perform any conversions it 767 deems appropriate. 769 If the permitted conversions are specified as "NONE" 770 then the intermediary SHOULD NOT perform any 771 conversions to this MIME body-part, even when the 772 target device or system does not support the original 773 form of the content. 775 If a Content-Convert header is present, then a Content- 776 Features header MUST also be present, to describe the 777 current form of the Content. 779 8. MIME CONTENT-PREVIOUS HEADER 781 When an intermediary has performed conversion of the 782 associated content, the intermediary MUST record 783 details of the previous representation, from which the 784 conversion was performed. This information is placed 785 in a Content-Previous header that is part of the 786 MIME body-part with the converted content. There is 787 a separate header for each, converted MIME body-part. 789 When an intermediary has performed conversion, the 790 intermediary MUST record details of the result of the 791 conversion that was performed, by creating or revising 792 the Content-Features header for the MIME body-part that 793 was converted. 795 In the extended [ABNF] notation, the Content-Previous 796 header field is defined as follows: 798 previous = "Content-Previous" [CFWS] ":" 799 [CFWS] 800 date by type 802 date = "Date " [CFWS] date-time [CFWS]";" 803 [CFWS] 805 by = "By " [CFWS] domain [CFWS]";" 806 [CFWS] 808 type = <> 811 The Date field specifies the date and time at which the 812 indicated representation was converted into a newer 813 representation. 815 The By field specifies the domain name of the 816 intermediary that performed the conversion. 818 An intermediary MAY choose to derive the Content- 819 Previous header, for a body-part, from an already- 820 existing Content-Features header in that body-part, 821 before that header is replaced with the description of 822 the current representation. 824 9. EXAMPLES 826 9.1. CONPERM Negotiation 828 S: 220 example.com IFAX 829 C: EHLO example.com 830 S: 250- example.com 831 S: 250-DSN 832 S: 250 CONPERM 833 C: MAIL FROM:May@some.example.com CONPERM 834 S: 250 originator ok 835 C: RCPT TO: 836 S: 250- recipient ok 837 C: DATA 838 S: 354 okay, send data 839 C: <> 866 S: 250 message accepted 867 C: QUIT 868 S: 221 goodbye 870 9.2. Example CONNEG Negotiation 872 S: 220 example.com IFAX 873 C: EHLO example.com 874 S: 250- example.com 875 S: 250-DSN 876 S: 250 CONNEG 877 C: MAIL FROM: 878 S: 250 originator ok 879 C: RCPT TO: CONNEG 880 S: 250- recipient ok 881 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 882 S: 250-CONNEG (MRC-mode=0) 883 S: 250-CONNEG (color=Binary) 884 S: 250-CONNEG (|(&(dpi=204) 885 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 886 S: 250-CONNEG (&(dpi=200) 887 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 888 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 889 S: 250-CONNEG (size-x<=2150/254) 890 S: 250-CONNEG (paper-size=[letter,A4]) 891 S: 250 CONNEG (ua-media=stationery) ) 892 C: DATA 893 S: 354 okay, send data 894 C: <> 903 S: 250 message accepted 904 C: QUIT 905 S: 221 goodbye 907 9.3. Content-Previous 909 Content-Previous: 910 Date Tue, 1 Jul 2001 10:52:37 +0200; 911 By relay.example.com; 912 (&(image-file-structure=TIFF-minimal) 913 (MRC-mode=0) 914 (color=Binary) 915 (&(dpi=400) 916 (dpi-xyratio=1) ) 917 (&(image-coding=JBIG) 918 (image-coding-constraint=JBIG-T85) 919 (JBIG-stripe-size=128) ) 920 (size-x=2150/254) 921 (paper-size=A4) 922 (ua-media=stationery) ) 924 10. IANA CONSIDERATIONS 926 There are no IANA considerations regarding this document. 928 11. SECURITY CONSIDERATIONS 930 This service calls for recipients to disclose their 931 capabilities. Mechanisms for determining the 932 requestor's and the respondent's authenticated identity 933 are outside the scope of this specification. It is 934 intended that these mechanisms permit disclosure of 935 information that can safely be public; hence there is 936 no inherent need for security measures. 938 Information that should receive restricted distribution 939 is still able to be disclosed. It is, therefore, the 940 responsibility of the disclosing ESMTP server or 941 disclosing ESMTP client to determine whether additional 942 security measures should be applied to the use of this 943 ESMTP option. 944 Use of the ESMTP CONNEG option permits content transformation 945 by an intermediary, along the mail transfer path. When 946 the contents are encrypted, the intermediary cannot perform 947 the conversion, since it is not expected to have access to the 948 relevant secret keying material. When the contents are signed, 949 but not encrypted, conversion will invalidate the signature. 950 This specification provides for potentially unbounded computation 951 by intermediary MTAs, depending upon the nature and amount 952 of conversion required. Further, this computation burden might 953 provide an opportunity for denial-of-service attacks, given that 954 Internet mail typically permits intermediaries to receive messages 955 from all Internet sources. 956 This specification provides for content conversion by 957 unspecified intermediaries. Use of this mechanism 958 carries significant risk. Although intermediaries 959 always have the ability to perform damaging 960 transformations, use of this specification could result 961 in more exploration of that potential and, therefore, 962 more misbehavior. Use of intermediaries is discussed 963 in [RFC3238]. 964 Conperm/Conneg provide a cooperative mechanism, rather than 965 enabling intermediary actions that have not previously been 966 possible. Intermediaries already can and do make conversions 967 on their own initiative. Hence the mechanism introduces 968 essentially no security concerns, other than divulging 969 recipient preferences. 971 12. ACKNOWLEDGEMENTS 973 Graham Klyne and Eric Burger provided extensive, 974 diligent reviews and suggestions. Keith Moore and Giat 975 Hana provided feedback that resulted in improving the 976 specification's integration into established email 977 practise. 979 13. REFERENCES 981 Normative: 982 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 983 Specifications: ABNF", RFC 2234, November 1997. 984 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 985 Indicate Requirement Levels", RFC2119, March 1997 987 [CONMSG] Klyne, G., Iwazaki, R., Crocker. D., , 988 "Content Negotiation for Messaging 989 Services based on Email", RFC 3297, July 990 2002. 992 [DISP] Masinter, L., Holtman, K., Mutz, A. and 993 D. Wing, "Media Features for Display, 994 Print, and Fax", RFC 2534, March 1999. 995 [DSN] Moore, K. "Simple Mail Transfer Protocol (SMTP) 996 Service Extension for Delivery Status 997 Notifications (DSNs)", RFC 3461, January 2003 998 [DSNFMT] K. Moore and G. Vaudreuil, "An Extensible Message 999 Format for Delivery Status Notifications", 1000 RFC 3464, January 2003. 1001 [DSNSMTP] Moore, K. "Simple Mail Transfer Protocol (SMTP) 1002 Service Extension for Delivery Status Notifications 1003 (DSNs)",RFC 3461, January 2003 1005 [SYSCOD] Vaudreuil, G., "Enhanced Mail System Status 1006 Codes", RFC3463, January 2003. 1008 [ESMTP1] Klensin, J., Freed, N., Rose, M., 1009 Stefferud, E. and D. Crocker, "SMTP 1010 Service Extensions", RFC 1869, November 1011 1995 1013 [ESMTP2] Klensin, J., "Simple Mail Transfer 1014 Protocol", RFC 2821, April 2001. 1015 [FEAT] Klyne, G., "Indicating Media Features 1016 for MIME Content", RFC 2912, September 1017 2000 1019 [IMF] Resnick, P., "Internet Message Format", 1020 RFC 2822, April 2001 1021 [SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", 1022 RFC 3463, January 2003. 1024 [TAG] Holtman, K., Mutz, A. and T. Hardie, 1025 "Media Feature Tag Registration 1026 Procedure", RFC 2506, March 1999. 1027 [SYN] Klyne, G. "A Syntax for Describing Media 1028 Feature Sets", RFC 2533, March 1999 1029 [MEDTYP] IANA, "MIME Media Types", 1030 1032 Informative: 1033 [RFC3238] Floyd, S., Daigle, L., "IAB Architectural 1034 and Policy Considerations for Open Pluggable 1035 Edge Services", RFC 3238, January 2002 1037 14. AUTHORS' ADDRESSES 1039 Kiyoshi Toyoda 1040 Panasonic Communications Co., Ltd. 1041 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan 1043 toyoda.kiyoshi@jp.panasonic.com 1045 Dave Crocker 1046 Brandenburg InternetWorking 1047 675 Spruce Drive 1048 Sunnyvale, CA 94086 USA 1050 Tel: +1.408.246.8253 1051 dcrocker@brandenburg.com 1053 15. INTELLECTUAL PROPERTY STATEMENT 1054 The IETF takes no position regarding the validity or scope of any 1055 intellectual property or other rights that might be claimed to 1056 pertain to the implementation or use of the technology described in 1057 this document or the extent to which any license under such rights 1058 might or might not be available; neither does it represent that it 1059 has made any effort to identify any such rights. Information on the 1060 IETF's procedures with respect to rights in standards-track and 1061 standards-related documentation can be found in BCP-11. Copies of 1062 claims of rights made available for publication and any assurances of 1063 licenses to be made available, or the result of an attempt made to 1064 obtain a general license or permission for the use of such 1065 proprietary rights by implementors or users of this specification can 1066 be obtained from the IETF Secretariat. 1067 The IETF invites any interested party to bring to its attention any 1068 copyrights, patents or patent applications, or other proprietary 1069 rights which may cover technology that may be required to practice 1070 this standard. Please address the information to the IETF Executive 1071 Director. 1073 16. FULL COPYRIGHT STATEMENT 1075 Copyright (C) The Internet Society (year). This document is subject 1076 to the rights, licenses and restrictions contained in BCP 78, and 1077 except as set forth therein, the authors retain all their rights. 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1081 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1082 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1083 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 APPENDIX A: CONNEG WITH DIRECT SMTP 1088 This Appendix is descriptive. It only provides 1089 discussion of usage issues permitted or required by 1090 the normative text 1092 In some configurations it is possible to have direct 1093 email-based interactions -- where the originator's 1094 system conducts a direct, interactive TCP connection 1095 with the recipient's system. This configuration 1096 permits a use of the content form negotiation service 1097 that conforms to the specification here, but permits 1098 some simplifications. This single SMTP session does 1099 not have the complexity of multiple, relaying sessions 1100 and therefore does not have the requirement for 1101 propagating permissions to intermediaries. 1103 The Originator's system provides user-level functions 1104 for the originator, and it contains the SMTP Client for 1105 sending messages. Hence, the formal step of email 1106 "posting" is a process that is internal or virtual, 1107 within the Originating system. The recipient's service 1108 contains the user-level functions for the recipient, 1109 and it contains the SMTP server, for receiving 1110 messages. Hence the formal steps of email "delivering" 1111 and "receipt" are internal or virtual, within the 1112 Receiving system. 1114 Figure 4: DIRECT CONNEG 1116 Originating system Receiving system 1117 +------------------+ +------------------+ 1118 | +------------+ | | +-----------+ | 1119 | | Originator | | | | Recipient | | 1120 | +------------+ | | +-----------+ | 1121 | ||Posting | | /\Receiving | 1122 | \/ | | || | 1123 | +---------+ | | +--------+ | 1124 | | SMTP |<---|-------|----| SMTP | | 1125 | | Client |----|-------|--->| Server | | 1126 | +---------+ | | +--------+ | 1127 +------------------+ +------------------+ 1129 In this case CONPERM is not needed, because the SMTP 1130 Client is part of the originating system. Therefore it 1131 already has the necessary permission. Similarly, the 1132 SMTP server will be certain to know the recipient's 1133 capabilities, because the server is part of the 1134 receiving system. 1136 Therefore, Direct Mode email transmission can achieve 1137 content capability and form matching by having: 1139 * Originating systems that conform to this specification 1140 and a communication process between originator and recipient 1141 that is the same as would take place between a last-hop SMTP 1142 Relay and the Delivering SMTP server it connects to. 1143 * That is, the Client and Server MUST employ CONNEG and 1144 the Client MUST perform any requisite conversions. 1146 APPENDIX B. USING COMBINATIONS OF THE EXTENSIONS 1147 This specification defines a number of mechanisms. It is not 1148 required that they all be used together. For example, the 1149 difference between listing preferred conversions, versus 1150 specifying enforced limitations to conversions, is discussed in 1151 the Introduction. This Appendix further describes some scenarios 1152 which might call for using fewer than the complete set that is 1153 defined in this specification. It also summarizes the conditions 1154 which mandate that an intermediary perform conversion. 1156 This Appendix is descriptive. It only provides discussion of 1157 usage issues permitted or required by the normative text 1159 The available mechanisms are: 1161 1. CONPERM Parameter to Mail-From 1162 2. CONNEG parameter to RCPT-TO 1163 3. MIME Content-Convert Header 1164 4. MIME Content-Previous Header 1165 5. MIME Content-Features Header 1167 B.1 Specifying Suggested Conversion Constraints 1168 Use of the MIME Content-Convert header specifies the originator's 1169 preferences, should conversion be performed. This does not impose 1170 any requirements on the conversion, but instead is merely advisory. 1172 B.2 Specifying Required Conversion Constraints 1173 When the MIME Content-Convert specification is coupled with the 1174 ESMTP CONPERM option, then the originator's specification of 1175 preferred conversions rises to the level of requirement. No other 1176 conversions are permitted, except those specified in the Content- 1177 Convert header. 1179 Note that the presence of both these mechanisms does not require 1180 that conversions be performed. Rather, it constrains conversions, 1181 should they occur. 1183 B.3 When Conversion is Required 1184 A node is required to perform conversion when: 1186 1. At least one MIME Content-Covert header is present in 1187 the message, 1189 2. ESMTP CONPERM is in force at the node processing the 1190 message, 1192 3. ESMTP CONNEG is also in force at the same node, 1194 4. The current content form is not cited in the CONNEG 1195 list, 1197 5. At least one content form is present both in the 1198 Content-Convert list and the CONNEG list, and 1200 6. The intermediary is able to convert from the current 1201 form to one of the forms listed in both Content-Convert 1202 and Conneg.