idnits 2.17.1 draft-ietf-fax-esmtp-conneg-04.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 868 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** 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 204: '...mation, the intermediary MAY choose to...' RFC 2119 keyword, line 222: '... intermediaries MAY use the CONPERM E...' RFC 2119 keyword, line 231: '...NPERM service it MUST interact with th...' RFC 2119 keyword, line 254: '...get�s capabilities, it MAY offer the...' RFC 2119 keyword, line 261: '... (1) MUST request CONNEG informat...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 279 has weird spacing: '... If the t...' == Line 640 has weird spacing: '... By relay...' -- 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 7741 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 697 looks like a reference -- Missing reference section? 'KEYWORDS' on line 158 looks like a reference -- Missing reference section? 'FAX' on line 709 looks like a reference -- Missing reference section? 'CFWS' on line 541 looks like a reference -- Missing reference section? 'DISPLAY' on line 693 looks like a reference -- Missing reference section? 'ESMTP1' on line 701 looks like a reference -- Missing reference section? 'ESMTP2' on line 706 looks like a reference -- Missing reference section? 'IMF' on line 713 looks like a reference -- Missing reference section? 'TAG' on line 716 looks like a reference -- Missing reference section? 'SETS' on line 720 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Toyoda, MGCS 3 Internet Draft D. Crocker, Brandenburg 4 draft-ietf-fax-esmtp-conneg-04.txt Feb 2003 5 Expires: <7-03> 7 SMTP Service Extensions 8 for Fax Content Negotiation 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, or 21 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 wishes to send content 41 that is in a form the recipient cannot process. In 42 order for the recipient to process the content, the 43 content must be converted to a related form, with the 44 same or with restricted information, such as changing 45 from color to black and white. In a store-and-forward 46 environment, it can be convenient to have this 47 conversion performed by an intermediary. 49 CONTENTS 51 1. Introduction 52 2. Conventions 53 3. Service Specification 54 3.1. Sending Permission 55 3.2. Returning Capabilities 56 3.3. Next-Hop Non-Support of Service 57 4. Content Conversion Permission SMTP Extension 58 4.1. Content Conversion Permission service extension 59 definition 60 4.2. CONPERM parameter to Mail-From 61 4.3. Syntax 62 5. Content Negotiation SMTP extension 63 5.1. Content Negotiation service extension definition 64 5.2. CONNEG parameter to RCPT-TO 65 5.3. Syntax 66 6. MIME CONTENT-CONVERT Header 67 7. MIME Content-Converted Header 68 8. EXAMPLES 69 8.1. CONPERM Negotiation 70 8.2. Example CONNEG Negotiation 71 8.3. Content-Converted 72 9. IANA Considerations 73 10. Security Considerations 74 11. Acknowledgements 75 12. References (Normative) 76 13. Authors� Addresses 77 14. Full Copyright Statement 78 Appendix A: CONNEG with Direct SMTP 80 1. INTRODUCTION 82 A message originator sometimes wishes to send content 83 that is in a form the recipient cannot process. This 84 specification enables MIME content conversion on behalf 85 of a message originator and a message recipient. It 86 defines a means of matching message content form to the 87 capabilities of a recipient device or system, through 88 an SMTP-based negotiation mechanism. An SMTP client is 89 given permission by an email originator to request and 90 use information about content capabilities of the 91 target device or system that is serviced by an SMTP 92 server. An SMTP server reports the target�s content 93 capabilities back to the SMTP client, and the client is 94 then able to convert message content to a form that is 95 supported by the target device or system. 97 This specification provides mechanisms to support such 98 a conversion service, through an ESMTP hop-by-hop 99 service. It uses two SMTP service extensions: CONPERM 100 and CONNEG, and two MIME Content headers: Content- 101 Conversion and Content-Converted 103 An example email relay environment is shown here: 105 +------------+ +-----------+ 106 | Originator | | Recipient | 107 +------------+ +-----------+ 108 ||Posting Delivering/\ 109 \/ || 110 +--------+ +-----------------+ +--------+ 111 | SMTP | | SMTP Relay | | SMTP | 112 | Client |--->| Server | Client |--->| Server | 113 +--------+ +--------+--------+ +--------+ 115 SMTP host permission to perform specified content 116 conversions is communicated by message senders, through 117 the ESMTP CONPERM service extension and MIME Content- 118 Conversion headers. Target device or system 119 capabilities are communicated in SMTP sessions through 120 the ESMTP CONNEG service extension. 122 Conversions are performed by the first ESMTP host that 123 can obtain both the sender�s permission and the 124 recipient�s capabilities. When an SMTP relay or 125 server performs content conversion, it records which 126 specific conversions are made, into Content-Converted 127 MIME headers associated with each, converted MIME body- 128 part. 130 [[Editor�s note: The specification does not 131 provide for sending an MDN back to the originator, 132 when a conversion is performed. Without 133 CONPERM/CONNEG, conversions are performed by the 134 recipient. Therefore it is acceptable to ensure 135 that the recipient, rather than the originator, is 136 informed of conversions. This is achieved with 137 Content-Converted. Informing the Originator of 138 conversions could generate a substantial increase 139 in email control traffic. Note that conversion by 140 a recipient does not currently result in 141 notification of the originator.]] 143 When a relay or client is unable to transmit the 144 message to a next-hop that supports CONPERM or to 145 perform appropriate conversion, then it terminates 146 message transmission and returns a [DSN] to the 147 originator. 149 2. CONVENTIONS 151 In examples, "C:" and "S:" indicate lines sent by the 152 client and server respectively. 154 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 155 NOT", and "MAY" in this document are to be interpreted 156 as defined in "Key words for use in RFCs to Indicate 157 Requirement Levels" [KEYWORDS]. 159 3. SERVICE SPECIFICATION 161 This service integrates two ESMTP extensions and two 162 MIME content-types, to permit authorized, accountable 163 content form conversion by intermediaries. 164 Intermediaries are ESMTP hosts (clients and servers) 165 along the transmission path between an originator and a 166 recipient. 168 Authorization is provided to intermediaries by the 169 originator, through ESMTP CONPERM. Authorized 170 conversions are specified in MIME Content-Convert 171 headers. Recipient capabilities are communicated to 172 intermediaries by ESMTP CONNEG, and a record of 173 conversions is placed into MIME Content-Converted 174 headers. 176 CONPERM and CONNEG operate on a per-message basis. 177 Therefore they are issued through the ESMTP MAIL-FROM 178 and RCPT-TO request. CONNEG response information is 179 provided on a per-recipient basis, through the response 180 to ESMTP RCPT-TO. 182 Conversion is performed by the first intermediary that 183 obtains recipient capability information. When an 184 intermediary obtains different capability information 185 for different recipients of the same message, it has 186 the choice of creating a single, converted copy of the 187 content that can be supported by all of the recipients, 188 or it can create multiple converted copies, each 189 version sent separately, and matching a subset of the 190 recipients. 192 A special case of differential capabilities occurs when 193 an intermediary receives capability information about 194 some recipients, but no information about others. An 195 example of this scenario can occur when sending a 196 message to some recipients within one�s own 197 organization and other recipients located elsewhere. 198 The intermediary might have capability information 199 about the local recipients, but will not have any for 200 distant recipients. This is treated as a variation of 201 the handling required when the permissible conversions 202 are the null set. However, rather than simply failing 203 transmission to the recipients for which there is no 204 capability information, the intermediary MAY choose to 205 send the original content to those recipients, via the 206 CONPERM mechanism. 208 3.1. Sending Permission 210 +------------+ 211 | Originator | 212 +------------+ 213 SMTP || 214 or || CONPERM 215 SUBMIT \/ 216 +--------+ +----------------+ 217 | SMTP | SMTP | SMTP Relay | 218 | Client |----------->| Server | | 219 +--------+ CONPERM +--------+-------+ 221 A message originator that permits content conversion by 222 intermediaries MAY use the CONPERM ESMTP service 223 extension and Content-Conversion MIME headers to 224 indicate what conversions are permitted by 225 intermediaries. Other mechanisms by which a message 226 originator communicates this permission to the SMTP 227 message transfer service are outside the scope of this 228 specification. 230 When an ESMTP client is authorized to participate in 231 the CONPERM service it MUST interact with the next SMTP 232 hop server, about: 234 * The server�s ability to support authorized conversions, 235 through ESMTP CONPERM 236 * The capabilities supported for the target device or 237 system, through ESMTP CONNEG 239 +-----------+ 240 | Recipient | 241 +-----------+ 242 Capabilities|| 243 \/ 244 +----------------+ +--------+ 245 | SMTP Relay | CONNEG | SMTP | 246 | | Client |<--------| Server | 247 +-------+--------+ +--------+ 249 3.2. Returning Capabilities 251 A target recipient device or system communicates its 252 capabilities to the SMTP service through a means 253 outside the scope of this specification. When an ESMTP 254 server knows a target�s capabilities, it MAY offer the 255 CONNEG ESMTP service extension. 257 When a message is being processed according to this 258 specification, if a next-hop ESMTP server responds that 259 it supports CONNEG, then the SMTP client: 261 (1) MUST request CONNEG information 263 (2) MUST perform the requisite conversions before sending 264 the message to the next-hop SMTP server 266 (3) MUST add a Content-Converted header to each MIME body- 267 part that has been converted and must specify the previous 268 form of the body-part and the current form. 270 When performing conversions, the Client MUST either: 272 (1) Send a single copy to the next-hop SMTP server, using a 273 best capabilities that are supported to all recipients along 274 that path, or 276 (2) Separate the transfers, to provide the best conversions 277 possible for subsets of the recipient. 279 If the transfers are separated, then the current 280 session MUST be terminated, and new sessions conducted 281 for each subset. 283 The conversions that are performed are determined by 284 the intersection of three lists: 286 * Conversions permitted by the sender 287 * Content capabilities of the target 288 * Conversions that can be performed by the SMTP client 289 host 291 If the result of this intersection is the null set of 292 representations, for an addressee, then delivery to 293 that addressee MUST be handled as a failure. 295 If the next-hop SMTP host does not indicate that it can 296 represent the target�s capabilities through CONNEG, but 297 does respond that it can support CONPERM, then the 298 client SMTP MUST send the existing content, if all 299 other SMTP transmission requirements are satisfied. 301 3.3. Next-Hop Non-Support of Service 303 If a Client is participating in this service, but the 304 next-hop SMTP server does not support CONPERM and does 305 not support CONNEG, then the SMTP client 307 (1) MUST terminate the session to the next-hop SMTP server, 308 without sending the message 310 (2) MUST return a DSN notification to the originator that 311 content negotiation could not be performed. 313 If a Client is participating in this service and the 314 next-hop SMTP server supports CONNEG but provides no 315 capabilities for an individual RCPT-TO addressee, then 316 the SMTP client�s processing for that recipient MUST be 317 either to: 319 (1) Treat the addressee as rejected, or 321 (2) Separate the addressee from the address list that is 322 processed according to CONNEG, and continue to process the 323 addressee according to CONPERM. 325 4. CONTENT CONVERSION PERMISSION SMTP EXTENSION 327 4.1. Content Conversion Permission service extension 328 definition 330 (1) The name of the SMTP service extension is 332 "Content_Conversion_Permission" 334 (2) The EHLO keyword value associated with this extension 335 is 337 "CONPERM" 339 (3) A parameter using the keyword "CONPERM" is added to the 340 MAIL-FROM command 342 (4) The server responds with acceptance or rejection of 343 support for CONPERM, for this message 345 4.2. CONPERM parameter to Mail-From 347 Parameter: 349 CONPERM 351 Arguments: 353 There are no arguments. Specification of 354 permitted conversions is located in a Content- 355 Conversion header for each MIME body-part for which 356 conversion is permitted. 358 Client Action: 360 If the server issued a 250-CONPERM, as part of its 361 EHLO response for the current session, and the client 362 is participating in the CONPERM service for this 363 message -- such as by having received the message with 364 a CONPERM requirement -- then the client MUST issue the 365 CONPERM parameter in the MAIL-FROM. If the server 366 does not issue 250-CONPERM, and the client is 367 participating in the CONPERM service for this message, 368 then the client MUST treat the transmission as 369 permanently rejected. 371 Server Action: 373 If the client specifies CONPERM in the MAIL-FROM, 374 but the server does not support the CONPERM parameter, 375 the server MUST reject the MAIL-FROM command with a 504- 376 CONPERM reply. 378 If the client issues the CONPERM parameter in the 379 MAIL-FROM, then the server MUST conform to this 380 specification. Either it must relay the message 381 according to CONPERM, or it must convert the message 382 according to CONNEG information. 384 4.3. Syntax 386 Content_Conversion_Permission = "CONPERM" 388 5. CONTENT NEGOTIATION SMTP EXTENSION 390 5.1. Content Negotiation service extension definition 392 (1) The name of the SMTP service extension is: 394 "Content_Negotiation" 396 (2) The EHLO keyword value associated with this extension 397 is: 399 "CONNEG" 401 (3) A parameter using the keyword "CONNEG" is added to the 402 RCPT TO command 404 (4) The server responds with a report of the content 405 capabilities of the device or system that embodies each 406 target RCPT-TO address. 408 5.2. CONNEG parameter to RCPT-TO 410 Parameter: 412 CONNEG 414 Arguments: 416 There are no arguments. 418 Client Action: 420 If message is subject to CONPERM requirements and 421 the server issues a 250-CONNEG, as part of its EHLO 422 response for the current session, the client MUST issue 423 the CONNEG parameter in the RCPT-TO request. If the 424 message is not subject to CONPERM requirements and the 425 server issues a 250-CONNEG, the client MAY issue the 426 CONNEG parameter with RCPT-TO. 428 If the client issues the CONNEG parameter with 429 RCPT-TO, then it MUST honor the capabilities specified 430 in the CONNEG RCPT-TO replies for that message, and 431 convert the message content, so that the target can 432 accept the data. 434 The conversions that are performed are determined 435 by the intersection of the: 437 * Conversions permitted by the sender 438 * Content capabilities of the target 439 * Conversions that can be performed by the SMTP client 440 host 442 If the result of this intersection is the null set 443 of representations, then the Client processing depends 444 upon whether the message is subject to CONPERM 445 processing: 447 (1) If the message is subject to CONPERM, the Client MAY 448 continue to transmit the original content, according to 449 CONPERM. 451 (2) Otherwise, the Client MUST treat the address as 452 rejected. 454 If the result of the intersection is not null, the 455 client SHOULD convert the data to the "highest" level 456 of capability of the server. Determination of the 457 level that is highest is left to the discretion of the 458 server. 460 The client MUST record the nature of the 461 conversion by using the MIME Content-Converted header 462 for each converted MIME body-part, indicating the 463 previous and new body-part form. 465 Server Action: 467 If the client specifies CONNEG in the RCPT-TO, but 468 the server does not support the CONNEG parameter, the 469 server MUST reject the RCPT-TO addressees with 504 470 replies. 472 If the server does support the CONNEG parameter 473 and it knows the capabilities of the target device or 474 system, then it MUST provide that information through 475 CONNEG. 477 The response to a CONNEG RCPT-TO request will be 478 multi-line RCPT-TO replies. For successful (250) 479 responses, at least the first line of the response is 480 for RCPT-TO information other than CONNEG. Additional 481 response lines are for CONNEG. In order to avoid 482 problems due to variations in line buffer sizes, the 483 total parametric listing must be provided as a series 484 of lines, each beginning with "250-CONNEG " except for 485 the last line, which is "250 CONNEG". 487 The contents of the capability listing MUST 488 conform to the specifications in [FAX]. 490 5.3. Syntax 492 Content_Negotiation = "CONNEG" 493 Capability = <> 495 6. MIME CONTENT-CONVERT HEADER 497 Content-Convert is an optional header field that 498 specifies permitted conversions for the associated 499 content. In its absence, the content originator has 500 provided no guidance about content conversions. 501 Therefore intermediaries SHOULD NOT perform content 502 conversion. 504 It is desirable to keep the set of possible disposition 505 types small and well defined, to avoid needless 506 complexity. Even so, evolving usage will likely require 507 the definition of additional disposition types or 508 parameters, so the set of disposition values is 509 extensible; see below. 511 In the extended ABNF notation, the Content-Convert 512 header field is defined as follows: 514 Convert = "Content-convert" ":" 515 permitted 517 Permitted = "ANY" / <> 520 If the permitted conversions are specified as "ANY" 521 then the intermediary may perform any conversions it 522 deems appropriate. 524 7. MIME CONTENT-CONVERTED HEADER 526 When an intermediary has performed conversion of the 527 associated content, the intermediary MUST record the 528 nature of the conversion that was performed. This 529 information is placed in a Content-Converted header 530 associated with the converted content. 532 In the extended ABNF notation, the Content-Converted 533 header field is defined as follows: 535 converted = "Content-converted" [CFWS] ":" 536 [CFWS] 537 "Date " [CFWS] date-time [CFWS]";" 538 [CFWS] 539 "By " [CFWS] domain [CFWS]";" 540 [CFWS] 541 "Old " [CFWS] type [CFWS]";" [CFWS] 542 "New " [CFWS] type [CFWS] 544 domain = <> 548 date-time = <> 551 type = <> 554 8. EXAMPLES 556 8.1. CONPERM Negotiation 558 S: 220 example.com IFAX 559 C: EHLO example.com 560 S: 250- example.com 561 S: 250-DSN 562 S: 250 CONPERM 563 C: MAIL FROM:May@some.example.com CONPERM 564 S: 250 sender ok 565 C: RCPT TO: 566 S: 250- recipient ok 567 C: DATA 568 S: 354 okay, send data 569 C: <> 596 S: 250 message accepted 597 C: QUIT 598 S: 221 goodbye 600 8.2. Example CONNEG Negotiation 602 S: 220 example.com IFAX 603 C: EHLO example.com 604 S: 250- example.com 605 S: 250-DSN 606 S: 250 CONNEG 607 C: MAIL FROM: 608 S: 250 sender ok 609 C: RCPT TO: CONNEG 610 S: 250- recipient ok 611 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 612 S: 250-CONNEG (MRC-mode=0) 613 S: 250-CONNEG (color=Binary) 614 S: 250-CONNEG (|(&(dpi=204) 615 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 616 S: 250-CONNEG (&(dpi=200) 617 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 618 S: 250-CONNEG (image-coding=[MH,MR,MMR]) 619 S: 250-CONNEG (size-x<=2150/254) 620 S: 250-CONNEG (paper-size=[letter,A4]) 621 S: 250 CONNEG (ua-media=stationery) ) 622 C: DATA 623 S: 354 okay, send data 624 C: <> 633 S: 250 message accepted 634 C: QUIT 635 S: 221 goodbye 637 8.3. Content-Converted 638 Content-converted: 639 Date Tue, 1 Jul 2001 10:52:37 +0200 ; 640 By relay.example.com ; 641 Old 642 (&(image-file-structure=TIFF-minimal) 643 (MRC-mode=0) 644 (color=Binary) 645 (&(dpi=400) 646 (dpi-xyratio=1) ) 647 (&(image-coding=JBIG) 648 (image-coding-constraint=JBIG-T85) 649 (JBIG-stripe-size=128) ) 650 (size-x=2150/254) 651 (paper-size=A4) 652 (ua-media=stationery) ) ; 653 New 654 (&(image-file-structure=TIFF-minimal) 655 (MRC-mode=0) 656 (color=Binary) 657 (&(dpi=200) 658 (dpi-xyratio=1) ) 659 (image-coding=MMR) 660 (size-x=2150/254) 661 (paper-size=letter) 662 (ua-media=stationery) ) 664 9. IANA CONSIDERATIONS 666 This memo is not intended to create any new issues for 667 IANA. 669 10. SECURITY CONSIDERATIONS 671 This service calls for participants to disclose their 672 capabilities. Mechanisms for determining the 673 requestor�s and the respondent�s authenticated identity 674 are outside the scope of this specification. It is 675 intended that these mechanisms permit disclosure of 676 public information; hence there is no particular need 677 for security measures. 679 However there is nothing to prevent disclosure of 680 sensitive information that should receive restricted 681 distribution. It is, therefore, the responsibility of 682 the disclosing ESMTP server or disclosing ESMTP client 683 to determine whether additional security measures 684 should be applied to the use of this ESMTP option. 686 11. ACKNOWLEDGEMENTS 688 Graham Klyne and Eric Burger provided diligent review 689 and useful suggestions. 691 12. REFERENCES (NORMATIVE) 693 [DISPLAY] Masinter, L., Holtman, K., Mutz, A. and 694 D. Wing, "Media Features for Display, 695 Print, and Fax", RFC 2534, March 1999. 697 [DSN] Moore, K., "SMTP Service Extension for 698 Delivery Status Notifications", RFC 699 1892, January 1996. 701 [ESMTP1] Klensin, J., Freed, N., Rose, M., 702 Stefferud, E. and D. Crocker, "SMTP 703 Service Extensions", RFC 1869, November 704 1995 706 [ESMTP2] Klensin, J., "Simple Mail Transfer 707 Protocol", RFC 2821, April 2001. 709 [FAX] McIntyre, L. and G. Klyne, "Content 710 Feature Schema for Internet Fax", RFC 711 2879, August 2000 713 [IMF] Resnick, P., "Internet Message Format", 714 RFC 2822, April 2001 716 [TAG] Holtman, K., Mutz, A. and T. Hardie, 717 "Media Feature Tag Registration 718 Procedure", RFC 2506, March 1999. 720 [SETS] Klyne, G., "A syntax for describing 721 media feature sets", RFC 2533, March 722 1999. 724 13. AUTHORS� ADDRESSES 726 Kiyoshi Toyoda 727 Network Technology Development Center 728 Panasonic Communications Co., Ltd. 729 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 731 tel: +81-3-5434-7161 732 fax: +81-3-5434-7156 733 toyoda.kiyoshi@jp.panasonic.com 735 Dave Crocker 736 Brandenburg InternetWorking 737 675 Spruce Drive 738 Sunnyvale, CA 94086 USA 740 Tel: +1.408.246.8253 741 dcrocker@brandenburg.com 743 14. FULL COPYRIGHT STATEMENT 745 Copyright (C) The Internet Society (2003). All Rights 746 Reserved. 748 This document and translations of it may be copied and 749 furnished to others, and derivative works that comment 750 on or otherwise explain it or assist in its 751 implementation may be prepared, copied, published and 752 distributed, in whole or in part, without restriction 753 of any kind, provided that the above copyright notice 754 and this paragraph are included on all such copies and 755 derivative works. However, this document itself may 756 not be modified in any way, such as by removing the 757 copyright notice or references to the Internet Society 758 or other Internet organizations, except as needed for 759 the purpose of developing Internet standards in which 760 case the procedures for copyrights defined in the 761 Internet Standards process must be followed, or as 762 required to translate it into languages other than 763 English. 765 The limited permissions granted above are perpetual and 766 will not be revoked by the Internet Society or its 767 successors or assigns. 769 This document and the information contained herein is 770 provided on an "AS IS" basis and THE INTERNET SOCIETY 771 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 772 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 773 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 774 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 775 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 776 PARTICULAR PURPOSE. 778 APPENDIX A: CONNEG WITH DIRECT SMTP 780 In some configurations it is possible to have direct 781 email-based interactions -- where the originator's 782 system conducts a direct, interactive TCP connection 783 with the recipient's system. This configuration 784 permits a use of CONPERM/CONNEG that conforms to the 785 specification here, but it also permits some 786 simplifications, because there is a single SMTP 787 session, rather than multiple, relaying sessions. 789 The Originator's system provides user-level functions 790 for the originator, and it contains the SMTP Client for 791 sending messages. Hence, the formal step of email 792 "posting" is a process that is internal or virtual, 793 within the Originating system. The recipient's service 794 contains the user-level functions for the recipient, 795 and it contains the SMTP server, for receiving 796 messages. Hence the formal steps of email "delivering" 797 and "receipt" are internal or virtual, within the 798 Receiving system. 800 The figure below shows these relationships: 802 Originating system Receiving system 803 +------------------+ +-----------------+ 804 | +------------+ | | +-----------+ | 805 | | Originator | | | | Recipient | | 806 | +------------+ | | +-----------+ | 807 | ||Posting | | /\Receipt | 808 | \/ | | || | 809 | +---------+ | | +--------+ | 810 | | SMTP |<---|-----|---| SMTP | | 811 | | Client |----|-----|-->| Server | | 812 | +---------+ | | +--------+ | 813 +------------------+ +-----------------+ 815 In this case CONPERM is not needed, because the SMTP 816 Client is part of the originating system. Therefore it 817 already has the necessary permission. Similarly, the 818 SMTP server will be certain to know the recipient's 819 capabilities, because the server is part of the 820 receiving system. 822 * For Originating systems that conform to this 823 specification and are operating in a Direct SMTP mode, the 824 communication process between originator and recipient is 825 the same as would take place between the last-hop SMTP Relay 826 and the Delivering SMTP server. That is, the Client and 827 Server MUST employ CONNEG and the Client MUST perform any 828 requisite conversions.