idnits 2.17.1 draft-ietf-fax-esmtp-conneg-11.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 15. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1115), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1115. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) 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 1465 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. ** 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 312: '... content MUST ensure that the resu...' RFC 2119 keyword, line 313: '...d. Otherwise it MUST NOT perform conv...' RFC 2119 keyword, line 319: '... Intermediaries MAY interpret the pre...' RFC 2119 keyword, line 327: '... The originator MAY also specify tran...' RFC 2119 keyword, line 330: '...ge. Conversions MUST be limited to th...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 938 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 (August 2004) is 7193 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? 'FEAT' on line 1048 looks like a reference -- Missing reference section? 'CONMSG' on line 1020 looks like a reference -- Missing reference section? 'KEYWORDS' on line 1017 looks like a reference -- Missing reference section? 'DSN' on line 1029 looks like a reference -- Missing reference section? 'DSNFMT' on line 1033 looks like a reference -- Missing reference section? 'DSNCOD' on line 302 looks like a reference -- Missing reference section? 'MEDTYP' on line 1062 looks like a reference -- Missing reference section? 'SYN' on line 1059 looks like a reference -- Missing reference section? 'ABNF' on line 1014 looks like a reference -- Missing reference section? 'CFWS' on line 820 looks like a reference -- Missing reference section? 'RFC3238' on line 1067 looks like a reference -- Missing reference section? 'DISP' on line 1025 looks like a reference -- Missing reference section? 'SYSCOD' on line 1037 looks like a reference -- Missing reference section? 'ESMTP1' on line 1040 looks like a reference -- Missing reference section? 'ESMTP2' on line 1045 looks like a reference -- Missing reference section? 'IMF' on line 1052 looks like a reference -- Missing reference section? 'TAG' on line 1055 looks like a reference Summary: 14 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 2 Draft D. Crocker / Brandenburg 3 draft-ietf-fax-esmtp-conneg-11.txt August 2004 5 Expires: <02-05> 7 SMTP and MIME Extensions 8 For Content Conversion 10 STATUS OF THIS MEMO 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 COPYRIGHT NOTICE 38 Copyright (C) The Internet Society (2003). All Rights 39 Reserved. 41 ABSTRACT 43 A message originator sometimes sends content in a form 44 the recipient cannot process. Such content needs to be 45 converted to a related form, with the same or with 46 restricted information, such as changing from color to 47 black and white. In a store-and-forward environment, 48 it can be convenient to have this conversion performed 49 by an intermediary. This specification integrates two 50 ESMTP extensions and three MIME content headers, 51 defining a cooperative service that permits authorized, 52 accountable content form conversion by intermediaries. 54 CONTENTS 56 1. Introduction 57 1.1. Background 58 1.2. Overview 59 1.3. Conventions 61 2. Applicability 63 3. Service Specification 64 3.1. Sending Permission 65 3.2. Returning Capabilities 66 3.3. Next-Hop Non-Support of Service 68 4. Content Conversion Permission SMTP Extension 69 4.1. Content Conversion Permission Service Extension 70 Definition 71 4.2. CONPERM Parameter to Mail-From 72 4.3. Syntax 74 5. Content Negotiation SMTP extension 75 5.1. Content Negotiation Service Extension Definition 76 5.2. CONNEG parameter to RCPT-TO 77 5.3. Syntax 79 6. MIME Content-Convert Header 81 7. MIME Content-Previous Header 83 8. MIME Content-Features Header 85 9. Examples 86 8.1. CONPERM Negotiation 87 8.2. Example CONNEG Negotiation 88 8.3. Content-Previous 90 10. IANA Considerations 92 11. Security Considerations 94 12. Acknowledgements 96 13. References 98 14. Authors' Addresses 100 15. Intellectual Property Statement 102 16. Full Copyright Statement 104 Appendix A: CONNEG with Direct SMTP 106 APPENDIX B: Changes to This Draft (TO BE REMOVED BY RFC EDITOR) 108 1. INTRODUCTION 110 Internet specifications typically define common 111 capabilities that are supported by all participants 112 for a particular service. This permits sending basic 113 data without needing to know the additional 114 capabilities supported by individual recipients. 115 However, knowing those capabilities permits sending 116 additional types of data and data of enhanced richness. 117 Otherwise, a message originator is faced with sending 118 content in a form the recipient cannot process or with 119 sending multiple forms of data. This specification 120 enables MIME content conversion on behalf of a message 121 originator and a message recipient. 123 1.1. Background 125 MIME enables distinguishing and labeling different 126 types of content. However an email originator cannot know 127 whether a recipient is able to support (interpret) any 128 particular data type. In order to permit basic use of 129 MIME, a minimum set of data types are specified as its 130 support base. How is an originator to know whether a 131 recipient can support any other types? 133 A mechanism for describing MIME types is specified in 134 [FEAT]. A mechanism that permits an originator to query 135 a recipient about the types it supports, by using email 136 messages for the control exchange, is specified in 137 [CONMSG]. In particular, this permits a recipient to 138 propagate information about its capabilities back to an 139 originator. Obviously, using end-to-end email messages 140 for the control exchange introduces considerable 141 latency and some unreliability. 143 An alternative approach is for an originator to use the 144 "best" form of data that it can, and hope that the 145 recipient, or an intermediary, can translate this into 146 a form that is supported by a limited recipient. This 147 specification defines such a mechanism. It defines a 148 means of matching message content form to the 149 capabilities of a recipient device or system, by using 150 MIME content descriptors and the optional use of an 151 SMTP-based negotiation mechanism. 153 1.2. Overview 155 An originator describes desirable content forms, in 156 MIME content descriptors. It further may give 157 "permission", to any intermediary or the recipient, to 158 convert the content to only one of those forms. 159 Separately, an SMTP server may report the target's 160 content capabilities back to the SMTP client. The 161 client is then able to convert message content to a 162 form that is both supported by the target system and is 163 acceptable to the originator. 165 A conversion service needs to balance between 166 directions provided by the originator, directions 167 provided by the recipient, and capabilities of the 168 intermediary that is performing the conversions. This 169 is made more complex by needing to distinguish between 170 such directions being merely advisory, versus having 171 them intended as requirements. Conversions that are 172 specified as advisory are performed if possible, but 173 they do not alter message delivery. In contrast, 174 conversion specifications that are treated as a 175 requirement prohibit delivery if the recipient will be 176 unable to process the content. 178 These possibilities interact to form different 179 processing scenarios, in the event the intermediary 180 cannot satisfy the desires of both the originator and 181 the recipient: 183 Table 1: FAILURE HANDLING 185 \ RECEIVER| | | 186 +-------+ | Advise | Require | 187 ORIGINATOR\| | | 188 -----------+----------+----------+ 189 | Deliver | Deliver | 190 Advise | original | original | 191 | content | content | 192 -----------+----------+----------+ 193 | Return | Return | 194 Require | w/out | w/out | 195 | delivery | delivery | 196 -----------+----------+----------+ 198 This table reflects a policy that determines failure 199 handling solely based on the direction provided by the 200 originator. Hence, information from the recipient is 201 used to guide the details of conversion, but not to 202 decide whether to deliver the message. 204 This is intended to continue existing email practise of 205 delivering content that a recipient might not be able 206 to process. Clearly the above table could be modified 207 to reflect a different policy. However that would 208 limit the backward compatibility experienced by users. 210 This specification provides mechanisms to support a 211 controlled, transit-time mail content conversion 212 service, through a series of mechanisms. These 213 include: 215 * an optional ESMTP hop-by-hop service that uses the 216 CONPERM SMTP service extensions, issued by the originator, 218 * an optional ESMTP hop-by-hop service that uses the 219 CONNEG SMTP service extensions, issued by the recipient, and 221 * three MIME Content headers (Content-Convert, Content- 222 Previous and Content-Features) that specify appropriate 223 content headers and record conversions that have been 224 performed. 226 Figure 1: EXAMPLE RELAY ENVIRONMENT 228 +------------+ +-----------+ 229 | Originator | | Recipient | 230 +------------+ +-----------+ 231 ||Posting Delivering/\ 232 \/ || 233 +--------+ +-----------------+ +--------+ 234 | SMTP | | SMTP Relay | | SMTP | 235 | Client |--->| Server | Client |--->| Server | 236 +--------+ +--------+--------+ +--------+ 238 1.3. Conventions 240 In examples, "C:" and "S:" indicate lines sent by the 241 client and server respectively. 243 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 244 NOT" and "MAY" in this document are to be interpreted 245 as defined in "Key words for use in RFCs to Indicate 246 Requirement Levels" [KEYWORDS]. 248 2. APPLICABILITY 250 This specification defines a cooperative mechanism that 251 facilitates early transformation of content. The mechanism 252 can be used to save bandwidth and to permit rendering on 253 recipient devices that have limited capabilities. In the 254 first case, the assumption is that conversion will produce 255 smaller content. In the latter case, the assumption is that 256 the recipient device can render content in a form that can be 257 derived from the original, but that the device cannot render 258 the original form. 260 The mechanism can impose significant resource requirements on 261 an intermediary doing conversions. Further, the intermediary 262 accepts responsibility for conversion prior to knowing 263 whether it can perform the conversion. Also note that 264 conversion is not possible for content that has been 265 digitally signed or encrypted, unless the converting 266 intermediary can decode and re-code the content. 268 3. SERVICE SPECIFICATION 270 This service integrates two ESMTP extensions and three 271 MIME content headers, to permit authorized, accountable 272 content form conversion by intermediaries. 273 Intermediaries are ESMTP hosts (clients and servers) 274 along the transmission path between an originator and a 275 recipient. 277 An originator specifies preferred content-types through 278 the Content-Convert MIME content header. The content 279 headers occur in each MIME body-part to which they 280 apply. That is, each MIME body-part contains its own 281 record of conversion guidance and history. 283 The originator's preferences are raised to the level 284 of requirement, through the ESMTP CONPERM service 285 extension. The CONPERM mechanism is only needed when 286 an originator requires that conversion limitations be 287 enforced by the mail transfer service. If an acceptable 288 content type cannot be delivered, then no delivery is to 289 take place. 291 Target system capabilities are communicated in SMTP 292 sessions through the ESMTP CONNEG service extension. 293 This information is used to restrict the range of 294 conversions that may be performed, but does not affect 295 delivery. 297 When CONPERM is used, conversions are performed by the first ESMTP 298 host that can obtain both the originator's permission and the 299 recipient's capabilities. If a relay or client is unable to 300 transmit the message to a next-hop that supports CONPERM or to 301 perform appropriate conversion, then it terminates message 302 transmission and returns a [DSN, DSNFMT, DSNCOD] to the originator, 303 with status code 5.6.3 (Conversion required but not supported). 305 When an SMTP relay or server performs content 306 conversion, it records which specific conversions are 307 made, into Content-Previous and Content-Features MIME 308 headers associated with each, converted MIME body-part. 310 If a message is protected by strong content authentication or 311 privacy techniques, then an intermediary that converts message 312 content MUST ensure that the results of its processing are 313 similarly protected. Otherwise it MUST NOT perform conversion. 315 Originator Action: 317 An originator specifies desired conversion 318 results, through the MIME Content-Convert header. 319 Intermediaries MAY interpret the presence of this 320 header as authorization to perform conversions. When 321 Content-Convert headers are the sole means for guiding 322 conversions by intermediaries, then they serve only as 323 advisories. In particular, failure to satisfy the 324 guidance of these headers does not affect final 325 delivery. 327 The originator MAY also specify transit-service 328 enforcement of conversion limitations by using the 329 ESMTP CONPERM service extension when posting a new 330 message. Conversions MUST be limited to those 331 specified in MIME Content-Convert headers, in each of 332 the MIME body-parts for which conversion is authorized. 333 If conversion is needed, but an authorized conversion 334 cannot be performed, then the message is returned to 335 the originator. If CONPERM is not used, then failure 336 to perform an authorized conversion does not affect 337 normal delivery handling. 339 Figure 2: CONPERM USAGE 341 +------------+ 342 | Originator | 343 +------------+ 344 SMTP || 345 or || CONPERM 346 SUBMIT \/ 347 +--------+ +----------------+ 348 | SMTP | SMTP | SMTP Relay | 349 | Client |----------->| Server | | 350 +--------+ CONPERM +--------+-------+ 352 Recipient Action: 354 With the ESMTP mail transfer service, recipient 355 capabilities SHOULD be communicated to intermediaries by 356 the ESMTP CONNEG service extension. 358 Figure 3: CONNEG USAGE 359 +-----------+ 360 | Recipient | 361 +-----------+ 362 Capabilities|| 363 \/ 364 +----------------+ +--------+ 365 | SMTP Relay | CONNEG | SMTP | 366 | | Client |<--------| Server | 367 +-------+--------+ +--------+ 369 Intermediary Actions: 371 An intermediary MAY be given CONPERM direction 372 when receiving a message, and MAY be given CONNEG 373 guidance, before sending the message. CONPERM and 374 CONNEG operate on a per-message basis. Therefore they 375 are issued through the ESMTP MAIL-FROM request. CONNEG 376 response information is provided on a per-recipient 377 basis, through the response to ESMTP RCPT-TO. 379 Conversion MUST be performed by the first CONPERM intermediary 380 that obtains CONNEG recipient capability information. The MIME 381 Content-Type MUST conform to the result of the converted content, 382 as per [MEDTYP]. When an intermediary obtains different capability 383 information for different recipients of the same message, it MAY 384 either: 386 * Create a single, converted copy of the content that can 387 be supported by all of the recipients, or 389 * Create multiple converted copies, matching the 390 capabilities of subsets of the recipients. Each version is 391 then sent separately, to an appropriate subset of the 392 recipients, using separate, standard SMTP sessions with 393 separate, standard RFC2821.Rcpt-To lists of addresses. 395 A record of conversions is placed into MIME 396 Content-Previous headers. The current form of the 397 content is described in MIME Content-Features headers. 399 A special case of differential capabilities occurs 400 when an intermediary receives capability information 401 about some recipients, but no information about others. 402 An example of this scenario can occur when sending a 403 message to some recipients within one's own 404 organization and other recipients located elsewhere. 405 The intermediary might have capability information 406 about the local recipients, but will not have any for 407 distant recipients. This is treated as a variation of 408 the handling that is required for situations in which 409 the permissible conversions are the null set -- that is, 410 no valid conversions are possible for a recipient. 412 Rather than simply failing transmission to the recipients for 413 which there is no capability information, the intermediary MAY 414 choose to split the list of addressees into subsets of separate, 415 standard RFC2821.Rcpt-To lists and separate, standard SMTP 416 sessions, and then continue the transmission of the original 417 content to those recipients, via the continued use of the CONPERM 418 mechanism. Hence, the handling for such recipients is performed 419 as if no CONNEG transaction took place. 421 Once an intermediary has performed conversion, it 422 MAY terminate use of CONPERM. However some relay 423 environments, such as those re-directing mail to a new 424 target device, will benefit from further conversion. 425 Intermediaries MAY continue to use CONPERM or MAY re- 426 initiate CONPERM use, when they have knowledge about 427 possible variations in target device. 429 NOTE: 431 A new, transformed version of content may have less 432 information than the earlier version. Of course, a sequence of 433 transformations may lose additional information at each step. 434 Perhaps surprisingly, this can result in more loss than might 435 otherwise be necessary. For example, transformation x could 436 change content form A to content form B, and then 437 transformation y change B to C. However it is possible that 438 transformation y could have accepted form A directly and 439 produced form D which has more of the original information 440 than C. 442 NOTE: 444 An originator MAY validate any conversions that are made by 445 requesting a positive [DSN] and the delivery agent MAY return a 446 copy of the delivered message content. 448 3.1. Sending Permission 450 A message originator that permits content conversion by 451 intermediaries MAY use the CONPERM ESMTP service 452 extension and Content-Convert MIME headers to indicate 453 what conversions are permitted by intermediaries. 454 Other mechanisms by which a message originator 455 communicates this permission to the SMTP message 456 transfer service are outside the scope of this 457 specification. 459 "NOTE": 461 This option requires that a server make an open-ended 462 commitment to ensure that acceptable conversions are 463 performed. In particular, it is possible that an 464 intermediary be required to perform conversion but be 465 unable to do so. This will result intermediary will be 466 required to perform conversion but will be in undelivered 467 mail. 469 When an ESMTP client is authorized to participate in 470 the CONPERM service it MUST interact with the next SMTP 471 hop server, about: 473 * The server's ability to enforce authorized conversions, 474 through ESMTP CONPERM 476 * The capabilities supported for the target device or 477 system, through ESMTP CONNEG 479 Successful use of CONPERM does not require that 480 conversion take place along the message transfer path. 481 Rather, it requires that conversion take place whenever 482 a next-hop server reports recipient capabilities, 483 through CONNEG, and those capabilities do not include 484 support for the current representation of the content. 486 It is acceptable to have every SMTP server -- including 487 the last-hop server -- support CONPERM, with none 488 offering CONNEG. In this case, the message is 489 delivered to the recipient in its original form. Any 490 possible conversions to be performed are left to the 491 recipient. Hence the recipient is given the original 492 form of the content, along with an explicit list of 493 conversions that the originator deems acceptable. 495 An SMTP server MAY offer ESMTP CONPERM, without being 496 able to perform conversions, if it knows that 497 conversions can be performed along the remainder of the 498 transfer path, or by the target device or system. 500 3.2. Returning Capabilities 502 A target recipient device or system communicates its 503 content form capabilities to the SMTP service through a 504 means outside the scope of this specification. Note that 505 the mechanism for enabling a server to issue CONNEG information 506 may require substantial mechanism between MUA and server. When an 507 ESMTP server knows a target's capabilities, it MAY offer the 508 CONNEG ESMTP service extension. 510 When a message is being processed according to the 511 CONPERM mechanism, if a next-hop ESMTP server responds 512 that it supports CONNEG, then the SMTP client: 514 (1) MUST request CONNEG information 516 (2) MUST perform the requisite conversions, if possible, 517 before sending the message to the next-hop SMTP server 519 (3) MUST fail message processing, if any conversion for the 520 message fails and MUST return a failure DSN to the 521 originator, with status code 5.6.5 (Conversion failed). 523 When performing conversions, as specified in Content- 524 Convert MIME headers, the Client MUST: 526 (1) Add a Content-Previous header and a Content-Features 527 header to each MIME body-part that has been converted. 528 removing any existing Content-Features header. 530 (2) Either: 532 * Send a single copy to the next-hop SMTP server, using a 533 best capabilities that are supported to all recipients 534 along that path, or 536 * Separate the transfers into multiple, standrd 537 RFC2821.Rcpt-To and ESMTP sessions, in order to provide 538 the best conversions possible for subsets of the 539 recipients. 541 If the transfers are to be separated, then the current 542 session MUST be terminated, and new sessions conducted 543 for each subset. 545 The conversions that are performed are determined by 546 the intersection of three lists: 548 * Conversions permitted by the originator 549 * Content capabilities of the target 550 * Conversions that can be performed by the SMTP client 551 host 553 Failed Conversion 555 If the result of this intersection is the null set of 556 representations, for an addressee, then delivery to 557 that addressee MUST be handled as a conversion failure. 559 If handling is subject to the CONPERM mechanism and: 561 * the next-hop SMTP host does not indicate that it can 562 represent the target's capabilities through CONNEG, but 564 * does respond that it can support CONPERM, 566 then the client SMTP MUST send the existing content, 567 if all other SMTP transmission requirements are 568 satisfied. 570 If handling is not subject to the CONPERM mechanism, 571 then conversion failures do not affect message 572 delivery. 574 3.3. Next-Hop Non-Support of Service 576 If a Client is participating in the CONPERM mechanism, 577 but the next-hop SMTP server does not support CONPERM 578 and does not support CONNEG, then the SMTP client 580 (1) MUST terminate the session to the next-hop SMTP server, 581 without sending the message 583 (2) MUST return a DSN notification to the originator, with status 584 code 5.6.3 (Conversion required but not supported). [DSN, 585 DSNFMT, SYSCOD] 587 If a Client is participating in the CONPERM mechanism 588 and the next-hop SMTP server supports CONNEG but 589 provides no capabilities for an individual RCPT-TO 590 addressee, then the SMTP client's processing for that 591 recipient MUST be either to: 593 (1) Treat the addressee as a conversion failure, or 595 (2) Separate the addressee from the address list that is 596 processed according to CONNEG, and continue to process the 597 addressee according to CONPERM. 599 4. CONTENT CONVERSION PERMISSION SMTP EXTENSION 601 4.1. Content Conversion Permission Service Extension 602 Definition 604 (1) The name of the SMTP service extension is 606 "Content_Conversion_Permission" 608 (2) The EHLO keyword value associated with this extension 609 is 611 "CONPERM" 613 (3) A parameter using the keyword "CONPERM" is added to the 614 MAIL-FROM command. 616 (4) The server responds with acceptance or rejection of 617 support for CONPERM, for this message. 619 4.2. CONPERM Parameter to Mail-From 621 Parameter: 623 CONPERM 625 Arguments: 627 There are no arguments. Specification of 628 permitted conversions is located in a Content-Convert 629 header for each MIME body-part for which conversion is 630 permitted. 632 Client Action: 634 If the server issued a 250-CONPERM, as part of its 635 EHLO response for the current session and the client is 636 participating in the CONPERM service for this message - 637 - such as by having received the message with a CONPERM 638 requirement -- then the client MUST issue the CONPERM 639 parameter in the MAIL-FROM. If the server does not 640 issue 250-CONPERM, and the client is participating in 641 the CONPERM service for this message, then the client 642 MUST treat the transmission as permanently rejected. 644 Server Action: 646 If the client specifies CONPERM in the MAIL-FROM, 647 but the server does not support the CONPERM parameter, 648 the server MUST reject the MAIL-FROM command with a 504- 649 CONPERM reply. 651 If the client issues the CONPERM parameter in the 652 MAIL-FROM, then the server MUST conform to this 653 specification. Either it MUST relay the message 654 according to CONPERM, or it MUST convert the message 655 according to CONNEG information. 657 4.3. Syntax 659 Content_Conversion_Permission = "CONPERM" 661 5. CONTENT NEGOTIATION SMTP EXTENSION 663 5.1. Content Negotiation Service Extension Definition 665 (1) The name of the SMTP service extension is: 667 "Content_Negotiation" 669 (2) The EHLO keyword value associated with this extension 670 is: 672 "CONNEG" 674 (3) A parameter using the keyword "CONNEG" is added to the 675 RCPT-TO command 677 (4) The server responds with a report of the content 678 capabilities of each device or system that embodies 679 the corresponding target RCPT-TO address 681 5.2. CONNEG parameter to RCPT-TO 683 Parameter: 685 CONNEG 687 Arguments: 689 There are no arguments. 691 Client Action: 693 If a message is subject to CONPERM requirements and 694 the server issues a 250-CONNEG, as part of its EHLO 695 response for the current session, the client MUST issue 696 the CONNEG parameter in the RCPT-TO request. If the 697 message is not subject to CONPERM requirements and the 698 server issues a 250-CONNEG, the client MAY issue the 699 CONNEG parameter with RCPT-TO. 701 If the client issues the CONNEG parameter with 702 RCPT-TO, then it MUST honor the capabilities returned 703 in the CONNEG RCPT-TO replies for that message, and it 704 MUST convert the message content, if the current form 705 of the content is not included in the recipient 706 capabilities. 708 The conversions that are performed are determined 709 by the intersection of the: 711 * Conversions permitted by the originator 712 * Content capabilities of the target 713 * Conversions that can be performed by the SMTP client 714 host 716 If the result of this intersection is the null set 717 of representations, then the Client processing depends 718 upon whether the next-hop server has offered CONPERM, as well as 719 CONNEG: 721 (1) If the message will be subject to CONPERM at the next 722 hop, the Client MAY to transmit the original content 723 to the next hop, continuing CONPERM requirements. 725 (2) Otherwise, the Client MUST treat the conversion as 726 failed. 728 If the result of the intersection is not null, the 729 client SHOULD convert the data to the "highest" level 730 of capability of the server. Determination of the 731 level that is highest is left to the discretion of the 732 host performing the conversion. 734 Each converted MIME body-part, MUST have a Content- 735 Previous header that indicates the previous body-part 736 form and a Content-Features header, indicating the new 737 body-part form. 739 Server Action: 741 If the client specifies CONNEG in the RCPT-TO, but 742 the server does not support the CONNEG parameter, the 743 server MUST reject the RCPT-TO addressees with 504 744 replies. 746 If the server does support the CONNEG parameter 747 and it knows the capabilities of the target device or 748 system, then it MUST provide that information through 749 CONNEG. 751 The response to a CONNEG RCPT-TO request will be 752 multi-line RCPT-TO replies. For successful (250) 753 responses, at least the first line of the response is 754 for RCPT-TO information other than CONNEG. Additional 755 response lines are for CONNEG. In order to avoid 756 problems due to variations in line buffer sizes, the 757 total parametric listing must be provided as a series 758 of lines, each beginning with "250-CONNEG" except for 759 the last line, which is "250 CONNEG". 761 The contents of the capability listing MUST 762 conform to the specifications in [SYN]. 764 5.3. Syntax 766 Content_Negotiation = "CONNEG" 767 Capability = <> 769 6. MIME CONTENT-CONVERT HEADER 771 Content-Convert is a header field that specifies permitted 772 conversions for the associated content. It MAY be used 773 without the other mechanisms defined in this document. 774 If present, this header MUST be carried unmodified and 775 delivered to the recipient. In its absence the content 776 originator has provided no guidance about content conversions, 777 and intermediaries SHOULD NOT perform content conversion. 779 In the extended ABNF notation, the Content-Convert 780 header field is defined as follows: 782 Convert = "Content-convert" ":" 783 permitted 785 Permitted = "ANY" / "NONE" / 786 <> 789 If the permitted conversions are specified as "ANY" 790 then the intermediary may perform any conversions it 791 deems appropriate. 793 If the permitted conversions are specified as "NONE" 794 then the intermediary SHOULD NOT perform any 795 conversions to this MIME body-part, even when the 796 target device or system does not support the original 797 form of the content. 799 7. MIME CONTENT-PREVIOUS HEADER 801 When an intermediary has performed conversion of the 802 associated content, the intermediary MUST record 803 details of the previous representation, from which the 804 conversion was performed. This information is placed 805 in a Content-Previous header that is associated with 806 the MIME body-part having converted content. There is 807 a separate header for each, converted MIME body-part. 809 In the extended [ABNF] notation, the Content-Previous 810 header field is defined as follows: 812 previous = "Content-Previous" [CFWS] ":" 813 [CFWS] 814 date by type 816 date "Date " [CFWS] date-time [CFWS]";" 817 [CFWS] 819 by "By " [CFWS] domain [CFWS]";" 820 [CFWS] 822 type = <> 825 The Date field specifies the date and time at which the 826 indicated representation was converted into a newer 827 representation. 829 The By field specifies the domain name of the 830 intermediary that performed the conversion. 832 An intermediary MAY choose to derive the Content- 833 Previous header, for a body-part, from an already- 834 existing Content-Features header in that body-part, 835 before that header is replaced with the description of 836 the current representation. 838 8. MIME CONTENT-FEATURES HEADER 840 When an intermediary has performed conversion, the 841 intermediary MUST record details of the result of the 842 conversion that was performed. This information is 843 placed in a Content-Features header associated with 844 each MIME body-part having converted content. There is 845 a separate Content-Features header for each MIME body- 846 part. 848 The specification for this header is contained in 849 [FEAT]. 851 9. EXAMPLES 853 9.1. CONPERM Negotiation 855 S: 220 example.com IFAX 856 C: EHLO example.com 857 S: 250- example.com 858 S: 250-DSN 859 S: 250 CONPERM 860 C: MAIL FROM:May@some.example.com CONPERM 861 S: 250 originator ok 862 C: RCPT TO: 863 S: 250- recipient ok 864 C: DATA 865 S: 354 okay, send data 866 C: <> 893 S: 250 message accepted 894 C: QUIT 895 S: 221 goodbye 897 9.2. Example CONNEG Negotiation 899 S: 220 example.com IFAX 900 C: EHLO example.com 901 S: 250- example.com 902 S: 250-DSN 903 S: 250 CONNEG 904 C: MAIL FROM: 905 S: 250 originator ok 906 C: RCPT TO: CONNEG 907 S: 250- recipient ok 908 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 909 S: 250-CONNEG (MRC-mode=0) 910 S: 250-CONNEG (color=Binary) 911 S: 250-CONNEG (|(&(dpi=204) 912 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 913 S: 250-CONNEG (&(dpi=200) 914 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 915 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 916 S: 250-CONNEG (size-x<=2150/254) 917 S: 250-CONNEG (paper-size=[letter,A4]) 918 S: 250 CONNEG (ua-media=stationery) ) 919 C: DATA 920 S: 354 okay, send data 921 C: <> 930 S: 250 message accepted 931 C: QUIT 932 S: 221 goodbye 934 9.3. Content-Previous 936 Content-Previous: 937 Date Tue, 1 Jul 2001 10:52:37 +0200; 938 By relay.example.com; 939 (&(image-file-structure=TIFF-minimal) 940 (MRC-mode=0) 941 (color=Binary) 942 (&(dpi=400) 943 (dpi-xyratio=1) ) 944 (&(image-coding=JBIG) 945 (image-coding-constraint=JBIG-T85) 946 (JBIG-stripe-size=128) ) 947 (size-x=2150/254) 948 (paper-size=A4) 949 (ua-media=stationery) ) 951 10. IANA CONSIDERATIONS 953 There are no IANA considerations regarding this document. 955 11. SECURITY CONSIDERATIONS 957 This service calls for recipients to disclose their 958 capabilities. Mechanisms for determining the 959 requestor's and the respondent's authenticated identity 960 are outside the scope of this specification. It is 961 intended that these mechanisms permit disclosure of 962 information that can safely be public; hence there is 963 no inherent need for security measures. 965 Information that should receive restricted distribution 966 is still able to be disclosed. It is, therefore, the 967 responsibility of the disclosing ESMTP server or 968 disclosing ESMTP client to determine whether additional 969 security measures should be applied to the use of this 970 ESMTP option. 972 Use of the ESMTP CONNEG option permits content transformation 973 by an intermediary, along the mail transfer path. When 974 the contents are encrypted, the intermediary cannot perform 975 the conversion, unless it has access to the relevant secret 976 information. When the contents are signed, but they remain 977 in the clear, conversion will invalidate the signature. 979 This specification provides for potentially unbounded computation 980 by intermediary MTAs, depending upon the nature and amount 981 of conversion required. Further, this computation burden might 982 provide an opportunity for denial-of-service attacks, given that 983 Internet mail typically permits intermediaries to receive messages 984 from all Internet sources. 986 This specifiction provides for content conversion by 987 unspecified intermediaries. Use of this mechanism 988 carries significant risk. Although intermediaries 989 always have the ability to perform damaging 990 transformations, use of this specification could result 991 in more exploration of that potential and, therefore, 992 more misbehavior. Use of intermediaries is discussed 993 in [RFC3238]. 995 Conperm/Conneg provide a cooperative mechanism, rather than 996 enabling intermediary actions that have not previously been 997 possible. Intermediaries already can and do make conversions 998 on their own initiative. Hence the mechanism introduces 999 essentially no security concerns, other than divulging 1000 recipient preferences. 1002 12. ACKNOWLEDGEMENTS 1004 Graham Klyne and Eric Burger provided extensive, 1005 diligent reviews and suggestions. Keith Moore and Giat 1006 Hana provided feedback that resulted in improving the 1007 specification's integration into established email 1008 practise. 1010 13. REFERENCES 1012 Normative: 1014 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 1015 Specifications: ABNF", RFC 2234, November 1997. 1017 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 1018 Indicate Requirement Levels", RFC2119, March 1997 1020 [CONMSG] Klyne, G., Iwazaki, R., Crocker. D., , 1021 "Content Negotiation for Messaging 1022 Services based on Email", RFC 3297, July 1023 2002. 1025 [DISP] Masinter, L., Holtman, K., Mutz, A. and 1026 D. Wing, "Media Features for Display, 1027 Print, and Fax", RFC 2534, March 1999. 1029 [DSN] Moore, K. "Simple Mail Transfer Protocol (SMTP) 1030 Service Extension for Delivery Status 1031 Notifications (DSNs)", RFC 3461, January 2003 1033 [DSNFMT] K. Moore and G. Vaudreuil, "An Extensible Message 1034 Format for Delivery Status Notifications", 1035 RFC 3464, January 2003. 1037 [SYSCOD] Vaudreuil, G., "Enhanced Mail System Status 1038 Codes", RFC3463, January 2003. 1040 [ESMTP1] Klensin, J., Freed, N., Rose, M., 1041 Stefferud, E. and D. Crocker, "SMTP 1042 Service Extensions", RFC 1869, November 1043 1995 1045 [ESMTP2] Klensin, J., "Simple Mail Transfer 1046 Protocol", RFC 2821, April 2001. 1048 [FEAT] Klyne, G., "Indicating Media Features 1049 for MIME Content", RFC 2912, September 1050 2000 1052 [IMF] Resnick, P., "Internet Message Format", 1053 RFC 2822, April 2001 1055 [TAG] Holtman, K., Mutz, A. and T. Hardie, 1056 "Media Feature Tag Registration 1057 Procedure", RFC 2506, March 1999. 1059 [SYN] Klyne, G. "A Syntax for Describing Media 1060 Feature Sets", RFC 2533, March 1999 1062 [MEDTYP] IANA, "MIME Media Types", 1063 1065 Informative: 1067 [RFC3238] Floyd, S., Daigle, L., "IAB Architectural 1068 and Policy Considerations for Open Pluggable 1069 Edge Services", RFC 3238, January 2002 1071 14. AUTHORS' ADDRESSES 1073 Kiyoshi Toyoda 1074 Network Technology Development Center 1075 Panasonic Communications Co., Ltd. 1076 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 1078 tel: +81-3-5745-3921 1079 fax: +81-3-5434-7156 1080 toyoda.kiyoshi@jp.panasonic.com 1082 Dave Crocker 1083 Brandenburg InternetWorking 1084 675 Spruce Drive 1085 Sunnyvale, CA 94086 USA 1087 Tel: +1.408.246.8253 1088 dcrocker@brandenburg.com 1090 15. INTELLECTUAL PROPERTY STATEMENT 1092 The IETF takes no position regarding the validity or scope of any 1093 intellectual property or other rights that might be claimed to 1094 pertain to the implementation or use of the technology described in 1095 this document or the extent to which any license under such rights 1096 might or might not be available; neither does it represent that it 1097 has made any effort to identify any such rights. Information on the 1098 IETF's procedures with respect to rights in standards-track and 1099 standards-related documentation can be found in BCP-11. Copies of 1100 claims of rights made available for publication and any assurances of 1101 licenses to be made available, or the result of an attempt made to 1102 obtain a general license or permission for the use of such 1103 proprietary rights by implementors or users of this specification can 1104 be obtained from the IETF Secretariat. 1106 The IETF invites any interested party to bring to its attention any 1107 copyrights, patents or patent applications, or other proprietary 1108 rights which may cover technology that may be required to practice 1109 this standard. Please address the information to the IETF Executive 1110 Director. 1112 16. FULL COPYRIGHT STATEMENT 1114 Copyright (C) The Internet Society (2003). All Rights 1115 Reserved. 1117 This document and translations of it may be copied and 1118 furnished to others, and derivative works that comment 1119 on or otherwise explain it or assist in its 1120 implementation may be prepared, copied, published and 1121 distributed, in whole or in part, without restriction 1122 of any kind, provided that the above copyright notice 1123 and this paragraph are included on all such copies and 1124 derivative works. However, this document itself may 1125 not be modified in any way, such as by removing the 1126 copyright notice or references to the Internet Society 1127 or other Internet organizations, except as needed for 1128 the purpose of developing Internet standards in which 1129 case the procedures for copyrights defined in the 1130 Internet Standards process must be followed, or as 1131 required to translate it into languages other than 1132 English. 1134 The limited permissions granted above are perpetual and 1135 will not be revoked by the Internet Society or its 1136 successors or assigns. 1138 This document and the information contained herein is 1139 provided on an "AS IS" basis and THE INTERNET SOCIETY 1140 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1141 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1142 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1143 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1144 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1145 PARTICULAR PURPOSE. 1147 APPENDIX A: CONNEG WITH DIRECT SMTP 1149 In some configurations it is possible to have direct 1150 email-based interactions -- where the originator's 1151 system conducts a direct, interactive TCP connection 1152 with the recipient's system. This configuration 1153 permits a use of the content form negotiation service 1154 that conforms to the specification here, but permits 1155 some simplifications. This single SMTP session does 1156 not have the complexity of multiple, relaying sessions 1157 and therefore does not have the requirement for 1158 propagating permissions to intermediaries. 1160 The Originator's system provides user-level functions 1161 for the originator, and it contains the SMTP Client for 1162 sending messages. Hence, the formal step of email 1163 "posting" is a process that is internal or virtual, 1164 within the Originating system. The recipient's service 1165 contains the user-level functions for the recipient, 1166 and it contains the SMTP server, for receiving 1167 messages. Hence the formal steps of email "delivering" 1168 and "receipt" are internal or virtual, within the 1169 Receiving system. 1171 Figure 4: DIRECT CONNEG 1173 Originating system Receiving system 1174 +------------------+ +------------------+ 1175 | +------------+ | | +-----------+ | 1176 | | Originator | | | | Recipient | | 1177 | +------------+ | | +-----------+ | 1178 | ||Posting | | /\Receiving | 1179 | \/ | | || | 1180 | +---------+ | | +--------+ | 1181 | | SMTP |<---|-------|----| SMTP | | 1182 | | Client |----|-------|--->| Server | | 1183 | +---------+ | | +--------+ | 1184 +------------------+ +------------------+ 1186 In this case CONPERM is not needed, because the SMTP 1187 Client is part of the originating system. Therefore it 1188 already has the necessary permission. Similarly, the 1189 SMTP server will be certain to know the recipient's 1190 capabilities, because the server is part of the 1191 receiving system. 1193 Therefore, Direct Mode email transmission can achieve 1194 content capability and form matching by having: 1196 * Originating systems that conform to this specification 1197 and a communication process between originator and recipient 1198 that is the same as would take place between a last-hop SMTP 1199 Relay and the Delivering SMTP server it connects to. 1201 * That is, the Client and Server MUST employ CONNEG and 1202 the Client MUST perform any requisite conversions. 1204 APPENDIX B: CHANGES TO THIS DRAFT (TO BE REMOVED BY RFC EDITOR) 1206 Fixed a few typos. 1208 Explicitly noted that there are no IANA considerations. 1210 Added IPR disclosure statement, according to RFC 3667. 1212 Noted that the mechanism for enabling server to issue conneg 1213 information may require substantial mechanism between MUA and 1214 server. 1216 Added citation to ABNF. 1218 Changes in Service Specification section 1219 Noted potentially inferior result from performing sequence of 1220 conversions along the message path. 1222 Clarified that splitting message rcpt-to list is accomplished 1223 by using standard SMTP procedures. 1225 Noted the likely functional conflict between conversion 1226 versus encryption-based security. 1228 Changes in Content Negotiation SMTP extension section 1229 Clarification of text about handling empty intersection goals 1230 between conperm and conneg. 1232 Changes in Security Considerations section 1233 Noted risk of conversion by intermediary. OPES citation. 1235 Added Security section warning about conversion by 1236 intermediaries. 1238 Noted potential impact of computational load on intermediary 1239 that does conversions. 1241 Added note observing that conperm/conneg provides a 1242 cooperative mechanism, rather than enabling intermediary 1243 actions that have not previously been possible. 1244 Intermediaries already can and do make conversions on their 1245 own initiative. Hence the mechanism introduces essentially no 1246 security concerns, other than divulging recipient 1247 preferences.