idnits 2.17.1 draft-earhart-url-smtp-00.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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Introduction section. ** 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 2 characters in excess of 72. 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 (December 1997) is 9629 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1738 (ref. 'BASIC-URL') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2192 (ref. 'IMAP-URL') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2245 (ref. 'SASL-ANON') (Obsoleted by RFC 4505) ** Obsolete normative reference: RFC 2044 (ref. 'UTF8') (Obsoleted by RFC 2279) Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Earhart 3 Internet Draft: URL-SMTP Carnegie Mellon 4 Document: draft-earhart-url-smtp-00.txt December 1997 5 Expires June 1997 7 An SMTP URL Interface 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. and may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 This document suggests a proposed protocol for the Internet 29 community, and requests discussion and suggestions for improvements. 30 Distribution of this draft is unlimited. 32 The protocol discussed in this document is experimental and subject 33 to change. Persons planning on either implementing or using this 34 protocol are STRONGLY URGED to get in touch with the author before 35 embarking on such a project. 37 Abstract 39 It is occasionally useful to be able to reference a generic server to 40 be used for message submission. URLs provide a good mechanism for 41 refering to arbitrary network resources. The SMTP URL scheme allows 42 a URL to specify an SMTP server, thus allowing other protocols to use 43 a general ''URL to be used for message delivery'' in place of an 44 explicit reference to SMTP. 46 Internet DRAFT An SMTP URL Interface December 15, 1997 48 1. Conventions Used in this Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [KEYWORDS]. 54 2. SMTP URL Scheme 56 The SMTP URL follows the common Internet scheme syntax as defined in 57 [BASIC-URL] except that plaintext passwords are not permitted. If 58 : is omitted, the port defaults to 25. 60 The specified server should not be assumed to have any services 61 available other than SMTP. Other than authentication, no protocol 62 actions are implied by an SMTP URL; an SMTP URL only specifies the 63 location of an SMTP service, not what to do with it (common actions 64 are to use the SMTP server to verify an address, and to submit 65 Internet mail). 67 An SMTP URL has the following general form: 69 url-smtp = "smtp://" url-server 71 "smtp" refers to the URL scheme; "://" is used to indicate a 72 reference to an Internet host address. The element 73 includes the hostname, and optional user name, authentication 74 mechanism and port number. 76 Note that unsafe or reserved characters such as " " or "?" MUST be 77 hex encoded as described in the URL specification [BASIC-URL]. Hex 78 encoded octets are interpreted according to UTF-8 [UTF8]. 80 3. SMTP URL User Name and Authentication Mechanism 82 A user name and/or authentication mechanism may be supplied. They 83 are used to perform SASL [SASL] authentication after making the 84 connection to the SMTP server. If no user name or authentication 85 mechanism is supplied, then the SASL ANONYMOUS [SASL-ANON] mechanism 86 is used by default. If an authentication mechanism is supplied 87 without a user name, then one SHOULD be obtained from the specified 88 mechanism or requested from the user as appropriate. If a user name 89 is supplied without an authentication mechanism then ";AUTH=*" is 90 assumed. 92 The ";AUTH=" authentication parameter is interpreted as described in 93 the IMAP URL Scheme [IMAP-URL]. 95 Internet DRAFT An SMTP URL Interface December 15, 1997 97 Note that if unsafe or reserved characters such as " " or ";" are 98 present in the user name or authentication mechanism, they MUST be 99 encoded as described in the URL specification [BASIC-URL]. 101 4. Formal Syntax 103 The following syntax specification uses the augmented Backus-Naur 104 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 105 rules as specified in Appendix A of the ABNF specification [ABNF]. 107 Except as noted otherwise, all alphabetic characters are case- 108 insensitive. The use of upper or lower case characters to define 109 token strings is for editorial clarity only. Implementations MUST 110 accept these strings in a case-insensitive fashion. 112 url-auth = ";AUTH=" ("*" / url-enc-auth) 114 url-achar = uchar / "&" / "=" / "~" 115 ;; See [BASIC-URL] for definition of "uchar" 117 url-enc-auth = 1*url-achar 118 ;; encoded version of auth-type-name above 120 url-enc-user = *url-achar 121 ;; encoded version of login userid 123 url-server = [url-enc-user [url-auth] "@"] hostport 124 ;; See [BASIC-URL] for definition of "hostport" 126 url-smtp = "smtp://" url-server 128 5. Security Considerations 130 SMTP URLs have the same security considerations as IMAP URLs [IMAP- 131 URL]. 133 Clients SHOULD make the SMTP URL being used obvious to the user, as 134 using an undesireable server may compromise the security of the 135 user's message. 137 Internet DRAFT An SMTP URL Interface December 15, 1997 139 6. Copyright 141 Copyright (C) The Internet Society 1997. All Rights Reserved. 143 This document and translations of it may be copied and furnished to 144 others, and derivative works that comment on or otherwise explain it 145 or assist in its implementation may be prepared, copied, published 146 and distributed, in whole or in part, without restriction of any 147 kind, provided that the above copyright notice and this paragraph are 148 included on all such copies and derivative works. However, this 149 document itself may not be modified in any way, such as by removing 150 the copyright notice or references to the Internet Society or other 151 Internet organizations, except as needed for the purpose of 152 developing Internet standards in which case the procedures for 153 copyrights defined in the Internet Standards process must be 154 followed, or as required to translate it into languages other than 155 English. 157 The limited permissions granted above are perpetual and will not be 158 revoked by the Internet Society or its successors or assigns. 160 This document and the information contained herein is provided on an 161 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 162 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 163 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 164 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 165 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 167 7. References 169 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 170 ABNF", RFC 2234, November 1997. 172 174 [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource 175 Locators (URL)", RFC 1738, December 1994. 177 179 [IMAP-URL] Newman, "IMAP URL Scheme", RFC 2192, July 1997. 181 183 Internet DRAFT An SMTP URL Interface December 15, 1997 185 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 190 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 191 2222, October 1997. 193 195 [SASL-ANON] Newman, "Anonymous SASL Mechanism", RFC 2245, November 196 1997. 198 200 [UTF8] Yergeau, "UTF-8, a transformation format of Unicode and ISO 201 10646", RFC 2044, October 1996. 203 205 8. Author's Address 207 Robert H. Earhart 208 Carnegie Mellon 209 5000 Forbes Ave. 210 Pittsburgh PA, 15213-3890 212 Email: earhart+@cmu.edu 214 Expires June 1997