idnits 2.17.1 draft-ietf-fax-esmtp-conneg-08.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 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 983 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. ** 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 177: '... The originator MAY indicate authoriz...' RFC 2119 keyword, line 180: '...rized conversions MUST be specified in...' RFC 2119 keyword, line 197: '...ent capabilities SHOULD be communicate...' RFC 2119 keyword, line 212: '... An intermediary MAY be given CONPERM ...' RFC 2119 keyword, line 213: '...ing a message, and MAY be given CONNEG...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 736 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 (June 2003) is 7614 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: 'KEYWORDS' is mentioned on line 161, but not defined == Missing Reference: 'CFWS' is mentioned on line 616, but not defined == Unused Reference: 'DISP' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'ESMTP1' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'ESMTP2' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'IMF' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'TAG' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'SETS' is defined on line 811, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1892 (ref. 'DSN') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2821 (ref. 'ESMTP2') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (ref. 'IMF') (Obsoleted by RFC 5322) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Toyoda, MGCS 2 Internet Draft D. Crocker, Brandenburg 3 draft-ietf-fax-esmtp-conneg-08.txt June 2003 4 Expires: <12-03> 6 SMTP Service Extensions 7 For Fax Content Negotiation 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full 12 conformance with all provisions of Section 10 of 13 RFC2026. Internet-Drafts are working documents of the 14 Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum 19 of six months and may be updated, replaced, or 20 obsoleted by other documents at any time. It is 21 inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be 29 accessed at 30 http://www.ietf.org/shadow.html. 32 COPYRIGHT NOTICE 34 Copyright (C) The Internet Society (2003). All Rights 35 Reserved. 37 SUMMARY 39 A message originator sometimes sends content in a form 40 the recipient cannot process. Such content needs to be 41 converted to a related form, with the same or with 42 restricted information, such as changing from color to 43 black and white. In a store-and-forward environment, 44 it can be convenient to have this conversion performed 45 by an intermediary. This specification integrates two 46 ESMTP extensions and three MIME content-types, to 47 permit authorized, accountable content form conversion 48 by intermediaries. 50 CONTENTS 52 1. Introduction 53 2. Conventions 54 3. Service Specification 55 3.1. Sending Permission 56 3.2. Returning Capabilities 57 3.3. Next-Hop Non-Support of Service 58 4. Content Conversion Permission SMTP Extension 59 4.1. Content Conversion Permission Service Extension 60 Definition 61 4.2. CONPERM Parameter to Mail-From 62 4.3. Syntax 63 5. Content Negotiation SMTP extension 64 5.1. Content Negotiation Service Extension Definition 65 5.2. CONNEG parameter to RCPT-TO 66 5.3. Syntax 67 6. MIME Content-Convert Header 68 7. MIME Content-Previous Header 69 8. MIME Content-Features Header 70 9. Examples 71 9.1. CONPERM Negotiation 72 9.2. Example CONNEG Negotiation 73 9.3. Content-Previous 74 10. IANA Considerations 75 11. Security Considerations 76 12. Acknowledgements 77 13. References 78 14. Authors' Addresses 79 15. Full Copyright Statement 80 Appendix A: CONNEG with Direct SMTP 82 1. INTRODUCTION 84 A message originator sometimes sends content in a form 85 the recipient cannot process. This specification 86 enables MIME content conversion on behalf of a message 87 originator and a message recipient. It defines a means 88 of matching message content form to the capabilities of 89 a recipient device or system, through an SMTP-based 90 negotiation mechanism. An SMTP client is given 91 permission by an email originator, to request and use 92 information about content capabilities of the target 93 device or system that is serviced by an SMTP server. 94 An SMTP server reports the target's content 95 capabilities back to the SMTP client. The client is 96 then able to convert message content to a form that is 97 supported by the target device or system. 99 This specification provides mechanisms to support such 100 a conversion service, through an ESMTP hop-by-hop 101 service. It uses two SMTP service extensions (CONPERM 102 and CONNEG) and three MIME Content headers (Content- 103 Convert, Content-Converted and Content-Features). 105 An example email relay environment is shown here: 107 +------------+ +-----------+ 108 | Originator | | Recipient | 109 +------------+ +-----------+ 110 ||Posting Delivering/\ 111 \/ || 112 +--------+ +-----------------+ +--------+ 113 | SMTP | | SMTP Relay | | SMTP | 114 | Client |--->| Server | Client |--->| Server | 115 +--------+ +--------+--------+ +--------+ 117 SMTP host permission to perform specified content 118 conversions is communicated by message senders, through 119 the ESMTP CONPERM service extension and MIME Content- 120 Convert headers. Target device or system capabilities 121 are communicated in SMTP sessions through the ESMTP 122 CONNEG service extension. 124 Conversions are performed by the first ESMTP host that 125 can obtain both the sender's permission and the 126 recipient's capabilities. When an SMTP relay or 127 server performs content conversion, it records which 128 specific conversions are made, into Content-Converted 129 and Content-Features MIME headers associated with each, 130 converted MIME body-part. 132 Note: The specification does not provide for 133 sending an MDN back to the originator, when a 134 conversion is performed. If there is no use 135 of CONPERM/CONNEG, then conversions are 136 performed by the recipient. Therefore it is 137 acceptable to ensure that the recipient, rather 138 than the originator, is informed of conversions. 139 This is achieved with Content-Previous and Content- 140 Features. Informing the Originator of conversions 141 could generate a substantial increase in email 142 control traffic. Note that any conversion done by 143 a recipient does not currently result in 144 notification of the originator. 146 When a relay or client is unable to transmit the 147 message to a next-hop that supports CONPERM or to 148 perform appropriate conversion, then it terminates 149 message transmission and returns a [DSN] to the 150 originator. 152 2. CONVENTIONS 154 In examples, "C:" and "S:" indicate lines sent by the 155 client and server respectively. 157 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 158 NOT", and "MAY" in this document are to be interpreted 159 as defined in "Key words for use in RFCs to Indicate 160 Requirement Levels" [KEYWORDS]. 162 3. SERVICE SPECIFICATION 164 This service integrates two ESMTP extensions and three 165 MIME content-types, to permit authorized, accountable 166 content form conversion by intermediaries. 167 Intermediaries are ESMTP hosts (clients and servers) 168 along the transmission path between an originator and a 169 recipient. 171 The MIME headers occur in each MIME body-part to which 172 they apply. That is, each MIME body-part contains its 173 own record of conversion permission and history. 175 Originator Action: 177 The originator MAY indicate authorization for 178 intermediaries to perform conversions, by using the 179 ESMTP CONPERM service extension when posting a new 180 message. Authorized conversions MUST be specified in 181 MIME Content-Convert headers, in each MIME body-part 182 for which conversions are authorized. 184 +------------+ 185 | Originator | 186 +------------+ 187 SMTP || 188 or || CONPERM 189 SUBMIT \/ 190 +--------+ +----------------+ 191 | SMTP | SMTP | SMTP Relay | 192 | Client |----------->| Server | | 193 +--------+ CONPERM +--------+-------+ 195 Recipient Action: 197 Recipient capabilities SHOULD be communicated to 198 intermediaries by the ESMTP CONNEG service extension. 200 +-----------+ 201 | Recipient | 202 +-----------+ 203 Capabilities|| 204 \/ 205 +----------------+ +--------+ 206 | SMTP Relay | CONNEG | SMTP | 207 | | Client |<--------| Server | 208 +-------+--------+ +--------+ 210 Intermediary Actions: 212 An intermediary MAY be given CONPERM direction 213 when receiving a message, and MAY be given CONNEG 214 guidance, before sending the message. CONPERM and 215 CONNEG operate on a per-message basis. Therefore they 216 are issued through the ESMTP MAIL-FROM request. CONNEG 217 response information is provided on a per-recipient 218 basis, through the response to ESMTP RCPT-TO. 220 Conversion MUST be performed by the first CONPERM 221 intermediary that obtains CONNEG recipient capability 222 information. When an intermediary obtains different 223 capability information for different recipients of the 224 same message, it MAY either: 226 * Create a single, converted copy of the content that 227 can be supported by all of the recipients, or 229 * Create multiple converted copies, matching the 230 capabilities of subsets of the recipients. Each 231 version is then sent separately, to an appropriate 232 subset of the recipients. 234 A record of conversions is placed into MIME 235 Content-Previous headers. The current form of the 236 content is provided in MIME Content-Features headers. 238 A special case of differential capabilities occurs 239 when an intermediary receives capability information 240 about some recipients, but no information about others. 241 An example of this scenario can occur when sending a 242 message to some recipients within one's own 243 organization and other recipients located elsewhere. 244 The intermediary might have capability information 245 about the local recipients, but will not have any for 246 distant recipients. This is treated as a variation of 247 the handling required when the permissible conversions 248 are the null set -- that is, no valid conversions are 249 possible for a recipient. 251 Rather than simply failing transmission to the 252 recipients for which there is no capability 253 information, the intermediary MAY choose to send the 254 original content to those recipients, via the CONPERM 255 mechanism. Hence, the handling for such recipients is 256 performed as if no CONNEG transaction took place. 258 Once an intermediary has performed conversion, it 259 MAY terminate use of CONPERM. However some relay 260 environments, such as those re-directing mail to a new 261 target device, will benefit from further conversion. 262 Intermediaries MAY continue to use CONPERM or MAY re- 263 initiate CONPERM use, when they have knowledge about 264 possible variations in target device. 266 3.1. Sending Permission 268 A message originator that permits content conversion by 269 intermediaries MAY use the CONPERM ESMTP service 270 extension and Content-Convert MIME headers to indicate 271 what conversions are permitted by intermediaries. 272 Other mechanisms by which a message originator 273 communicates this permission to the SMTP message 274 transfer service are outside the scope of this 275 specification. 277 When an ESMTP client is authorized to participate in 278 the CONPERM service it MUST interact with the next SMTP 279 hop server, about: 281 * The server's ability to support authorized , 282 conversions through ESMTP CONPERM 284 * The capabilities supported for the target device 285 or system, through ESMTP CONNEG 287 Successful use of CONPERM does not require that 288 conversion take place along the message transfer path. 289 Rather, it requires that conversion take place whenever 290 a next-hop server reports recipient capabilities, 291 through CONNEG, and those capabilities do not include 292 support for the current representation of the content. 294 It is acceptable to have every SMTP server -- including 295 the last-hop server -- support CONPERM, with none 296 offering CONNEG. In this case, the message is 297 delivered to the recipient in its original form. Any 298 possible conversions to be performed are left to the 299 recipient. Hence the recipient is given the original 300 form of the content, along with an explicit list of 301 conversions that the originator deems acceptable. 303 An SMTP server MAY offer ESMTP CONPERM, without being 304 able to perform conversions, if it knows that 305 conversions can be performed by the target device or 306 system. 308 3.2. Returning Capabilities 310 A target recipient device or system communicates its 311 content form capabilities to the SMTP service through a 312 means outside the scope of this specification. When an 313 ESMTP server knows a target's capabilities, it MAY 314 offer the CONNEG ESMTP service extension. 316 When a message is being processed according to this 317 specification, if a next-hop ESMTP server responds that 318 it supports CONNEG, then the SMTP client: 320 (1) MUST request CONNEG information 322 (2) MUST perform the requisite conversions, if 323 possible, before sending the message to the 324 next-hop SMTP server 326 (3) MUST fail message processing, if any conversion 327 for the message fails, and MUST return a failure 328 DSN to the originator 330 (4) MUST add a Content-Previous header and a Content- 331 Features header to each MIME body-part that has 332 been converted. 334 When performing conversions, the Client MUST either: 336 (1) Send a single copy to the next-hop SMTP server, 337 using a best capabilities that are supported to 338 all recipients along that path, or 340 (2) Separate the transfers, to provide the best 341 conversions possible for subsets of the recipients. 343 If the transfers are separated, then the current 344 session MUST be terminated, and new sessions conducted 345 for each subset. 347 The conversions that are performed are determined by 348 the intersection of three lists: 350 * Conversions permitted by the sender 352 * Content capabilities of the target 354 * Conversions that can be performed by the SMTP 355 client host 357 Failed Conversion 359 If the result of this intersection is the null set of 360 representations, for an addressee, then delivery to 361 that addressee MUST be handled as a conversion failure. 363 If the next-hop SMTP host does not indicate that it can 364 represent the target's capabilities through CONNEG, but 365 does respond that it can support CONPERM, then the 366 client SMTP MUST send the existing content, if all 367 other SMTP transmission requirements are satisfied. 369 3.3. Next-Hop Non-Support of Service 371 If a Client is participating in this service, but the 372 next-hop SMTP server does not support CONPERM and does 373 not support CONNEG, then the SMTP client 375 (1) MUST terminate the session to the next-hop SMTP 376 server, without sending the message 378 (2) MUST return a DSN notification to the originator 379 that content negotiation could not be performed. 381 If a Client is participating in this service and the 382 next-hop SMTP server supports CONNEG but provides no 383 capabilities for an individual RCPT-TO addressee, then 384 the SMTP client's processing for that recipient MUST be 385 to: 387 (1) Treat the addressee as a conversion failure, and 389 (2) Separate the addressee from the address list that 390 is processed according to CONNEG, and continue to 391 process the addressee according to CONPERM. 393 4. CONTENT CONVERSION PERMISSION SMTP EXTENSION 395 4.1. Content Conversion Permission Service Extension 396 Definition 398 (1) The name of the SMTP service extension is 400 "Content_Conversion_Permission" 402 (2) The EHLO keyword value associated with this 403 extension is 405 "CONPERM" 407 (3) A parameter using the keyword "CONPERM" is added 408 to the MAIL-FROM command. 410 (4) The server responds with acceptance or rejection of 411 support for CONPERM, for this message. 413 4.2. CONPERM Parameter to Mail-From 415 Parameter: 417 CONPERM 419 Arguments: 421 There are no arguments. Specification of 422 permitted conversions is located in a Content-Convert 423 header for each MIME body-part for which conversion is 424 permitted. 426 Client Action: 428 If the server issued a 250-CONPERM, as part of its 429 EHLO response for the current session and the client is 430 participating in the CONPERM service for this message - 431 - such as by having received the message with a CONPERM 432 requirement -- then the client MUST issue the CONPERM 433 parameter in the MAIL-FROM. If the server does not 434 issue 250-CONPERM, and the client is participating in 435 the CONPERM service for this message, then the client 436 MUST treat the transmission as permanently rejected. 438 Server Action: 440 If the client specifies CONPERM in the MAIL-FROM, 441 but the server does not support the CONPERM parameter, 442 the server MUST reject the MAIL-FROM command with a 504- 443 CONPERM reply. 445 If the client issues the CONPERM parameter in the 446 MAIL-FROM, then the server MUST conform to this 447 specification. Either it MUST relay the message 448 according to CONPERM, or it MUST convert the message 449 according to CONNEG information. 451 4.3. Syntax 453 Content_Conversion_Permission = "CONPERM" 455 5. CONTENT NEGOTIATION SMTP EXTENSION 457 5.1. Content Negotiation Service Extension Definition 459 (1) The name of the SMTP service extension is: 461 "Content_Negotiation" 463 (2) The EHLO keyword value associated with this 464 extension is: 466 "CONNEG" 468 (3) A parameter using the keyword "CONNEG" is added to 469 the RCPT-TO command 471 (4) The server responds with a report of the content 472 capabilities of the device or system that embodies 473 each target RCPT-TO address. 475 5.2. CONNEG parameter to RCPT-TO 477 Parameter: 479 CONNEG 481 Arguments: 483 There are no arguments. 485 Client Action: 487 If message is subject to CONPERM requirements and 488 the server issues a 250-CONNEG, as part of its EHLO 489 response for the current session, the client MUST issue 490 the CONNEG parameter in the RCPT-TO request. If the 491 message is not subject to CONPERM requirements and the 492 server issues a 250-CONNEG, the client MAY issue the 493 CONNEG parameter with RCPT-TO. 495 If the client issues the CONNEG parameter with 496 RCPT-TO, then it MUST honor the capabilities returned 497 in the CONNEG RCPT-TO replies for that message, and it 498 MUST convert the message content, if the current form 499 of the content is not included in the recipient 500 capabilities. 502 The conversions that are performed are determined 503 by the intersection of the: 505 * Conversions permitted by the sender 507 * Content capabilities of the target 509 * Conversions that can be performed by the SMTP 510 client host 512 If the result of this intersection is the null set 513 of representations, then the Client processing depends 514 upon whether the message is subject to CONPERM 515 processing: 517 (1) If the message is subject to CONPERM, the 518 Client MAY continue to transmit the original 519 content, according to CONPERM. 521 (2) Otherwise, the Client MUST treat the conversion 522 as failed. 524 If the result of the intersection is not null, the 525 client SHOULD convert the data to the "highest" level 526 of capability of the server. Determination of the 527 level that is highest is left to the discretion of the 528 host performing the conversion. 530 Each converted MIME body-part, MUST have a Content- 531 Converted header that indicates the previous body-part 532 form and a Content-Features header, indicating the new 533 body-part form. 535 Server Action: 537 If the client specifies CONNEG in the RCPT-TO, but 538 the server does not support the CONNEG parameter, the 539 server MUST reject the RCPT-TO addressees with 504 540 replies. 542 If the server does support the CONNEG parameter 543 and it knows the capabilities of the target device or 544 system, then it MUST provide that information through 545 CONNEG. 547 The response to a CONNEG RCPT-TO request will be 548 multi-line RCPT-TO replies. For successful (250) 549 responses, at least the first line of the response is 550 for RCPT-TO information other than CONNEG. Additional 551 response lines are for CONNEG. In order to avoid 552 problems due to variations in line buffer sizes, the 553 total parametric listing must be provided as a series 554 of lines, each beginning with "250-CONNEG" except for 555 the last line, which is "250 CONNEG". 557 The contents of the capability listing MUST 558 conform to the specifications in [SYN, FAX]. 560 5.3. Syntax 562 Content_Negotiation = "CONNEG" 564 Capability = <> 566 6. MIME CONTENT-CONVERT HEADER 568 Content-Convert is an optional header field that 569 specifies permitted conversions for the associated 570 content. It MAY be used without the other mechanisms 571 defined in this document. If present, this header MUST 572 be carried unmodified and delivered to the recipient. 573 In its absence the content originator has provided no 574 guidance about content conversions, and intermediaries 575 SHOULD NOT perform content conversion. 577 In the extended ABNF notation, the Content-Convert 578 header field is defined as follows: 580 Convert = "Content-convert" ":" 581 permitted 583 Permitted = "ANY" / "NONE" / 584 <> 587 If the permitted conversions are specified as "ANY" 588 then the intermediary may perform any conversions it 589 deems appropriate. If the permitted conversions are 590 specified as "NONE" then the intermediary SHOULD NOT 591 perform any conversions to this MIME body-part, even 592 when the target device or system does not support the 593 original form of the content. 595 7. MIME CONTENT-PREVIOUS HEADER 597 When an intermediary has performed conversion of the 598 associated content, the intermediary MUST record 599 details of the previous representation, from which the 600 conversion was performed. This information is placed 601 in a Content-Previous header that is associated with 602 the MIME body-part having converted content. There is a 603 separate header for each, converted MIME body-part. 605 In the extended ABNF notation, the Content-Previous 606 header field is defined as follows: 608 previous = "Content-Previous" [CFWS] ":" 609 [CFWS] 610 date by type 612 date "Date " [CFWS] date-time [CFWS]";" 613 [CFWS] 615 by "By " [CFWS] domain [CFWS]";" 616 [CFWS] 618 type = <> 621 The Date field specifies the date and time at which the 622 indicated representation was converted into a newer 623 representation. 625 The By field specifies the domain name of the 626 intermediary that performed the conversion. 628 An intermediary MAY choose to derive the Content- 629 Previous header, for a body-part, from an already- 630 existing Content-Features header in that body-part, 631 before that header is replaced with the description of 632 the current representation. 634 8. MIME CONTENT-FEATURES HEADER 636 When an intermediary has performed conversion, the 637 intermediary MUST record details of the result of the 638 conversion that was performed. This information is 639 placed in a Content-Features header associated with 640 each MIME body-part having converted content. There is 641 a separate Content-Features header for each MIME body- 642 part. 644 The specification for this header is contained in 645 [FEAT]. 647 9. EXAMPLES 649 9.1. CONPERM Negotiation 651 S: 220 example.com IFAX 652 C: EHLO example.com 653 S: 250- example.com 654 S: 250-DSN 655 S: 250 CONPERM 656 C: MAIL FROM:May@some.example.com CONPERM 657 S: 250 sender ok 658 C: RCPT TO: 659 S: 250- recipient ok 660 C: DATA 661 S: 354 okay, send data 662 C: <> 690 S: 250 message accepted 691 C: QUIT 692 S: 221 goodbye 694 9.2. Example CONNEG Negotiation 696 S: 220 example.com IFAX 697 C: EHLO example.com 698 S: 250- example.com 699 S: 250-DSN 700 S: 250 CONNEG 701 C: MAIL FROM: 702 S: 250 sender ok 703 C: RCPT TO: CONNEG 704 S: 250- recipient ok 705 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 706 S: 250-CONNEG (MRC-mode=0) 707 S: 250-CONNEG (color=Binary) 708 S: 250-CONNEG (|(&(dpi=204) 709 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 710 S: 250-CONNEG (&(dpi=200) 711 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 712 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 713 S: 250-CONNEG (size-x<=2150/254) 714 S: 250-CONNEG (paper-size=[letter,A4]) 715 S: 250 CONNEG (ua-media=stationery) ) 716 C: DATA 717 S: 354 okay, send data 718 C: <> 728 S: 250 message accepted 729 C: QUIT 730 S: 221 goodbye 732 9.3. Content-Previous 734 Content-Previous: 735 Date Tue, 1 Jul 2001 10:52:37 +0200; 736 By relay.example.com; 737 (&(image-file-structure=TIFF-minimal) 738 (MRC-mode=0) 739 (color=Binary) 740 (&(dpi=400) 741 (dpi-xyratio=1) ) 742 (&(image-coding=JBIG) 743 (image-coding-constraint=JBIG-T85) 744 (JBIG-stripe-size=128) ) 745 (size-x=2150/254) 746 (paper-size=A4) 747 (ua-media=stationery) ) 749 10. IANA CONSIDERATIONS 751 This memo is not intended to create any new issues for 752 IANA. 754 11. SECURITY CONSIDERATIONS 756 This service calls for recipients to disclose their 757 capabilities. Mechanisms for determining the 758 requestor's and the respondent's authenticated 759 identity are outside the scope of this specification. 760 It is intended that these mechanisms permit disclosure 761 of information that can safely be public; hence there 762 is no inherent need for security measures. 764 However there is nothing to prevent disclosure of 765 sensitive information that should receive restricted 766 distribution. It is, therefore, the responsibility of 767 the disclosing ESMTP server or disclosing ESMTP client 768 to determine whether additional security measures 769 should be applied to the use of this ESMTP option. 771 12. ACKNOWLEDGEMENTS 773 Graham Klyne and Eric Burger provided extensive, 774 diligent reviews and suggestions. 776 13. REFERENCES 778 Normative: 780 [DISP] Masinter, L., Holtman, K., Mutz, A. and 781 D. Wing, "Media Features for Display, 782 Print, and Fax", RFC 2534, March 1999. 784 [DSN] Moore, K., "SMTP Service Extension for 785 Delivery Status Notifications", RFC 786 1892, January 1996. 788 [ESMTP1] Klensin, J., Freed, N., Rose, M., 789 Stefferud, E. and D. Crocker, "SMTP 790 Service Extensions", RFC 1869, November 791 1995 793 [ESMTP2] Klensin, J., "Simple Mail Transfer 794 Protocol", RFC 2821, April 2001. 796 [FAX] McIntyre, L. and G. Klyne, "Content 797 Feature Schema for Internet Fax", RFC 798 2879, August 2000 800 [FEAT] Klyne, G., "Indicating Media Features 801 for MIME Content", RFC 2912, September 802 2000 804 [IMF] Resnick, P., "Internet Message Format", 805 RFC 2822, April 2001 807 [TAG] Holtman, K., Mutz, A. and T. Hardie, 808 "Media Feature Tag Registration 809 Procedure", RFC 2506, March 1999. 811 [SETS] Klyne, G., "A syntax for describing 812 media feature sets", RFC 2533, March 813 1999. 815 [SYN] Klyne, G. "A Syntax for Describing Media 816 Feature Sets", RFC 25343, March 1999 818 14. AUTHORS' ADDRESSES 820 Kiyoshi Toyoda 821 Network Technology Development Center 822 Panasonic Communications Co., Ltd. 823 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 825 tel: +81-3-5434-7161 826 fax: +81-3-5434-7156 827 toyoda.kiyoshi@jp.panasonic.com 829 Dave Crocker 830 Brandenburg InternetWorking 831 675 Spruce Drive 832 Sunnyvale, CA 94086 USA 834 Tel: +1.408.246.8253 835 dcrocker@brandenburg.com 837 15. FULL COPYRIGHT STATEMENT 839 Copyright (C) The Internet Society (2003). All Rights 840 Reserved. 842 This document and translations of it may be copied and 843 furnished to others, and derivative works that comment 844 on or otherwise explain it or assist in its 845 implementation may be prepared, copied, published and 846 distributed, in whole or in part, without restriction 847 of any kind, provided that the above copyright notice 848 and this paragraph are included on all such copies and 849 derivative works. However, this document itself may 850 not be modified in any way, such as by removing the 851 copyright notice or references to the Internet Society 852 or other Internet organizations, except as needed for 853 the purpose of developing Internet standards in which 854 case the procedures for copyrights defined in the 855 Internet Standards process must be followed, or as 856 required to translate it into languages other than 857 English. 859 The limited permissions granted above are perpetual and 860 will not be revoked by the Internet Society or its 861 successors or assigns. 863 This document and the information contained herein is 864 provided on an "AS IS" basis and THE INTERNET SOCIETY 865 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 866 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 867 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 868 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 870 PARTICULAR PURPOSE. 872 APPENDIX A: CONNEG WITH DIRECT SMTP 874 In some configurations it is possible to have direct 875 email-based interactions -- where the originator's 876 system conducts a direct, interactive TCP connection 877 with the recipient's system. This configuration 878 permits a use of the content form negotiation service 879 that conforms to the specification here, but permits 880 some simplifications. This single SMTP session does 881 not have the complexity of multiple, relaying sessions 882 and therefore does not have the requirement for 883 propagating permissions to intermediaries. 885 The Originator's system provides user-level functions 886 for the originator, and it contains the SMTP Client for 887 sending messages. Hence, the formal step of email 888 "posting" is a process that is internal or virtual, 889 within the Originating system. The recipient's service 890 contains the user-level functions for the recipient, 891 and it contains the SMTP server, for receiving 892 messages. Hence the formal steps of email "delivering" 893 and "receipt" are internal or virtual, within the 894 Receiving system. 896 The figure below shows these relationships: 898 Originating system Receiving system 899 +------------------+ +------------------+ 900 | +------------+ | | +-----------+ | 901 | | Originator | | | | Recipient | | 902 | +------------+ | | +-----------+ | 903 | ||Posting | | /\Receiving | 904 | \/ | | || | 905 | +---------+ | | +--------+ | 906 | | SMTP |<---|-------|----| SMTP | | 907 | | Client |----|-------|--->| Server | | 908 | +---------+ | | +--------+ | 909 +------------------+ +------------------+ 911 In this case CONPERM is not needed, because the SMTP 912 Client is part of the originating system. Therefore it 913 already has the necessary permission. Similarly, the 914 SMTP server will be certain to know the recipient's 915 capabilities, because the server is part of the 916 receiving system. 918 Therefore, Direct Mode email transmission can achieve 919 content capability and form matching by having: 921 * Originating systems that conform to this 922 specification the communication process between 923 originator and recipient is the same as would 924 take place between the last-hop SMTP Relay and 925 the Delivering SMTP server. 927 * That is, the Client and Server MUST employ CONNEG 928 and the Client MUST perform any requisite 929 conversions.