idnits 2.17.1 draft-ietf-fax-esmtp-conneg-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 1174 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 285: '... Intermediaries MAY interpret the pre...' RFC 2119 keyword, line 293: '... The originator MAY also specify tran...' RFC 2119 keyword, line 296: '...ge. Conversions MUST be limited to th...' RFC 2119 keyword, line 320: '...ent capabilities SHOULD be communicate...' RFC 2119 keyword, line 336: '... An intermediary MAY be given CONPERM ...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 866 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 2003) is 7438 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 938 looks like a reference -- Missing reference section? 'CONMSG' on line 958 looks like a reference -- Missing reference section? 'KEYWORDS' on line 238 looks like a reference -- Missing reference section? 'DSN' on line 922 looks like a reference -- Missing reference section? 'SYN' on line 953 looks like a reference -- Missing reference section? 'FAX' on line 934 looks like a reference -- Missing reference section? 'CFWS' on line 748 looks like a reference -- Missing reference section? 'DISP' on line 918 looks like a reference -- Missing reference section? 'ESMTP1' on line 926 looks like a reference -- Missing reference section? 'ESMTP2' on line 931 looks like a reference -- Missing reference section? 'IMF' on line 942 looks like a reference -- Missing reference section? 'TAG' on line 945 looks like a reference -- Missing reference section? 'SETS' on line 949 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Toyoda / MGCS Internet 2 Draft D. Crocker / Brandenburg 3 draft-ietf-fax-esmtp-conneg-09.txt December 2003 5 Expires: <06-04> 7 SMTP and MIME Extensions 8 For Content Conversion 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full 13 conformance with all provisions of Section 10 of 14 RFC2026. Internet-Drafts are working documents of the 15 Internet Engineering Task Force (IETF), its areas and 16 its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum 20 of six months and may be updated, replaced, 21 or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be 30 accessed at 31 http://www.ietf.org/shadow.html. 33 COPYRIGHT NOTICE 35 Copyright (C) The Internet Society (2003). All Rights 36 Reserved. 38 SUMMARY 40 A message originator sometimes sends content in a form 41 the recipient cannot process. Such content needs to be 42 converted to a related form, with the same or with 43 restricted information, such as changing from color to 44 black and white. In a store-and-forward environment, 45 it can be convenient to have this conversion performed 46 by an intermediary. This specification integrates two 47 ESMTP extensions and three MIME content headers, to 48 permit authorized, accountable content form conversion 49 by intermediaries. 51 CONTENTS 53 1. Introduction 54 1.1. Background 55 1.2. Overview 56 1.3. Conventions 58 2. Service Specification 59 2.1. Sending Permission 60 2.2. Returning Capabilities 61 2.3. Next-Hop Non-Support of Service 63 3. Content Conversion Permission SMTP Extension 64 3.1. Content Conversion Permission Service Extension 65 Definition 66 3.2. CONPERM Parameter to Mail-From 67 3.3. Syntax 69 4. Content Negotiation SMTP extension 70 4.1. Content Negotiation Service Extension Definition 71 4.2. CONNEG parameter to RCPT-TO 72 4.3. Syntax 74 5. MIME Content-Convert Header 76 6. MIME Content-Previous Header 78 7. MIME Content-Features Header 80 8. Examples 81 8.1. CONPERM Negotiation 82 8.2. Example CONNEG Negotiation 83 8.3. Content-Previous 85 9. IANA Considerations 87 10. Security Considerations 89 11. Acknowledgements 91 12. References 93 13. Authors' Addresses 95 14. Full Copyright Statement 97 Appendix A: CONNEG with Direct SMTP 99 1. INTRODUCTION 101 Internet specifications typically define common 102 capabilities that are to supported by all participants 103 for a particular service. This permits sending basic 104 data without needing to know the additional 105 capabilities supported by individual recipients. 106 However, knowing those capabilities permits sending 107 additional types of data and data of enhanced richness. 108 Otherwise, a message originator is faced with sending 109 content in a form the recipient cannot process or with 110 sending multiple forms of data. This specification 111 enables MIME content conversion on behalf of a message 112 originator and a message recipient. 114 1.1. Background 116 MIME enables distinguishing and labeling different 117 types of content. However an originator cannot know 118 whether a recipient is able to support (interpret) any 119 particular data type. In order to permit basic use of 120 MIME, a minimum set of data types are specified as its 121 support base. How is an originator to know whether a 122 recipient can support any other types? 124 A mechanism for describing MIME types is specified in 125 [FEAT]. A mechanism that permits an originator to query 126 a recipient about the types it supports, by using mail 127 messages for the control exchange, is specified in 128 [CONMSG]. In particular, this permits a recipient to 129 propagate information about its capabilities back to an 130 originator. Obviously, using end-to-end email messages 131 for the control exchange introduces considerable 132 latency and some unreliability. 134 An alternative approach is for an originator to use the 135 "best" form of data that it can, and hope that the 136 recipient, or an intermediary, can translate this into 137 a form that is supported by a limited recipient. The 138 current document defines such a mechanism. It defines a 139 means of matching message content form to the 140 capabilities of a recipient device or system, by using 141 MIME content descriptors and the optional use of an 142 SMTP-based negotiation mechanism. 144 1.2. Overview 146 An originator describes desirable content forms, in 147 MIME content descriptors. It further may give 148 "permission", to any intermediary or the recipient, to 149 convert the content to only one of those forms. 150 Separately, an SMTP server may report the target's 151 content capabilities back to the SMTP client. The 152 client is then able to convert message content to a 153 form that is both supported by the target system and is 154 acceptable to the originator. 156 A conversion service needs to balance between 157 directions provided by the originator, directions 158 provided by the recipient, and capabilities of the 159 intermediary that is performing the conversions. This 160 is made more complex by needing to distinguish between 161 such directions being merely advisory, versus having 162 them intended as requirements. Conversions that are 163 specified as advisory are performed if possible, but 164 they do not alter message delivery. In contrast, 165 conversion specifications that are treated as a 166 requirement prohibit delivery if the recipient will be 167 unable to process the content. 169 These possibilities interact to form different 170 processing scenarios, in the event the intermediary 171 cannot satisfy the desires of both the originator and 172 the recipient: 174 Table 1: FAILURE HANDLING 176 \ RECEIVER| | | 177 +-------+ | Advise | Require | 178 ORIGINATOR\| | | 179 -----------+----------+----------+ 180 | Deliver | Deliver | 181 Advise | original | original | 182 | content | content | 183 -----------+----------+----------+ 184 | Return | Return | 185 Require | w/out | w/out | 186 | delivery | delivery | 187 -----------+----------+----------+ 189 This table reflects a policy that determines failure 190 handling solely based on the direction provided by the 191 originator. Hence, information from the recipient is 192 used to guide the details of conversion, but not to 193 decide whether to deliver the message. 195 This is intended to continue existing email practise of 196 delivering content that a recipient might not be able 197 to process. Clearly the above table could be modified 198 to reflect a different policy. However that would 199 limit the backward compatibility experienced by users. 201 This specification provides mechanisms to support a 202 controlled, transit-time mail content conversion 203 service, through a series of mechanisms. These 204 include: 206 * an optional ESMTP hop-by-hop service that uses the 207 CONPERM SMTP service extensions, issued by the originator, 209 * an optional ESMTP hop-by-hop service that uses the 210 CONNEG SMTP service extensions, issued by the recipient, and 212 * three MIME Content headers (Content-Convert, Content- 213 Converted and Content-Features) that specify appropriate 214 content headers and record conversions that have been 215 performed. 217 Figure 1: EXAMPLE RELAY ENVIRONMENT 219 +------------+ +-----------+ 220 | Originator | | Recipient | 221 +------------+ +-----------+ 222 ||Posting Delivering/\ 223 \/ || 224 +--------+ +-----------------+ +--------+ 225 | SMTP | | SMTP Relay | | SMTP | 226 | Client |--->| Server | Client |--->| Server | 227 +--------+ +--------+--------+ +--------+ 229 1.3. Conventions 231 In examples, "C:" and "S:" indicate lines sent by the 232 client and server respectively. 234 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 235 NOT" and "MAY" in this document are to be interpreted 236 as defined in "Key words for use in RFCs to Indicate 237 Requirement Levels" [KEYWORDS]. 239 2. SERVICE SPECIFICATION 241 This service integrates two ESMTP extensions and three 242 MIME content headers, to permit authorized, accountable 243 content form conversion by intermediaries. 244 Intermediaries are ESMTP hosts (clients and servers) 245 along the transmission path between an originator and a 246 recipient. 248 An originator specifies preferred content-types through 249 the Content-Convert MIME content header. The content 250 headers occur in each MIME body-part to which they 251 apply. That is, each MIME body-part contains its own 252 record of conversion guidance and history. 254 The originator's preference's are raised to the level 255 of requirement, through the ESMTP CONPERM service 256 extension. The CONPERM mechanism is only needed when 257 an originator requires that conversion limitations be 258 enforced by the mail service. If an acceptable content 259 type cannot be delivered, then no delivery is to take 260 place. 262 Target system capabilities are communicated in SMTP 263 sessions through the ESMTP CONNEG service extension. 264 This information is used to restrict the range of 265 conversions that may be performed, but does not affect 266 delivery. 268 When CONPERM is used, conversions are performed by the 269 first ESMTP host that can obtain both the originator's 270 permission and the recipient's capabilities. If a 271 relay or client is unable to transmit the message to a 272 next-hop that supports CONPERM or to perform 273 appropriate conversion, then it terminates message 274 transmission and returns a [DSN] to the originator. 276 When an SMTP relay or server performs content 277 conversion, it records which specific conversions are 278 made, into Content-Converted and Content-Features MIME 279 headers associated with each, converted MIME body-part. 281 Originator Action: 283 An originator specifies desired conversion 284 results, through the MIME Content-Convert header. 285 Intermediaries MAY interpret the presence of this 286 header as authorization to perform conversions. When 287 Content-Convert headers are the sole means for guiding 288 conversions by intermediaries, then they serve only as 289 advisories. In particular, failure to satisfy the 290 guidance of these headers does not affect final 291 delivery. 293 The originator MAY also specify transit-service 294 enforcement of conversion limitations by using the 295 ESMTP CONPERM service extension when posting a new 296 message. Conversions MUST be limited to those 297 specified in MIME Content-Convert headers, in each MIME 298 body-part for which conversions are authorized. If 299 conversion is needed, but an authorized conversion 300 cannot be performed, then the message is returned to 301 the originator. If CONPERM is not used, then failure 302 to perform an authorized conversion does not affect 303 normal delivery handling. 305 Figure 2: CONPERM USAGE 307 +------------+ 308 | Originator | 309 +------------+ 310 SMTP || 311 or || CONPERM 312 SUBMIT \/ 313 +--------+ +----------------+ 314 | SMTP | SMTP | SMTP Relay | 315 | Client |----------->| Server | | 316 +--------+ CONPERM +--------+-------+ 318 Recipient Action: 320 Recipient capabilities SHOULD be communicated to 321 intermediaries by the ESMTP CONNEG service extension. 323 Figure 3: CONNEG USAGE 324 +-----------+ 325 | Recipient | 326 +-----------+ 327 Capabilities|| 328 \/ 329 +----------------+ +--------+ 330 | SMTP Relay | CONNEG | SMTP | 331 | | Client |<--------| Server | 332 +-------+--------+ +--------+ 334 Intermediary Actions: 336 An intermediary MAY be given CONPERM direction 337 when receiving a message, and MAY be given CONNEG 338 guidance, before sending the message. CONPERM and 339 CONNEG operate on a per-message basis. Therefore they 340 are issued through the ESMTP MAIL-FROM request. CONNEG 341 response information is provided on a per-recipient 342 basis, through the response to ESMTP RCPT-TO. 344 Conversion MUST be performed by the first CONPERM 345 intermediary that obtains CONNEG recipient capability 346 information. When an intermediary obtains different 347 capability information for different recipients of the 348 same message, it MAY either: 350 * Create a single, converted copy of the content that can 351 be supported by all of the recipients, or 353 * Create multiple converted copies, matching the 354 capabilities of subsets of the recipients. Each version is 355 then sent separately, to an appropriate subset of the 356 recipients. 358 A record of conversions is placed into MIME 359 Content-Previous headers. The current form of the 360 content is provided in MIME Content-Features headers. 362 A special case of differential capabilities occurs 363 when an intermediary receives capability information 364 about some recipients, but no information about others. 365 An example of this scenario can occur when sending a 366 message to some recipients within one's own 367 organization and other recipients located elsewhere. 368 The intermediary might have capability information 369 about the local recipients, but will not have any for 370 distant recipients. This is treated as a variation of 371 the handling required when the permissible conversions 372 are the null set -- that is, no valid conversions are 373 possible for a recipient. 375 Rather than simply failing transmission to the 376 recipients for which there is no capability 377 information, the intermediary MAY choose to continue 378 the transmission of the original content to those 379 recipients, via the continued use of the CONPERM 380 mechanism. Hence, the handling for such recipients is 381 performed as if no CONNEG transaction took place. 383 Once an intermediary has performed conversion, it 384 MAY terminate use of CONPERM. However some relay 385 environments, such as those re-directing mail to a new 386 target device, will benefit from further conversion. 387 Intermediaries MAY continue to use CONPERM or MAY re- 388 initiate CONPERM use, when they have knowledge about 389 possible variations in target device. 391 2.1. Sending Permission 393 A message originator that permits content conversion by 394 intermediaries MAY use the CONPERM ESMTP service 395 extension and Content-Convert MIME headers to indicate 396 what conversions are permitted by intermediaries. 397 Other mechanisms by which a message originator 398 communicates this permission to the SMTP message 399 transfer service are outside the scope of this 400 specification. 402 When an ESMTP client is authorized to participate in 403 the CONPERM service it MUST interact with the next SMTP 404 hop server, about: 406 * The server's ability to support authorized conversions, 407 through ESMTP CONPERM 409 * The capabilities supported for the target device or 410 system, through ESMTP CONNEG 412 Successful use of CONPERM does not require that 413 conversion take place along the message transfer path. 414 Rather, it requires that conversion take place whenever 415 a next-hop server reports recipient capabilities, 416 through CONNEG, and those capabilities do not include 417 support for the current representation of the content. 419 It is acceptable to have every SMTP server -- including 420 the last-hop server -- support CONPERM, with none 421 offering CONNEG. In this case, the message is 422 delivered to the recipient in its original form. Any 423 possible conversions to be performed are left to the 424 recipient. Hence the recipient is given the original 425 form of the content, along with an explicit list of 426 conversions that the originator deems acceptable. 428 An SMTP server MAY offer ESMTP CONPERM, without being 429 able to perform conversions, if it knows that 430 conversions can be performed by the target device or 431 system. 433 2.2. Returning Capabilities 435 A target recipient device or system communicates its 436 content form capabilities to the SMTP service through a 437 means outside the scope of this specification. When an 438 ESMTP server knows a target's capabilities, it MAY 439 offer the CONNEG ESMTP service extension. 441 When a message is being processed according to the 442 CONPERM mechanism, if a next-hop ESMTP server responds 443 that it supports CONNEG, then the SMTP client: 445 (1) MUST request CONNEG information 447 (2) MUST perform the requisite conversions, if possible, 448 before sending the message to the next-hop SMTP server 450 (3) MUST fail message processing, if any conversion for the 451 message fails and MUST return a failure DSN to the 452 originator 454 When performing conversions, as specified in Content- 455 Convert MIME headers, the Client MUST: 457 (1) Add a Content-Previous header and a Content-Features 458 header to each MIME body-part that has been converted. 460 (2) Either: 462 * Send a single copy to the next-hop SMTP server, using a 463 best capabilities that are supported to all recipients along 464 that path, or 466 * Separate the transfers, to provide the best conversions 467 possible for subsets of the recipients. 469 If the transfers are separated, then the current 470 session MUST be terminated, and new sessions conducted 471 for each subset. 473 The conversions that are performed are determined by 474 the intersection of three lists: 476 * Conversions permitted by the originator 477 * Content capabilities of the target 478 * Conversions that can be performed by the SMTP client 479 host 481 Failed Conversion 483 If the result of this intersection is the null set of 484 representations, for an addressee, then delivery to 485 that addressee MUST be handled as a conversion failure. 487 If handling is subject to the CONPERM mechanism and: 489 * the next-hop SMTP host does not indicate that it can 490 represent the target's capabilities through CONNEG, but 492 * does respond that it can support CONPERM, 494 then the client SMTP MUST send the existing content, 495 if all other SMTP transmission requirements are 496 satisfied. 498 If hanling is not subject to the CONPERM mechanism, 499 then conversion failures do not affect message 500 delivery. 502 2.3. Next-Hop Non-Support of Service 504 If a Client is participating in the CONPERM mechanism, 505 but the next-hop SMTP server does not support CONPERM 506 and does not support CONNEG, then the SMTP client 508 (1) MUST terminate the session to the next-hop SMTP server, 509 without sending the message 511 (2) MUST return a DSN notification to the originator that 512 content negotiation could not be performed. 514 If a Client is participating in the CONPERM mechanism 515 and the next-hop SMTP server supports CONNEG but 516 provides no capabilities for an individual RCPT-TO 517 addressee, then the SMTP client's processing for that 518 recipient MUST be either to: 520 (1) Treat the addressee as a conversion failure, or 522 (2) Separate the addressee from the address list that is 523 processed according to CONNEG, and continue to process the 524 addressee according to CONPERM. 526 3. CONTENT CONVERSION PERMISSION SMTP EXTENSION 528 3.1. Content Conversion Permission Service Extension 529 Definition 531 (1) The name of the SMTP service extension is 533 "Content_Conversion_Permission" 535 (2) The EHLO keyword value associated with this extension 536 is 538 "CONPERM" 540 (3) A parameter using the keyword "CONPERM" is added to the 541 MAIL-FROM command. 543 (4) The server responds with acceptance or rejection of 544 support for CONPERM, for this message. 546 3.2. CONPERM Parameter to Mail-From 548 Parameter: 550 CONPERM 552 Arguments: 554 There are no arguments. Specification of 555 permitted conversions is located in a Content-Convert 556 header for each MIME body-part for which conversion is 557 permitted. 559 Client Action: 561 If the server issued a 250-CONPERM, as part of its 562 EHLO response for the current session and the client is 563 participating in the CONPERM service for this message - 564 - such as by having received the message with a CONPERM 565 requirement -- then the client MUST issue the CONPERM 566 parameter in the MAIL-FROM. If the server does not 567 issue 250-CONPERM, and the client is participating in 568 the CONPERM service for this message, then the client 569 MUST treat the transmission as permanently rejected. 571 Server Action: 573 If the client specifies CONPERM in the MAIL-FROM, 574 but the server does not support the CONPERM parameter, 575 the server MUST reject the MAIL-FROM command with a 504- 576 CONPERM reply. 578 If the client issues the CONPERM parameter in the 579 MAIL-FROM, then the server MUST conform to this 580 specification. Either it MUST relay the message 581 according to CONPERM, or it MUST convert the message 582 according to CONNEG information. 584 3.3. Syntax 586 Content_Conversion_Permission = "CONPERM" 588 4. CONTENT NEGOTIATION SMTP EXTENSION 590 4.1. Content Negotiation Service Extension Definition 592 (1) The name of the SMTP service extension is: 594 "Content_Negotiation" 596 (2) The EHLO keyword value associated with this extension 597 is: 599 "CONNEG" 601 (3) A parameter using the keyword "CONNEG" is added to the 602 RCPT-TO command 604 (4) The server responds with a report of the content 605 capabilities of the device or system that embodies each 606 target RCPT-TO address. 608 4.2. CONNEG parameter to RCPT-TO 610 Parameter: 612 CONNEG 614 Arguments: 616 There are no arguments. 618 Client Action: 620 If message is subject to CONPERM requirements and 621 the server issues a 250-CONNEG, as part of its EHLO 622 response for the current session, the client MUST issue 623 the CONNEG parameter in the RCPT-TO request. If the 624 message is not subject to CONPERM requirements and the 625 server issues a 250-CONNEG, the client MAY issue the 626 CONNEG parameter with RCPT-TO. 628 If the client issues the CONNEG parameter with 629 RCPT-TO, then it MUST honor the capabilities returned 630 in the CONNEG RCPT-TO replies for that message, and it 631 MUST convert the message content, if the current form 632 of the content is not included in the recipient 633 capabilities. 635 The conversions that are performed are determined 636 by the intersection of the: 638 * Conversions permitted by the originator 639 * Content capabilities of the target 640 * Conversions that can be performed by the SMTP client 641 host 643 If the result of this intersection is the null set 644 of representations, then the Client processing depends 645 upon whether the message is subject to CONPERM 646 processing: 648 (1) If the message is subject to CONPERM, the Client MAY 649 continue to transmit the original content, according to 650 CONPERM. 652 (2) Otherwise, the Client MUST treat the conversion as 653 failed. 655 If the result of the intersection is not null, the 656 client SHOULD convert the data to the "highest" level 657 of capability of the server. Determination of the 658 level that is highest is left to the discretion of the 659 host performing the conversion. 661 Each converted MIME body-part, MUST have a Content- 662 Converted header that indicates the previous body-part 663 form and a Content-Features header, indicating the new 664 body-part form. 666 Server Action: 668 If the client specifies CONNEG in the RCPT-TO, but 669 the server does not support the CONNEG parameter, the 670 server MUST reject the RCPT-TO addressees with 504 671 replies. 673 If the server does support the CONNEG parameter 674 and it knows the capabilities of the target device or 675 system, then it MUST provide that information through 676 CONNEG. 678 The response to a CONNEG RCPT-TO request will be 679 multi-line RCPT-TO replies. For successful (250) 680 responses, at least the first line of the response is 681 for RCPT-TO information other than CONNEG. Additional 682 response lines are for CONNEG. In order to avoid 683 problems due to variations in line buffer sizes, the 684 total parametric listing must be provided as a series 685 of lines, each beginning with "250-CONNEG" except for 686 the last line, which is "250 CONNEG". 688 The contents of the capability listing MUST 689 conform to the specifications in [SYN, FAX]. 691 4.3. Syntax 693 Content_Negotiation = "CONNEG" 694 Capability = <> 696 5. MIME CONTENT-CONVERT HEADER 698 Content-Convert is an optional header field that 699 specifies permitted conversions for the associated 700 content. It MAY be used without the other mechanisms 701 defined in this document. If present, this header MUST 702 be carried unmodified and delivered to the recipient. 703 In its absence the content originator has provided no 704 guidance about content conversions, and intermediaries 705 SHOULD NOT perform content conversion. 707 In the extended ABNF notation, the Content-Convert 708 header field is defined as follows: 710 Convert = "Content-convert" ":" 711 permitted 713 Permitted = "ANY" / "NONE" / 714 <> 717 If the permitted conversions are specified as "ANY" 718 then the intermediary may perform any conversions it 719 deems appropriate. 721 If the permitted conversions are specified as "NONE" 722 then the intermediary SHOULD NOT perform any 723 conversions to this MIME body-part, even when the 724 target device or system does not support the original 725 form of the content. 727 6. MIME CONTENT-PREVIOUS HEADER 729 When an intermediary has performed conversion of the 730 associated content, the intermediary MUST record 731 details of the previous representation, from which the 732 conversion was performed. This information is placed 733 in a Content-Previous header that is associated with 734 the MIME body-part having converted content. There is 735 a separate header for each, converted MIME body-part. 737 In the extended ABNF notation, the Content-Previous 738 header field is defined as follows: 740 previous = "Content-Previous" [CFWS] ":" 741 [CFWS] 742 date by type 744 date "Date " [CFWS] date-time [CFWS]";" 745 [CFWS] 747 by "By " [CFWS] domain [CFWS]";" 748 [CFWS] 750 type = <> 753 The Date field specifies the date and time at which the 754 indicated representation was converted into a newer 755 representation. 757 The By field specifies the domain name of the 758 intermediary that performed the conversion. 760 An intermediary MAY choose to derive the Content- 761 Previous header, for a body-part, from an already- 762 existing Content-Features header in that body-part, 763 before that header is replaced with the description of 764 the current representation. 766 7. MIME CONTENT-FEATURES HEADER 768 When an intermediary has performed conversion, the 769 intermediary MUST record details of the result of the 770 conversion that was performed. This information is 771 placed in a Content-Features header associated with 772 each MIME body-part having converted content. There is 773 a separate Content-Features header for each MIME body- 774 part. 776 The specification for this header is contained in 777 [FEAT]. 779 8. EXAMPLES 781 8.1. CONPERM Negotiation 783 S: 220 example.com IFAX 784 C: EHLO example.com 785 S: 250- example.com 786 S: 250-DSN 787 S: 250 CONPERM 788 C: MAIL FROM:May@some.example.com CONPERM 789 S: 250 originator ok 790 C: RCPT TO: 791 S: 250- recipient ok 792 C: DATA 793 S: 354 okay, send data 794 C: <> 821 S: 250 message accepted 822 C: QUIT 823 S: 221 goodbye 825 8.2. Example CONNEG Negotiation 827 S: 220 example.com IFAX 828 C: EHLO example.com 829 S: 250- example.com 830 S: 250-DSN 831 S: 250 CONNEG 832 C: MAIL FROM: 833 S: 250 originator ok 834 C: RCPT TO: CONNEG 835 S: 250- recipient ok 836 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 837 S: 250-CONNEG (MRC-mode=0) 838 S: 250-CONNEG (color=Binary) 839 S: 250-CONNEG (|(&(dpi=204) 840 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 841 S: 250-CONNEG (&(dpi=200) 842 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 843 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 844 S: 250-CONNEG (size-x<=2150/254) 845 S: 250-CONNEG (paper-size=[letter,A4]) 846 S: 250 CONNEG (ua-media=stationery) ) 847 C: DATA 848 S: 354 okay, send data 849 C: <> 858 S: 250 message accepted 859 C: QUIT 860 S: 221 goodbye 862 8.3. Content-Previous 864 Content-Previous: 865 Date Tue, 1 Jul 2001 10:52:37 +0200; 866 By relay.example.com; 867 (&(image-file-structure=TIFF-minimal) 868 (MRC-mode=0) 869 (color=Binary) 870 (&(dpi=400) 871 (dpi-xyratio=1) ) 872 (&(image-coding=JBIG) 873 (image-coding-constraint=JBIG-T85) 874 (JBIG-stripe-size=128) ) 875 (size-x=2150/254) 876 (paper-size=A4) 877 (ua-media=stationery) ) 879 9. IANA CONSIDERATIONS 881 This memo is not intended to create any new issues for 882 IANA. 884 10. SECURITY CONSIDERATIONS 886 This service calls for recipients to disclose their 887 capabilities. Mechanisms for determining the 888 requestor's and the respondent's authenticated identity 889 are outside the scope of this specification. It is 890 intended that these mechanisms permit disclosure of 891 information that can safely be public; hence there is 892 no inherent need for security measures. 894 Information that should receive restricted distribution 895 is still able to be disclosed. It is, therefore, the 896 responsibility of the disclosing ESMTP server or 897 disclosing ESMTP client to determine whether additional 898 security measures should be applied to the use of this 899 ESMTP option. 901 11. ACKNOWLEDGEMENTS 903 Graham Klyne and Eric Burger provided extensive, 904 diligent reviews and suggestions. Keith Moore and Giat 905 Hana provided feedback that resulted in improving the 906 specification's integration into established email 907 practise. 909 12. REFERENCES 911 Normative: 913 [CONMSG] Klyne, G., Iwazaki, R., Crocker. D., , 914 "Content Negotiation for Messaging 915 Services based on Email", RFC 3297, July 916 2002. 918 [DISP] Masinter, L., Holtman, K., Mutz, A. and 919 D. Wing, "Media Features for Display, 920 Print, and Fax", RFC 2534, March 1999. 922 [DSN] Moore, K., "SMTP Service Extension for 923 Delivery Status Notifications", RFC 924 1892, January 1996. 926 [ESMTP1] Klensin, J., Freed, N., Rose, M., 927 Stefferud, E. and D. Crocker, "SMTP 928 Service Extensions", RFC 1869, November 929 1995 931 [ESMTP2] Klensin, J., "Simple Mail Transfer 932 Protocol", RFC 2821, April 2001. 934 [FAX] McIntyre, L. and G. Klyne, "Content 935 Feature Schema for Internet Fax", RFC 936 2879, August 2000 938 [FEAT] Klyne, G., "Indicating Media Features 939 for MIME Content", RFC 2912, September 940 2000 942 [IMF] Resnick, P., "Internet Message Format", 943 RFC 2822, April 2001 945 [TAG] Holtman, K., Mutz, A. and T. Hardie, 946 "Media Feature Tag Registration 947 Procedure", RFC 2506, March 1999. 949 [SETS] Klyne, G., "A syntax for describing 950 media feature sets", RFC 2533, March 951 1999. 953 [SYN] Klyne, G. "A Syntax for Describing Media 954 Feature Sets", RFC 25343, March 1999 956 Informative: 958 [CONMSG] Klyne, G., Iwazaki, R., Crocker. D., , 959 "Content Negotiation for Messaging 960 Services based on Email", RFC 3297, July 961 2002. 963 13. AUTHORS' ADDRESSES 965 Kiyoshi Toyoda 966 Network Technology Development Center 967 Panasonic Communications Co., Ltd. 968 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 970 tel: +81-3-5434-7161 971 fax: +81-3-5434-7156 972 toyoda.kiyoshi@jp.panasonic.com 974 Dave Crocker 975 Brandenburg InternetWorking 976 675 Spruce Drive 977 Sunnyvale, CA 94086 USA 979 Tel: +1.408.246.8253 980 dcrocker@brandenburg.com 982 14. FULL COPYRIGHT STATEMENT 984 Copyright (C) The Internet Society (2003). All Rights 985 Reserved. 987 This document and translations of it may be copied and 988 furnished to others, and derivative works that comment 989 on or otherwise explain it or assist in its 990 implementation may be prepared, copied, published and 991 distributed, in whole or in part, without restriction 992 of any kind, provided that the above copyright notice 993 and this paragraph are included on all such copies and 994 derivative works. However, this document itself may 995 not be modified in any way, such as by removing the 996 copyright notice or references to the Internet Society 997 or other Internet organizations, except as needed for 998 the purpose of developing Internet standards in which 999 case the procedures for copyrights defined in the 1000 Internet Standards process must be followed, or as 1001 required to translate it into languages other than 1002 English. 1004 The limited permissions granted above are perpetual and 1005 will not be revoked by the Internet Society or its 1006 successors or assigns. 1008 This document and the information contained herein is 1009 provided on an "AS IS" basis and THE INTERNET SOCIETY 1010 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1011 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1012 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1013 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1014 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1015 PARTICULAR PURPOSE. 1017 APPENDIX A: CONNEG WITH DIRECT SMTP 1019 In some configurations it is possible to have direct 1020 email-based interactions -- where the originator's 1021 system conducts a direct, interactive TCP connection 1022 with the recipient's system. This configuration 1023 permits a use of the content form negotiation service 1024 that conforms to the specification here, but permits 1025 some simplifications. This single SMTP session does 1026 not have the complexity of multiple, relaying sessions 1027 and therefore does not have the requirement for 1028 propagating permissions to intermediaries. 1030 The Originator's system provides user-level functions 1031 for the originator, and it contains the SMTP Client for 1032 sending messages. Hence, the formal step of email 1033 "posting" is a process that is internal or virtual, 1034 within the Originating system. The recipient's service 1035 contains the user-level functions for the recipient, 1036 and it contains the SMTP server, for receiving 1037 messages. Hence the formal steps of email "delivering" 1038 and "receipt" are internal or virtual, within the 1039 Receiving system. 1041 Figure 4: DIRECT CONNEG 1043 Originating system Receiving system 1044 +------------------+ +------------------+ 1045 | +------------+ | | +-----------+ | 1046 | | Originator | | | | Recipient | | 1047 | +------------+ | | +-----------+ | 1048 | ||Posting | | /\Receiving | 1049 | \/ | | || | 1050 | +---------+ | | +--------+ | 1051 | | SMTP |<---|-------|----| SMTP | | 1052 | | Client |----|-------|--->| Server | | 1053 | +---------+ | | +--------+ | 1054 +------------------+ +------------------+ 1056 In this case CONPERM is not needed, because the SMTP 1057 Client is part of the originating system. Therefore it 1058 already has the necessary permission. Similarly, the 1059 SMTP server will be certain to know the recipient's 1060 capabilities, because the server is part of the 1061 receiving system. 1063 Therefore, Direct Mode email transmission can achieve 1064 content capability and form matching by having: 1066 * Originating systems that conform to this specification 1067 the communication process between originator and recipient 1068 is the same as would take place between the last-hop SMTP 1069 Relay and the Delivering SMTP server. 1071 * That is, the Client and Server MUST employ CONNEG and 1072 the Client MUST perform any requisite conversions.