idnits 2.17.1 draft-ietf-fax-esmtp-conneg-02.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: ---------------------------------------------------------------------------- ** 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 539 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ESMTP1,ESMTP2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 111: '... REQUIRED...' RFC 2119 keyword, line 114: '... MUST reject the RCPT-TO co...' RFC 2119 keyword, line 117: '...rary problem, it MUST reject the RCPT-...' RFC 2119 keyword, line 120: '... OPTIONAL...' RFC 2119 keyword, line 123: '... target MUST process the addr...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 85, but not defined ** 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 2531 (ref. 'RFC2879') (Obsoleted by RFC 2879) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-02.txt June 2002 5 Expires: December 2002 7 SMTP Service Extension 8 for 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 (2001). All Rights 36 Reserved. 38 ABSTRACT 40 This document defines a content negotiation service 41 extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP 42 client may request information about content 43 capabilities of the target device or system that is 44 serviced by an SMTP server. The SMTP server may report 45 the target's content capabilities back to the client. 46 This process emulates a classic facsimile start-of- 47 session capabilities negotiation, although it can be used 48 for a broad range of email-based scenarios. This service 49 extension is primarily intended for "direct", one-hop, 50 originator/recipient SMTP transfers, although relayed 51 scenarios through multiple SMTP servers are permitted. 53 1. INTRODUCTION 55 When a data source and a receiver have interactive access to 56 each other, the receiver often informs the source of its 57 capabilities, to permit optimized performance or functionality for 58 the interaction. Classic telephone-based facsimile is an example, 59 as are voice over IP and ESMTP among Internet applications. The 60 store-and-forward nature of Internet mail is usually assumed to 61 preclude such capabilities exchanges. However direct email-based 62 interactions are possible with proper configuration of the email 63 originator and recipient servers, such as over an intranet. 65 This document defines an SMTP-based service extension [ESMTP1, 66 ESMTP2] for content negotiation, whereby an SMTP client may 67 request information about content capabilities of the target 68 device or system that is serviced by an SMTP server. The SMTP 69 server may report the target's content capabilities back to the 70 client. This process emulates a classic facsimile start-of-session 71 capabilities negotiation, although it may be used for any email- 72 based service. This extension is primarily intended for "direct" 73 SMTP transfers, although relayed scenarios are permitted through a 74 series of SMTP servers. 76 2. CONVENTIONS 78 In examples, "C:" and "S:" indicate lines sent by the 79 client and server respectively. 81 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 82 NOT", and "MAY" in this document are to be interpreted 83 as defined in "Key words for use in RFCs to Indicate 84 Requirement Levels" [KEYWORDS]. 86 3. CONTENT NEGOTIATION SERVICE EXTENSION 88 (1) The name of the SMTP service extension is 89 "Content_Negotiation" 91 (2) The EHLO keyword value associated with this extension 92 is "CONNEG" 94 (3) A parameter using the keyword "CONNEG" is added to the 95 RCPT-TO command 97 (4) The server responds with a report of the content 98 capabilities of the device or system that embodies the 99 target RCPT-TO address. 101 4. CONNEG PARAMETER TO RCPT-TO 103 4.1 Parameter 105 Keyword: 107 CONNEG 109 Argument: 111 REQUIRED 112 The client requires support for the capability. If the 113 target does not support the CONNEG parameter, the target 114 MUST reject the RCPT-TO command with a 504 reply. 116 If the target can not support the capability due to a 117 temporary problem, it MUST reject the RCPT-TO command with 118 a 404 reply. 120 OPTIONAL 121 The client requests the target to use the capability. If 122 the target can not support the capability at this time, the 123 target MUST process the address and message as if the 124 requested CONNEG capabilities had not been specified. 126 If the argument does not exist, the default is "REQUIRED". 128 When a capability is REQUIRED by the client but can not 129 currently be supported by the target, an error response will 130 have significant performance impact to overall SMTP 131 processing. Use of the OPTIONAL parameter will ensure high 132 SMTP performance. 134 4.2 Client Action: 136 If the server issued a 250-CONNEG, as part of its 137 EHLO response for the current session, the client MAY 138 issue the CONNEG parameter with RCPT-TO. 140 If the client issues the CONNEG parameter with 141 RCPT-TO, then it MUST honor the capabilities specified 142 in the CONNEG RCPT-TO reply, and transform data that is 143 sent, so that the target can accept the data. The 144 client SHOULD transform the data to the "highest" level 145 of capability of the target. 147 If the server rejects the RCPT-TO command with a 404 reply, the 148 client may later reissue the RCPT-TO with the CONNEG parameter. 150 If the server returns an EHLO 250 code without CONNEG 151 capabilities, the client MUST work as "a Simple Mode of Facsimile 152 Using Internet Mail" [RFC2305]. 154 4.3 Server Action: 156 If the client specifies "CONNEG = REQUIRED" in the RCPT-TO, 157 but the target does not support the CONNEG parameter, the target 158 MUST reject the RCPT-TO command with a 504 reply. 160 If the target support the CONNEG parameter, but it can not return 161 the recepient's capability temporarily, the target MUST reject the 162 RCPT-TO command with a 404 reply. For example, if the target get 163 the capability information from a directory, but its connection is 164 offline, the target MUST reject the RCPT-TO command with a 404 165 reply. 167 If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the 168 target MUST process the address and message as if the requested 169 CONNEG capabilities had not been specified. 171 Regardless of the value of the parameter, if the target does 172 support the CONNEG parameter, then it MUST issue a 250 reply, 173 followed by the capabilities of the target that is specified by 174 the RCPT-TO address. Successful responses to CONNEG RCPT-TO 175 requests will always be multiple SMTP lines. The first line 176 is the normal RCPT-TO response, and subsequent lines beginning 177 with the exact string "250-CONNEG " and "250 CONNEG " are 178 the CONNEG responses. The last line begins with "250 179 CONNEG". 181 If the SMTP server supports ENHANCEDSTATUSCODES, the response 182 strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 183 CONNEG". The response strings for indicating a permanent 184 failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". 185 The response strings for a temporary failure are "404-4.3.3 186 CONNEG" and "404 5.3.3 CONNEG". 188 All CONNEG-capable clients and CONNEG-capable servers MUST 189 be able to successfully process CONNEG lines that are up to 512 190 characters long, as required by RFC2821. If the length of CONNEG 191 lines is greater than 512 characters, the server MUST insert 192 line breaks and make next CONNEG line. 194 The contents of the capability listing MUST conform to 195 [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate 196 services, such as the facsimile start-of-session capabilities 197 negotiation as described in "Content Feature Schema for 198 Internet Fax". [RFC2879] 200 5. SYNTAX 202 Command with "CONNEG": 203 "RCPT TO:" ("" / "" 204 / Forward-Path) (SP "CONNEG =" ("REQUIRED" / 205 "OPTIOANL") CRLF 207 Reply: 208 ( ("250-" CRLF) *("250-CONNEG" capability CRLF) 209 ("250 CONNEG" capability CRLF) )/ 210 ( ("250-2.1.5" CRLF) 211 *("250-2.1.5 CONNEG" capability CRLF) 212 ("250 2.1.5 CONNEG" capability CRLF) )/ 213 ("504" CRLF) / 214 ("504 5.3.3" CRLF) / 215 ("404" CRLF) / 216 ("404 4.3.3" CRLF) / 218 capability = <> 221 6. EXAMPLE 223 An example of ESMTP sequence with successful RCPT-TO response 225 S: 220 ifax1.jp IFAX 227 C: EHLO ifax1.jp 229 S: 250-ifax1.jp 230 S: 250-DSN 231 S: 250 CONNEG 233 C: MAIL FROM: 235 S: 250 sender ok 237 C: RCPT TO: CONNEG = REQUIRED 239 S: 250- recipient ok 240 S: 250 CONNEG (&(image-file-structure=TIFF-minimal) 241 S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) 242 S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) 243 S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) 244 S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) 245 S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) 246 S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) 247 S: (ua-media=stationery) ) 249 C: DATA 251 S: 354 okay, send data 253 C: <> 262 S: 250 message accepted 264 C: QUIT 266 S: 221 goodbye 268 An example of successful RCPT-TO response when the length of 269 capability is greater than 512 characters. 271 S: 250-2.1.5 recipient ok 272 S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) ... 273 S: 250-2.1.5 CONNEG ..... 274 S: 250 2.1.5 CONNEG (color=Binary) 276 An example of succssful RCPT-TO response when CONNEG-capable 277 server supports ENHANCEDSTATUSCODES. 279 S: 250-2.1.5 recipient ok 280 S: 250 2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) 281 S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) 282 S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) 283 S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) 284 S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) 285 S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) 286 S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) 287 S: (ua-media=stationery) ) 289 An example of ESMTP sequence with parmanent failure RCPT-TO 290 response. 292 S: 220 ifax1.jp IFAX 294 C: EHLO ifax1.jp 296 S: 250-ifax1.jp 297 S: 250-DSN 299 C: MAIL FROM: 301 S: 250 sender ok 303 C: RCPT TO: CONNEG = REQUIRED 305 S: 504 recipient ok 307 C: QUIT 309 S: 221 goodbye 311 An example of an ESMTP sequence with temporary failure RCPT-TO 312 response when the value of parameter is "REQUIRED": 314 S: 220 ifax1.jp IFAX 316 C: EHLO ifax1.jp 318 S: 250-ifax1.jp 319 S: 250-DSN 320 S: 250 CONNEG 322 C: MAIL FROM: 324 S: 250 sender ok 326 C: RCPT TO: CONNEG = REQUIRED 328 S: 404 recipient ok 330 C: QUIT 332 S: 221 goodbye 333 . 334 . 335 . 336 retry according to implementation 338 An example of an ESMTP sequence with temporary failure RCPT-TO 339 response when the value of parameter is "OPTIONAL": 341 S: 220 ifax1.jp IFAX 343 C: EHLO ifax1.jp 345 S: 250-ifax1.jp 346 S: 250-DSN 347 S: 250 CONNEG 349 C: MAIL FROM: 351 S: 250 sender ok 353 C: RCPT TO: CONNEG = OPTIONAL 355 S: 250 recipient ok 357 C: DATA 359 S: 354 okay, send data 361 C: <> 366 S: 250 message accepted 368 C: QUIT 370 S: 221 goodbye 372 7. IANA CONSIDERATIONS 374 On publicatiom of this document by the RFC Editor, the IANA 375 shall register the Content_Negotiation ESMTP extension defined 376 in section 3. 378 8. SECURITY CONSIDERATIONS 380 This ESMTP option calls for a respondent to disclose 381 its capabilities. Mechanisms for determining the 382 requestor's authenticated identity are outside the 383 scope of this specification. It is intended that this 384 mechanism permit disclosure of public information; 385 hence there is no particular need for security 386 measures. 388 However there is nothing to prevent disclosure of 389 sensitive information that should receive restricted 390 distribution. It is, therefore, the responsibility of 391 the disclosing ESMTP server to determine whether 392 additional security measures should be applied to the 393 use of this ESMTP option. 395 A man-in-the-middle attack might change the capabilities reported 396 for a given recipient. For example: Suppose the sender knows the 397 recipient has the ability to view color documents so they mark 398 some things in red in what is otherwise a black and white 399 document. But someone interferes with the returned capabilities, 400 indicating that the recipient only supports black and white. The 401 document is duly downgraded, with the result that the recipient 402 doesn't see what the sender marked. 404 An indirect exposure can occur when the report of a capability 405 implies use of specific software. If that software is known to 406 have security weaknesses, the capabilities report effectively 407 advertises the associated opportunity to exploit the security 408 weakness. 410 For target SMTP servers that require security mechanisms to be in 411 force at the start of the session, the target SHOULD refrain from 412 including the CONNEG parameter in an EHLO response until the 413 requisite security mechanisms are in force. 415 9. ACKNOWLEDGEMENTS 417 Graham Klyne provided useful suggestions to an earlier 418 draft. 420 10. NORMATIVE REFERENCES 422 [ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, 423 E. and D. Crocker, "SMTP Service Extensions", 424 RFC 1869, November 1995 426 [ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", 427 RFC 2821, April 2001. 429 [RFC2879] McIntyre, L. and G. Klyne, "Content Feature 430 Schema for Internet Fax", RFC 2531, August 431 2000 433 [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, 434 "A Simple Mode of Facsimile Using Internet Mail", 435 RFC 2305, March 1998. 437 [RFC2506] Holtman, K., Mutz, A. and T. Hardie, "Media Feature 438 Tag Registration Procedure", RFC 2506, March 1999. 440 [RFC2533] Klyne, G., "A syntax for describing media feature 441 sets", RFC 2533, March 1999. 443 [RFC2534] Masinter, L., Holtman, K., Mutz, A. and D. Wing, " 444 Media Features for Display, Print, and Fax", 445 RFC 2534, March 1999. 447 11. AUTHORS' ADDRESSES 449 Kiyoshi Toyoda 450 Matsushita Graphic Communication Systems,Inc 451 2-3-8 Shimomeguro, Meguro-Ku 452 Tokyo 153 JAPAN 454 +81.3.5434.7161 455 ktoyoda@rdmg.mgcs.mei.co.jp 457 Dave Crocker 458 Brandenburg InternetWorking 459 675 Spruce Drive 460 Sunnyvale, CA 94086 USA 462 +1.408.246.8253 463 dcrocker@brandenburg.com 465 12. FULL COPYRIGHT STATEMENT 467 Copyright (C) The Internet Society (2001). All Rights 468 Reserved. 470 This document and translations of it may be copied and 471 furnished to others, and derivative works that comment 472 on or otherwise explain it or assist in its 473 implementation may be prepared, copied, published and 474 distributed, in whole or in part, without restriction 475 of any kind, provided that the above copyright notice 476 and this paragraph are included on all such copies and 477 derivative works. However, this document itself may 478 not be modified in any way, such as by removing the 479 copyright notice or references to the Internet Society 480 or other Internet organizations, except as needed for 481 the purpose of developing Internet standards in which 482 case the procedures for copyrights defined in the 483 Internet Standards process must be followed, or as 484 required to translate it into languages other than 485 English. 487 The limited permissions granted above are perpetual and 488 will not be revoked by the Internet Society or its 489 successors or assigns. 491 This document and the information contained herein is 492 provided on an "AS IS" basis and THE INTERNET SOCIETY 493 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 494 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 495 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 496 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 498 PARTICULAR PURPOSE.