idnits 2.17.1 draft-ietf-fax-smtp-capabilities-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([SMTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1998) is 9477 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC821' is mentioned on line 143, but not defined ** Obsolete undefined reference: RFC 821 (Obsoleted by RFC 2821) -- No information found for draft-ietf-acap-spec- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACAP' -- No information found for draft-ietf-drums-abnf- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' -- No information found for draft-greenblatt-defema- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIR-EMAIL' -- No information found for draft-leach-asid-ds-email- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DS-EMAIL' -- No information found for draft-ietf-fax-profile- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FAX-PROFILE' -- No information found for draft-ietf-fax-requirements- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FAX-REQ' -- No information found for draft-ietf-http-negotiation- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HTTP-NEG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SALUTATION' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIME-40BIT' ** Obsolete normative reference: RFC 822 (ref. 'SMTP') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1869 (ref. 'SMTP-EXT') (Obsoleted by RFC 2821) -- No information found for draft-ietf-drums-smtpupd- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SMTP-UPD' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dan Wing 2 Internet Draft Neil Joffe 3 November 3, 1997 Cisco Systems, Inc. 4 Expires May 1998 6 SMTP Service Extension for Capabilities Exchange 7 draft-ietf-fax-smtp-capabilities-00.txt 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents .br of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Note: although this work has been discussed in the 28 IETF-FAX working group, it does not purport to represent 29 the consensus of the group. 31 0. Administrivia 33 0.1. Changes since previous versions 35 Changes from draft-wing-smtp-capabilities-00.txt to 36 draft-ietf-fax-smtp-capabilities-00.txt: 38 * Filename changed from -wing- to -ietf-fax-. 39 * More example methods to get recipient capabilities in section 40 2.1. 41 * Reference fax requirements document and fax profile for internet 42 mail document. 44 1. Abstract 45 This document describes an extension to SMTP [SMTP] which provides a 46 mechanism for capabilities exchange so the sender of a message can know 47 selected capabilities of its ultimate recipient, or of the message 48 transmission path to that recipient. 50 2. Introduction 52 This memo defines a mechanism to allow an SMTP client to determine the 53 capabilities (such as viewers, word processors, and color support) and 54 preferences (such as language) of a recipient, which allows the SMTP 55 client to send a message in a format that is usable by the recipient. 57 This memo was motivated by an analysis of the requirements for using the 58 Internet to deliver fax messages, described in [FAX-REQ] and 59 [FAX-PROFILE]. While capabilities exchange is necessary for fax, it can 60 be useful in other messaging scenerios such as delivery to cellular 61 telephones via SMS, security [SMIME-40BIT], and to send normal messages 62 that will be usable by the recipient. 64 2.1. CAPABILITIES Extension 66 The CAPABILITIES extension permits an SMTP client to easily obtain a 67 list of a recipient's capabilities. These capabilities can be used by 68 the client to send a message that is known to be readable, processable, 69 or understood by the recipient, or to inform the mail user agent that 70 the recipient will be unable to read the message. 72 The CAPS esmtp-keyword for the RCPT command causes the server to 73 advertise recipient capabilities. These capabilities can be: 75 (a) those of the actual recipient (if known through a mechanism 76 such as [ACAP], [DIR-EMAIL], [DS-EMAIL], [SALUTATION], querying 77 the next MTA in the SMTP path, or some other 78 implementation-specific mechanism), or 80 (b) the recipient's capabilities (from (a)), plus those capabilities 81 the SMTP server is willing to accept and translate to the 82 recipient's capabilities (text/8bit to text/quoted-printable, for 83 example). 85 This memo uses the mechanism described in [SMTP-EXT] to define an 86 extension to the SMTP protocol for indicating recipient's capabilities 87 to the SMTP client. 89 2.2. Discussion of this draft 90 This draft is being discussed on the "ietf-fax" mailing list. To 91 subscribe, send a message to: 92 ietf-fax-request@imc.org 93 with the line: 94 subscribe 95 in the body of the message. Archives are available from 96 http://www.imc.org/ietf-fax. 98 2.3. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [REQ]. 104 3. Framework for capabilities extension 106 The following service extension is defined for capabilities exchange. 108 (1) The name of the capabilities extension is Capabilities; 110 (2) the EHLO keyword value associated with the capabilities extension 111 is CAPABILITIES; 113 (3) no parameters are allowed with this extension; 115 (4) no new SMTP verbs are associated with this extension; 117 (5) one optional parameter for the RCPT command, using the 118 esmtp-keyword "CAPS", (used to request the capabilities of the 119 recipient), is defined in section 4, 121 no parameters are added to the MAIL command; 123 (6) the maximum length of RCPT TO is increased by 5 characters. 125 4. Behavior of RCPT TO: CAPS 127 A RCPT command issued by a client may contain the optional esmtp-keyword 128 "CAPS" to indicate that the SMTP client wishes to receive recipient 129 capabilities information in the RCPT response from the SMTP server. 131 The server should be aware of the nature of the recipient via some 132 implementation-specific method (LDAP or other directory query, 133 contacting the destination system directly, [DIR-EMAIL], or some other 134 implementation-specific method). 136 4.1. Responses to RCPT TO esmtp-keyword CAPS 138 The response to the esmtp-keyword CAPS on a RCPT TO command is a 139 multiline reply, consisting of the standard SMTP reply, followed by 140 recipient capabilities in the format specified in section 6 and 8.2 of 141 [HTTP-NEG] and section 14 of [HTTP-1.1]. The response should be split 142 on multiple lines to not exceed the 512 character limit for a reply line 143 as specified in [RFC821, SMTP-UPD]. 145 The SMTP server only needs to indicate capabilities if the SMTP server 146 is responding with a positive (2xx) reply. Non-positive replies don't 147 need to include capabilities and such capabilities are to be ignored by 148 the SMTP client if they are present. 150 The positive response, in [ABNF] form is: 152 caps-response = rsp-code SP rcpt-response CR LF / 153 ( rsp-code "-" rcpt-response CR LF 154 1*( rsp-code "-" caps-line CR LF ) 155 rsp-code SP caps-line CR LF ) 157 rsp-code = "2" 2DIGIT 159 rcpt-response = 162 caps-line = [status-code SP] features-line CR LF 164 features-line = http-line / ( ttl-caps ttl-seconds ) 166 status-code = of section 4 of [SMTP-ENH-ERR] 167 if SMTP server implements [SMTP-ENH-ERR]> 169 http-line = 171 ttl-caps = "ttl=" ttl-seconds 172 ttl-seconds = 1*DIGIT 174 (XXX - ttl-caps and ttl-seconds aren't defined in [HTTP-NEG], but 175 they should probably be moved there, as they're more appropriate 176 there 178 The purpose of is to indicate how long the list of capabilties 179 should be considered an authoritative list of capabilities. The ttl is 180 decremented by the SMTP server for the length of time since the data 181 was last refreshed. A ttl of 0 indicates the capabilities list is 182 out-of-date but newer authoritative capabilities are not obtainable at 183 this time. ) 185 4.2. SMTP server unable to obtain capabilities 187 If the SMTP server receives a request for recipient capabilities but 188 cannot determine the capabilities of the recipient for some reason, the 189 SMTP server may reply with: 191 (1) ttl=0, or 192 (2) an expired capabilities list and ttl=0 194 This allows the SMTP client to: 196 (a) abort the transaction, or 197 (b) send whatever data it wishes (case 1, above), or 198 (c) send data meeting the capabilities listed in (case 2, above). 200 4.3. Behavior when client exceeds recipient's capabilities 202 The SMTP server MAY verify that the SMTP client did not exceed the 203 recipient capabilities advertised by the server. If the SMTP server 204 determines that the SMTP client exceeded the advertised capabilities, 205 the SMTP server can reject the message after the end-of-mail-data 206 indicator. See the discussion in section 2.4.1 in [SMTP-UPD] for more 207 information. 209 5. Examples 211 5.1. Simple capabilities exchange 213 S: 220 gw.cisco.com ESMTP service ready 214 C: EHLO joffe-pc.cisco.com 215 S: 250-gw.cisco.com says hello 216 S: 250 CAPABILITIES 217 C: MAIL FROM: 218 S: 250 sender okay 219 C: RCPT TO: CAPS 220 S: 250- recipient ok 221 S: 250-Accept: audio/basic 222 S: 250-Accept: text/* 223 S: 250-Accept: image/tiff;application=f, image/tiff;application=fx, 224 application/octet-stream; q=0.2 225 S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4 226 S: 250-Accept-Features: pix-x=1728, res=204x196 227 S: 250 ttl=500 228 C: DATA 229 S: 354 Send your data 230 ... 232 5.2. SMTP server isn't able to obtain capabilities for recipient 234 S: 220 gw.cisco.com SMTP service ready 235 C: EHLO wing-pc.cisco.com 236 S: 250-gw.cisco.com says hello 237 S: 250 CAPABILITIES 238 C: MAIL FROM: 239 S: 250 sender okay 240 C: RCPT TO: CAPS 241 S: 250 recipient ok 242 C: DATA 243 S: 354 Send your data 244 ... 246 5.3. SMTP server can only obtain expired capabilities information 248 S: 220 gw.cisco.com SMTP service ready 249 C: EHLO wing-pc.cisco.com 250 S: 250-gw.cisco.com says hello 251 S: 250 CAPABILITIES 252 C: MAIL FROM: 253 S: 250 sender okay 254 C: RCPT TO: 255 S: 250- recipient ok 256 S: 250-Accept: text/* 257 S: 250-Accept: application/ms-word, application/powerpoint 258 S: 250 ttl=0 259 C: DATA 260 S: 354 Send your data 261 ... 263 6. Security Considerations 265 As detailed in section 14 of [HTTP-NEG], Accept- headers, in particular 266 Accept-Language headers, may reveal information which the user would 267 rather keep private. For this reason it may be desirable to restrict 268 externally-accessible information on user preferences and capabilities. 270 7. Acknowledgments 272 This document was produced by work initially started in the Internet Fax 273 Working Group. 275 The authors would like to thank Graham Klyne (Integralis Ltd.) and 276 Larry Masinter (Xerox PARC) for their contributions to this work. 278 8. References 280 [ACAP] 281 J. Myers, C. Newman, "ACAP -- Application Configuration Access 282 Protocol", Internet Draft, Work in Progress, 283 draft-ietf-acap-spec-??.txt. 285 [ABNF] 286 D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: 287 ABNF", Internet Draft, Work in Progress, 288 draft-ietf-drums-abnf-??.txt. 290 [DIR-EMAIL] 291 B. Greenblatt, "Directory Entries From Email Address", Internet 292 Draft, Work in Progress, draft-greenblatt-defema-??.txt. 294 [DS-EMAIL] 295 P. Leach, "Locating DS Entries by E-mail Address", Internet 296 Draft, Work in Progress, draft-leach-asid-ds-email-??.txt. 298 [FAX-PROFILE] 299 ?, "FAX Profile for Internet Mail", Internet Draft, Work in 300 Progress, draft-ietf-fax-profile-??.txt 302 [FAX-REQ] 303 L. Masinter, "Requirements for Internet FAX", Internet Draft, 304 Work in Progress, draft-ietf-fax-requirements-??.txt. 306 [HTTP-1.1] 307 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 308 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 309 1997. 311 [HTTP-NEG] 312 K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP", 313 Internet Draft, Work In Progress, 314 draft-ietf-http-negotiation-??.txt. 316 [REQ] 317 S. Bradner, "Key words for use in RFCs to Indicate Requirement 318 Levels", BCP-14, RFC 2119, March 1997. 320 [SALUTATION] 321 The Salutation Consortium, "Salutation Architecture 322 Specification", December 1996. 324 [SMIME-40BIT] 325 Bruce Schneier, "Counterpane Systems Releases Windows 326 95-compatible S/MIME 40-bit RC2 Cracking ScreenSaver", 327 http://www.counterpane.com/smime.html. 329 [SMTP] 330 D. Crocker, "Standard for the Format of ARPA Internet Text 331 Messages", STD-10, RFC 822, August 1982. 333 [SMTP-EXT] 334 J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP 335 Service Extensions", STD-10, RFC 1869, November 1995. 337 [SMTP-UPD] 338 J. Klensin, D. Mann, "Simple Mail Transfer Protocol", Internet 339 Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt. 341 [SMTP-ENH-ERR] 342 N. Freed, "SMTP Service Extension for Returning Enhanced Error 343 Codes", RFC 2034, October 1996. 345 9. Author's Addresses 347 Dan Wing 348 Cisco Systems, Inc. 349 101 Cooper Street 350 Santa Cruz, CA 95060 USA 352 Phone: +1 408 457 5200 353 Fax: +1 408 457 5208 354 EMail: dwing@cisco.com 356 Neil Joffe 357 Cisco Systems, Inc. 358 170 West Tasman Drive 359 San Jose, CA 95134-1706 USA 361 Phone: +1 408 526 4000 362 Email: njoffe@cisco.com