idnits 2.17.1 draft-ietf-fax-esmtp-conneg-06.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. == There are 12 instances of lines with non-ascii characters in the document. == 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 970 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 an Authors' Addresses 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 737 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 (Feb 2003) is 7713 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? 'DSN' on line 785 looks like a reference -- Missing reference section? 'KEYWORDS' on line 161 looks like a reference -- Missing reference section? 'SYN' on line 816 looks like a reference -- Missing reference section? 'FAX' on line 797 looks like a reference -- Missing reference section? 'CFWS' on line 620 looks like a reference -- Missing reference section? 'FEAT' on line 801 looks like a reference -- Missing reference section? 'DISP' on line 781 looks like a reference -- Missing reference section? 'ESMTP1' on line 789 looks like a reference -- Missing reference section? 'ESMTP2' on line 794 looks like a reference -- Missing reference section? 'IMF' on line 805 looks like a reference -- Missing reference section? 'TAG' on line 808 looks like a reference -- Missing reference section? 'SETS' on line 812 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 14 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-06.txt Feb 2003 4 Expires: <8-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 [[Editor�s note: The specification does not 133 provide for sending an MDN back to the originator, 134 when a conversion is performed. If there is no 135 use 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. /d]] 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 can 227 be supported by all of the recipients, or 229 * Create multiple converted copies, matching the 230 capabilities of subsets of the recipients. Each version is 231 then sent separately, to an appropriate subset of the 232 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 re-direction to an alternate 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 [[Editor's Note: An SMTP host that has performed 267 a conversion might continue use of CONPERM or it 268 might not. It is not clear to me what the 269 specification should say about this. The above 270 paragraph offers one view. 272 It seems reasonable to permit a sequence of 273 conversion events. If we do that, how do we 274 specify that permission here? /d]] 276 3.1. Sending Permission 278 A message originator that permits content conversion by 279 intermediaries MAY use the CONPERM ESMTP service 280 extension and Content-Convert MIME headers to indicate 281 what conversions are permitted by intermediaries. 282 Other mechanisms by which a message originator 283 communicates this permission to the SMTP message 284 transfer service are outside the scope of this 285 specification. 287 When an ESMTP client is authorized to participate in 288 the CONPERM service it MUST interact with the next SMTP 289 hop server, about: 291 * The server�s ability to support authorized conversions, 292 through ESMTP CONPERM 294 * The capabilities supported for the target device or 295 system, through ESMTP CONNEG 297 Successful use of CONPERM does not require that 298 conversion take place along the message transfer path. 299 Rather, it requires that conversion take place whenever 300 a next-hop server reports recipient capabilities, 301 through CONNEG, and those capabilities do not include 302 support for the current representation of the content. 304 It is acceptable to have every SMTP server -- including 305 the last-hop server -- support CONPERM, with none 306 offering CONNEG. In this case, the message is 307 delivered to the recipient in its original form. Any 308 possible conversions to be performed are left to the 309 recipient. Hence the recipient is given the original 310 form of the content, along with an explicit list of 311 conversions that the originator deems acceptable. 313 An SMTP server MAY offer ESMTP CONPERM, without being 314 able to perform conversions, if it knows that 315 conversions can be performed by the target device or 316 system. 318 3.2. Returning Capabilities 320 A target recipient device or system communicates its 321 content form capabilities to the SMTP service through a 322 means outside the scope of this specification. When an 323 ESMTP server knows a target�s capabilities, it MAY 324 offer the CONNEG ESMTP service extension. 326 When a message is being processed according to this 327 specification, if a next-hop ESMTP server responds that 328 it supports CONNEG, then the SMTP client: 330 (1) MUST request CONNEG information 332 (2) MUST perform the requisite conversions before sending 333 the message to the next-hop SMTP server 335 (3) MUST fail message processing, if any conversion for the 336 message fails and MUST return a failure DSN to the 337 originator 339 (4) MUST add a Content-Previous header and a Content- 340 Features header to each MIME body-part that has been 341 converted. 343 When performing conversions, the Client MUST either: 345 (1) Send a single copy to the next-hop SMTP server, using a 346 best capabilities that are supported to all recipients along 347 that path, or 349 (2) Separate the transfers, to provide the best conversions 350 possible for subsets of the recipients. 352 If the transfers are separated, then the current 353 session MUST be terminated, and new sessions conducted 354 for each subset. 356 The conversions that are performed are determined by 357 the intersection of three lists: 359 * Conversions permitted by the sender 360 * Content capabilities of the target 361 * Conversions that can be performed by the SMTP client 362 host 364 Failed Conversion 366 If the result of this intersection is the null set of 367 representations, for an addressee, then delivery to 368 that addressee MUST be handled as a conversion failure. 370 If the next-hop SMTP host does not indicate that it can 371 represent the target�s capabilities through CONNEG, but 372 does respond that it can support CONPERM, then the 373 client SMTP MUST send the existing content, if all 374 other SMTP transmission requirements are satisfied. 376 3.3. Next-Hop Non-Support of Service 378 If a Client is participating in this service, but the 379 next-hop SMTP server does not support CONPERM and does 380 not support CONNEG, then the SMTP client 382 (1) MUST terminate the session to the next-hop SMTP server, 383 without sending the message 385 (2) MUST return a DSN notification to the originator that 386 content negotiation could not be performed. 388 If a Client is participating in this service and the 389 next-hop SMTP server supports CONNEG but provides no 390 capabilities for an individual RCPT-TO addressee, then 391 the SMTP client�s processing for that recipient MUST be 392 either to: 394 (1) Treat the addressee as a conversion failure, or 396 (2) Separate the addressee from the address list that is 397 processed according to CONNEG, and continue to process the 398 addressee according to CONPERM. 400 4. CONTENT CONVERSION PERMISSION SMTP EXTENSION 402 4.1. Content Conversion Permission Service Extension 403 Definition 405 (1) The name of the SMTP service extension is 407 "Content_Conversion_Permission" 409 (2) The EHLO keyword value associated with this extension 410 is 412 "CONPERM" 414 (3) A parameter using the keyword "CONPERM" is added to the 415 MAIL-FROM command. 417 (4) The server responds with acceptance or rejection of 418 support for CONPERM, for this message. 420 4.2. CONPERM Parameter to Mail-From 422 Parameter: 424 CONPERM 426 Arguments: 428 There are no arguments. Specification of 429 permitted conversions is located in a Content-Convert 430 header for each MIME body-part for which conversion is 431 permitted. 433 Client Action: 435 If the server issued a 250-CONPERM, as part of its 436 EHLO response for the current session and the client is 437 participating in the CONPERM service for this message - 438 - such as by having received the message with a CONPERM 439 requirement -- then the client MUST issue the CONPERM 440 parameter in the MAIL-FROM. If the server does not 441 issue 250-CONPERM, and the client is participating in 442 the CONPERM service for this message, then the client 443 MUST treat the transmission as permanently rejected. 445 Server Action: 447 If the client specifies CONPERM in the MAIL-FROM, 448 but the server does not support the CONPERM parameter, 449 the server MUST reject the MAIL-FROM command with a 504- 450 CONPERM reply. 452 If the client issues the CONPERM parameter in the 453 MAIL-FROM, then the server MUST conform to this 454 specification. Either it MUST relay the message 455 according to CONPERM, or it MUST convert the message 456 according to CONNEG information. 458 4.3. Syntax 460 Content_Conversion_Permission = "CONPERM" 462 5. CONTENT NEGOTIATION SMTP EXTENSION 464 5.1. Content Negotiation Service Extension Definition 466 (1) The name of the SMTP service extension is: 468 "Content_Negotiation" 470 (2) The EHLO keyword value associated with this extension 471 is: 473 "CONNEG" 475 (3) A parameter using the keyword "CONNEG" is added to the 476 RCPT-TO command 478 (4) The server responds with a report of the content 479 capabilities of the device or system that embodies each 480 target RCPT-TO address. 482 5.2. CONNEG parameter to RCPT-TO 484 Parameter: 486 CONNEG 488 Arguments: 490 There are no arguments. 492 Client Action: 494 If message is subject to CONPERM requirements and 495 the server issues a 250-CONNEG, as part of its EHLO 496 response for the current session, the client MUST issue 497 the CONNEG parameter in the RCPT-TO request. If the 498 message is not subject to CONPERM requirements and the 499 server issues a 250-CONNEG, the client MAY issue the 500 CONNEG parameter with RCPT-TO. 502 If the client issues the CONNEG parameter with 503 RCPT-TO, then it MUST honor the capabilities returned 504 in the CONNEG RCPT-TO replies for that message, and it 505 MUST convert the message content, if the current form 506 of the content is not included in the recipient 507 capabilities. 509 The conversions that are performed are determined 510 by the intersection of the: 512 * Conversions permitted by the sender 513 * Content capabilities of the target 514 * Conversions that can be performed by the SMTP client 515 host 517 If the result of this intersection is the null set 518 of representations, then the Client processing depends 519 upon whether the message is subject to CONPERM 520 processing: 522 (1) If the message is subject to CONPERM, the Client MAY 523 continue to transmit the original content, according to 524 CONPERM. 526 (2) Otherwise, the Client MUST treat the conversion as 527 failed. 529 If the result of the intersection is not null, the 530 client SHOULD convert the data to the "highest" level 531 of capability of the server. Determination of the 532 level that is highest is left to the discretion of the 533 host performing the conversion. 535 Each converted MIME body-part, MUST have a Content- 536 Converted header that indicates the previous body-part 537 form and a Content-Features header, indicating the new 538 body-part form. 540 Server Action: 542 If the client specifies CONNEG in the RCPT-TO, but 543 the server does not support the CONNEG parameter, the 544 server MUST reject the RCPT-TO addressees with 504 545 replies. 547 If the server does support the CONNEG parameter 548 and it knows the capabilities of the target device or 549 system, then it MUST provide that information through 550 CONNEG. 552 The response to a CONNEG RCPT-TO request will be 553 multi-line RCPT-TO replies. For successful (250) 554 responses, at least the first line of the response is 555 for RCPT-TO information other than CONNEG. Additional 556 response lines are for CONNEG. In order to avoid 557 problems due to variations in line buffer sizes, the 558 total parametric listing must be provided as a series 559 of lines, each beginning with "250-CONNEG" except for 560 the last line, which is "250 CONNEG". 562 The contents of the capability listing MUST 563 conform to the specifications in [SYN, FAX]. 565 5.3. Syntax 567 Content_Negotiation = "CONNEG" 568 Capability = <> 570 6. MIME CONTENT-CONVERT HEADER 572 Content-Convert is an optional header field that 573 specifies permitted conversions for the associated 574 content. It MAY be used without the other mechanisms 575 defined in this document. If present, this header MUST 576 be carried unmodified and delivered to the recipient. 577 In its absence the content originator has provided no 578 guidance about content conversions, and intermediaries 579 SHOULD NOT perform content conversion. 581 In the extended ABNF notation, the Content-Convert 582 header field is defined as follows: 584 Convert = "Content-convert" ":" 585 permitted 587 Permitted = "ANY" / "NONE" / 588 <> 591 If the permitted conversions are specified as "ANY" 592 then the intermediary may perform any conversions it 593 deems appropriate. If the permitted conversions are 594 specified as "NONE" then the intermediary SHOULD NOT 595 perform any conversions to this MIME body-part, even 596 when the target device or system does not support the 597 original form of the content. 599 7. MIME CONTENT-PREVIOUS HEADER 601 When an intermediary has performed conversion of the 602 associated content, the intermediary MUST record 603 details of the previous representation, from which the 604 conversion was performed. This information is placed 605 in a Content-Previous header that is associated with 606 the MIME body-part having converted content. There is a 607 separate header for each, converted MIME body-part. 609 In the extended ABNF notation, the Content-Previous 610 header field is defined as follows: 612 previous = "Content-Previous" [CFWS] ":" 613 [CFWS] 614 date by type 616 date "Date " [CFWS] date-time [CFWS]";" 617 [CFWS] 619 by "By " [CFWS] domain [CFWS]";" 620 [CFWS] 622 type = <> 625 The Date field specifies the date and time at which the 626 indicated representation was converted into a newer 627 representation. 629 The By field specifies the domain name of the 630 intermediary that performed the conversion. 632 An intermediary MAY choose to derive the Content- 633 Previous header, for a body-part, from an already- 634 existing Content-Features header in that body-part, 635 before that header is replaced with the description of 636 the current representation. 638 8. MIME CONTENT-FEATURES HEADER 640 When an intermediary has performed conversion, the 641 intermediary MUST record details of the result of the 642 conversion that was performed. This information is 643 placed in a Content-Features header associated with 644 each MIME body-part having converted content. There is 645 a separate Content-Features header for each MIME body- 646 part. 648 The specification for this header is contained in 649 [FEAT]. 651 9. EXAMPLES 653 9.1. CONPERM Negotiation 655 S: 220 example.com IFAX 656 C: EHLO example.com 657 S: 250- example.com 658 S: 250-DSN 659 S: 250 CONPERM 660 C: MAIL FROM:May@some.example.com CONPERM 661 S: 250 sender ok 662 C: RCPT TO: 663 S: 250- recipient ok 664 C: DATA 665 S: 354 okay, send data 666 C: <> 693 S: 250 message accepted 694 C: QUIT 695 S: 221 goodbye 697 9.2. Example CONNEG Negotiation 699 S: 220 example.com IFAX 700 C: EHLO example.com 701 S: 250- example.com 702 S: 250-DSN 703 S: 250 CONNEG 704 C: MAIL FROM: 705 S: 250 sender ok 706 C: RCPT TO: CONNEG 707 S: 250- recipient ok 708 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 709 S: 250-CONNEG (MRC-mode=0) 710 S: 250-CONNEG (color=Binary) 711 S: 250-CONNEG (|(&(dpi=204) 712 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 713 S: 250-CONNEG (&(dpi=200) 714 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 715 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 716 S: 250-CONNEG (size-x<=2150/254) 717 S: 250-CONNEG (paper-size=[letter,A4]) 718 S: 250 CONNEG (ua-media=stationery) ) 719 C: DATA 720 S: 354 okay, send data 721 C: <> 730 S: 250 message accepted 731 C: QUIT 732 S: 221 goodbye 734 9.3. Content-Previous 735 Content-converted: 736 Date Tue, 1 Jul 2001 10:52:37 +0200; 737 By relay.example.com; 738 (&(image-file-structure=TIFF-minimal) 739 (MRC-mode=0) 740 (color=Binary) 741 (&(dpi=400) 742 (dpi-xyratio=1) ) 743 (&(image-coding=JBIG) 744 (image-coding-constraint=JBIG-T85) 745 (JBIG-stripe-size=128) ) 746 (size-x=2150/254) 747 (paper-size=A4) 748 (ua-media=stationery) ) 750 10. IANA CONSIDERATIONS 752 This memo is not intended to create any new issues for 753 IANA. 755 11. SECURITY CONSIDERATIONS 757 This service calls for participants to disclose their 758 capabilities. Mechanisms, for determining the 759 requestor�s and the respondent�s authenticated 760 identity, are outside the scope of this specification. 761 It is intended that these mechanisms permit disclosure 762 of information that can safely be public; hence there 763 is no inherent need for security measures. 765 However there is nothing to prevent disclosure of 766 sensitive information that should receive restricted 767 distribution. It is, therefore, the responsibility of 768 the disclosing ESMTP server or disclosing ESMTP client 769 to determine whether additional security measures 770 should be applied to the use of this ESMTP option. 772 12. ACKNOWLEDGEMENTS 774 Graham Klyne and Eric Burger provided extensive, 775 diligent reviews and suggestions. 777 13. REFERENCES 779 Normative: 781 [DISP] Masinter, L., Holtman, K., Mutz, A. and 782 D. Wing, "Media Features for Display, 783 Print, and Fax", RFC 2534, March 1999. 785 [DSN] Moore, K., "SMTP Service Extension for 786 Delivery Status Notifications", RFC 787 1892, January 1996. 789 [ESMTP1] Klensin, J., Freed, N., Rose, M., 790 Stefferud, E. and D. Crocker, "SMTP 791 Service Extensions", RFC 1869, November 792 1995 794 [ESMTP2] Klensin, J., "Simple Mail Transfer 795 Protocol", RFC 2821, April 2001. 797 [FAX] McIntyre, L. and G. Klyne, "Content 798 Feature Schema for Internet Fax", RFC 799 2879, August 2000 801 [FEAT] Klyne, G., "Indicating Media Features 802 for MIME Content", RFC 2912, September 803 2000 805 [IMF] Resnick, P., "Internet Message Format", 806 RFC 2822, April 2001 808 [TAG] Holtman, K., Mutz, A. and T. Hardie, 809 "Media Feature Tag Registration 810 Procedure", RFC 2506, March 1999. 812 [SETS] Klyne, G., "A syntax for describing 813 media feature sets", RFC 2533, March 814 1999. 816 [SYN] Klyne, G. "A Syntax for Describing Media 817 Feature Sets", RFC 25343, March 1999 819 14. AUTHORS� ADDRESSES 821 Kiyoshi Toyoda 822 Network Technology Development Center 823 Panasonic Communications Co., Ltd. 824 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 826 tel: +81-3-5434-7161 827 fax: +81-3-5434-7156 828 toyoda.kiyoshi@jp.panasonic.com 830 Dave Crocker 831 Brandenburg InternetWorking 832 675 Spruce Drive 833 Sunnyvale, CA 94086 USA 835 Tel: +1.408.246.8253 836 dcrocker@brandenburg.com 838 15. FULL COPYRIGHT STATEMENT 840 Copyright (C) The Internet Society (2003). All Rights 841 Reserved. 843 This document and translations of it may be copied and 844 furnished to others, and derivative works that comment 845 on or otherwise explain it or assist in its 846 implementation may be prepared, copied, published and 847 distributed, in whole or in part, without restriction 848 of any kind, provided that the above copyright notice 849 and this paragraph are included on all such copies and 850 derivative works. However, this document itself may 851 not be modified in any way, such as by removing the 852 copyright notice or references to the Internet Society 853 or other Internet organizations, except as needed for 854 the purpose of developing Internet standards in which 855 case the procedures for copyrights defined in the 856 Internet Standards process must be followed, or as 857 required to translate it into languages other than 858 English. 860 The limited permissions granted above are perpetual and 861 will not be revoked by the Internet Society or its 862 successors or assigns. 864 This document and the information contained herein is 865 provided on an "AS IS" basis and THE INTERNET SOCIETY 866 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 867 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 868 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 869 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 871 PARTICULAR PURPOSE. 873 APPENDIX A: CONNEG WITH DIRECT SMTP 875 In some configurations it is possible to have direct 876 email-based interactions -- where the originator's 877 system conducts a direct, interactive TCP connection 878 with the recipient's system. This configuration 879 permits a use of the content form negotiation service 880 that conforms to the specification here, but permits 881 some simplifications. This single SMTP session does 882 not have the complexity of multiple, relaying sessions 883 and therefore does not have the requirement for 884 propagating permissions to intermediaries. 886 The Originator's system provides user-level functions 887 for the originator, and it contains the SMTP Client for 888 sending messages. Hence, the formal step of email 889 "posting" is a process that is internal or virtual, 890 within the Originating system. The recipient's service 891 contains the user-level functions for the recipient, 892 and it contains the SMTP server, for receiving 893 messages. Hence the formal steps of email "delivering" 894 and "receipt" are internal or virtual, within the 895 Receiving system. 897 The figure below shows these relationships: 899 Originating system Receiving system 900 +------------------+ +------------------+ 901 | +------------+ | | +-----------+ | 902 | | Originator | | | | Recipient | | 903 | +------------+ | | +-----------+ | 904 | ||Posting | | /\Receiving | 905 | \/ | | || | 906 | +---------+ | | +--------+ | 907 | | SMTP |<---|-------|----| SMTP | | 908 | | Client |----|-------|--->| Server | | 909 | +---------+ | | +--------+ | 910 +------------------+ +------------------+ 912 In this case CONPERM is not needed, because the SMTP 913 Client is part of the originating system. Therefore it 914 already has the necessary permission. Similarly, the 915 SMTP server will be certain to know the recipient's 916 capabilities, because the server is part of the 917 receiving system. 919 Therefore, Direct Mode email transmission can achieve 920 content capability and form matching by having: 922 * Originating systems that conform to this specification 923 the communication process between originator and recipient 924 is the same as would take place between the last-hop SMTP 925 Relay and the Delivering SMTP server. 927 * That is, the Client and Server MUST employ CONNEG and 928 the Client MUST perform any requisite conversions.