idnits 2.17.1 draft-ietf-fax-esmtp-conneg-01.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 354 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 89: '...or the current session, the client MAY...' RFC 2119 keyword, line 93: '...RCPT-TO, then it MUST honor the capabi...' RFC 2119 keyword, line 96: '... client SHOULD transform the data ...' RFC 2119 keyword, line 103: '... target MUST reject the RCPT-TO co...' RFC 2119 keyword, line 107: '... then it MUST issue a 250 reply, f...' (2 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.) -- The document date (November 2001) is 8170 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 60, 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) 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-01.txt November 2001 5 Expires: May 2002 7 SMTP Service Extension 8 for Content Negotiation of Internet Fax 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 SUMMARY 40 This document defines a content negotiation SMTP 41 service extension [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. This service 48 extension is primarily intended for "direct" SMTP 49 transfers, although relayed scenarios are permitted. 51 1. CONVENTIONS 53 In examples, "C:" and "S:" indicate lines sent by the 54 client and server respectively. 56 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 57 NOT", and "MAY" in this document are to be interpreted 58 as defined in "Key words for use in RFCs to Indicate 59 Requirement Levels" [KEYWORDS]. 61 2. CONTENT NEGOTIATION SERVICE EXTENSION 63 (1) The name of the SMTP service extension is 64 "Content_Negotiation" 66 (2) The EHLO keyword value associated with this extension 67 is "CONNEG" 69 (3) A parameter using the keyword "CONNEG" is added to the 70 RCPT-TO command 72 (4) The server responds with a report of the content 73 capabilities of the device or system that embodies the 74 target RCPT-TO address. 76 3. CONNEG PARAMETER TO RCPT-TO 78 Parameter: 80 CONNEG 82 Arguments: 84 There are no arguments. 86 Client Action: 88 If the server issued a 250-CONNEG, as part of its 89 EHLO response for the current session, the client MAY 90 issue the CONNEG parameter with RCPT-TO. 92 If the client issues the CONNEG parameter with 93 RCPT-TO, then it MUST honor the capabilities specified 94 in the CONNEG RCPT-TO reply, and transform data that is 95 sent, so that the target can accept the data. The 96 client SHOULD transform the data to the "highest" level 97 of capability of the target. 99 Server Action: 101 If the client specifies CONNEG in the RCPT-TO, but 102 the target does not support the CONNEG parameter, the 103 target MUST reject the RCPT-TO command with a 504 104 reply. 106 If the target does support the CONNEG parameter, 107 then it MUST issue a 250 reply, followed by its 108 capabilities of the target that is specified by the 109 RCPT-TO address. 111 Successful responses to CONNEG RCPT-TO 112 requests will always be multiple SMTP lines. The 113 first line is the normal RCPT-TO response, and 114 subsequent lines beginning with the exact string 115 "250-CONNEG " and "250 CONNEG " are the CONNEG responses. 116 The last line begins with "250 CONNEG ". if the SMTP 117 server supports ENHANCEDSTATUSCODES, the exact strings 118 are "250-2.1.5 CONNEG " and "250 2.1.5 CONNEG ". 120 All CONNEG-capable clients and CONNEG-capable servers MUST 121 be able to successfully process CONNEG lines that are up to 512 122 characters long, as required by RFC2821. 124 The contents of the capability listing MUST 125 conform to the specifications in "Content Feature 126 Schema for Internet Fax". [RFC2879] 128 4. SYNTAX 130 Command with "CONNEG": 131 "RCPT TO:" ("" / "" 132 / Forward-Path) (SP "CONNEG") CRLF 134 Reply: 135 ( ("250-" CRLF) *("250-CONNEG" capability CRLF) 136 ("250 CONNEG" capability CRLF) )/ 137 ( ("250-2.1.5" CRLF) 138 *("250-2.1.5 CONNEG" capability CRLF) 139 ("250 2.1.5 CONNEG" capability CRLF) ) 141 capability = <> 143 5. EXAMPLE 145 S: 220 ifax1.jp IFAX 147 C: EHLO ifax1.jp 149 S: 250-ifax1.jp 150 S: 250-DSN 151 S: 250 CONNEG 153 C: MAIL FROM: 155 S: 250 sender ok 157 C: RCPT TO: CONNEG 159 S: 250- recipient ok 160 S: 250-CONNEG (&(image-file-structure=TIFF-minimal) 161 S: 250-CONNEG (MRC-mode=0) 162 S: 250-CONNEG (color=Binary) 163 S: 250-CONNEG (|(&(dpi=204) 164 S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 165 S: 250-CONNEG (&(dpi=200) 166 S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) 167 S: 250-CONNEG (&(dpi=400) 168 S: 250-CONNEG (dpi-xyratio=1) ) ) 169 S: 250-CONNEG (|(image-coding=[MH,MR,MMR]) 170 S: 250-CONNEG (&(image-coding=JBIG) 171 S: 250-CONNEG (image-coding-constraint=JBIG-T85) 172 S: 250-CONNEG (JBIG-stripe-size=128) ) ) 173 S: 250-CONNEG (paper-size=[letter,A4,B4]) 174 S: 250 CONNEG (ua-media=stationery) ) 176 C: DATA 178 S: 354 okay, send data 180 C: <> 189 S: 250 message accepted 191 C: QUIT 193 S: 221 goodbye 195 An example when CONNEG-capable server supports 196 ENHANCEDSTATUSCODES. 198 S: 220 ifax1.jp IFAX 200 C: EHLO ifax1.jp 202 S: 250-ifax1.jp 203 S: 250-DSN 204 S: 250-ENHANCEDSTATUSCODES 205 S: 250 CONNEG 207 C: MAIL FROM: 209 S: 250 2.1.5 sender ok 211 C: RCPT TO: CONNEG 213 S: 250-2.1.5 recipient ok 214 S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) 215 S: 250-2.1.5 CONNEG (MRC-mode=0) 216 S: 250-2.1.5 CONNEG (color=Binary) 217 S: 250-2.1.5 CONNEG (|(&(dpi=204) 218 S: 250-2.1.5 CONNEG (dpi-xyratio=[204/98,204/196]) ) 219 S: 250-2.1.5 CONNEG (&(dpi=200) 220 S: 250-2.1.5 CONNEG (dpi-xyratio=[200/100,1]) ) 221 S: 250-2.1.5 CONNEG (&(dpi=400) 222 S: 250-2.1.5 CONNEG (dpi-xyratio=1) ) ) 223 S: 250-2.1.5 CONNEG (|(image-coding=[MH,MR,MMR]) 224 S: 250-2.1.5 CONNEG (&(image-coding=JBIG) 225 S: 250-2.1.5 CONNEG (image-coding-constraint=JBIG-T85) 226 S: 250-2.1.5 CONNEG (JBIG-stripe-size=128) ) ) 227 S: 250-2.1.5 CONNEG (paper-size=[letter,A4,B4]) 228 S: 250 2.1.5 CONNEG (ua-media=stationery) ) 230 6. IANA CONSIDERATIONS 232 This memo is not intended to create any new issues for 233 IANA. 235 7. SECURITY CONSIDERATIONS 237 This ESMTP option calls for a respondent to disclose 238 its capabilities. Mechanisms for determining the 239 requestor's authenticated identity are outside the 240 scope of this specification. It is intended that this 241 mechanism permit disclosure of public information; 242 hence there is no particular need for security 243 measures. 245 However there is nothing to prevent disclosure of 246 sensitive information that should receive restricted 247 distribution. It is, therefore, the responsibility of 248 the disclosing ESMTP server to determine whether 249 additional security measures should be applied to the 250 use of this ESMTP option. 252 8. ACKNOWLEDGEMENTS 254 Graham Klyne provided useful suggestions to an earlier 255 draft. 257 9. REFERENCES 259 [ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, 260 E. and D. Crocker, "SMTP Service Extensions", 261 RFC 1869, November 1995 263 [ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", 264 RFC 2821, April 2001. 266 [RFC2879] McIntyre, L. and G. Klyne, "Content Feature 267 Schema for Internet Fax", RFC 2531, August 268 2000 270 10. AUTHORS' ADDRESSES 272 Kiyoshi Toyoda 273 Matsushita Graphic Communication Systems,Inc 274 2-3-8 Shimomeguro, Meguro-Ku 275 Tokyo 153 JAPAN 277 +81.3.5434.7161 278 ktoyoda@rdmg.mgcs.mei.co.jp 280 Dave Crocker 281 Brandenburg InternetWorking 282 675 Spruce Drive 283 Sunnyvale, CA 94086 USA 285 +1.408.246.8253 286 dcrocker@brandenburg.com 288 11. FULL COPYRIGHT STATEMENT 290 Copyright (C) The Internet Society (2001). All Rights 291 Reserved. 293 This document and translations of it may be copied and 294 furnished to others, and derivative works that comment 295 on or otherwise explain it or assist in its 296 implementation may be prepared, copied, published and 297 distributed, in whole or in part, without restriction 298 of any kind, provided that the above copyright notice 299 and this paragraph are included on all such copies and 300 derivative works. However, this document itself may 301 not be modified in any way, such as by removing the 302 copyright notice or references to the Internet Society 303 or other Internet organizations, except as needed for 304 the purpose of developing Internet standards in which 305 case the procedures for copyrights defined in the 306 Internet Standards process must be followed, or as 307 required to translate it into languages other than 308 English. 310 The limited permissions granted above are perpetual and 311 will not be revoked by the Internet Society or its 312 successors or assigns. 314 This document and the information contained herein is 315 provided on an "AS IS" basis and THE INTERNET SOCIETY 316 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 317 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 318 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 319 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 321 PARTICULAR PURPOSE.