idnits 2.17.1 draft-gellens-pop-url-01.txt: 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 6 months document validity. ** 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 Abstract 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 are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (12 February 1998) is 9569 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 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) -- Possible downref: Non-RFC (?) normative reference: ref. 'POP-AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'URL-GUIDELINES' ** Obsolete normative reference: RFC 2044 (ref. 'UTF8') (Obsoleted by RFC 2279) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: POP URL Scheme R. Gellens 2 Document: draft-gellens-pop-url-01.txt QUALCOMM, Incorporated 3 Expires: 12 August 1998 12 February 1998 5 POP URL Scheme 7 Status of this Memo: 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 "working draft" or "work in progress." 20 To learn the current status of any Internet Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 22 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 A version of this draft document is intended for submission to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. 30 1. Introduction 32 [POP3] is a widely-deployed mail access protocol. Many programs 33 access POP3 message stores, and thus need POP3 configuration 34 information. Since there are multiple configuration elements which 35 are required in order to access a mailbox, a single string 36 representation is convenient. 38 A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and 39 URLs are a widely-supported generalized representation of network 40 resources. 42 A means of specifying a POP3 mailbox as a URL will likely be useful 43 in many programs and protocols. [ACAP] is one case where a string 44 encapsulation of elements required to access network services is 45 needed. For example, an [IMAP4] message store is usually specified 46 in ACAP datasets as an [IMAP-URL]. 48 This memo defines a URL scheme for referencing a POP mailbox. 50 2. Conventions Used in this Document 52 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 53 in this document are to be interpreted as defined in "Key words for 54 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 56 3. POP Scheme 58 The POP URL scheme designates a POP server, and optionally a port 59 number, authentication mechanism, authentication ID, and/or 60 authorization ID. 62 The POP URL follows the common Internet scheme syntax as defined in 63 RFC 1738 [BASIC-URL] except that clear text passwords are not 64 permitted. If : is omitted, the port defaults to 110. 66 The POP URL is described using [ABNF] in Section 8. 68 A POP URL is of the general form: 70 pop://;auth=@: 72 Where , , and are as defined in RFC 1738, and 73 some or all of the elements, except "pop:" and , may be 74 omitted. 76 4. POP User Name and Authentication Mechanism 78 An authorization (which mailbox to access) and authentication 79 (whose password to check against) identity (referred to as "user 80 name" for simplicity) and/or authentication mechanism name may be 81 supplied. These are used in the "USER", "APOP", or "AUTH" 82 [POP-AUTH] commands after making the connection to the POP server. 83 If the URL doesn't supply an authentication identifier, the program 84 interpreting the POP URL SHOULD request one from the user. 86 An authentication mechanism can be expressed by adding 87 ";AUTH=" to the end of the user name. If the 88 authentication mechanism is not "APOP", it is a SASL POP [POP-AUTH] 89 mechanism. When such an is indicated, the client 90 SHOULD request appropriate credentials from that mechanism and use 91 the "AUTH" or "APOP" commands instead of the "USER" command. If no 92 user name is specified, one SHOULD be obtained from the mechanism 93 or requested from the user as appropriate. 95 The string ";AUTH=*" indicates that the client SHOULD select an 96 appropriate authentication mechanism. It MAY use any mechanism 97 supported by the POP server. 99 If a user name is included with no authentication mechanism, then 100 ";AUTH=*" is assumed. 102 Since URLs can easily come from untrusted sources, care must be 103 taken when resolving a URL which requires or requests any sort of 104 authentication. If authentication credentials are supplied to the 105 wrong server, it may compromise the security of the user's account. 106 The program resolving the URL should make sure it meets at least 107 one of the following criteria in this case: 109 (1) The URL comes from a trusted source, such as a referral server 110 which the client has validated and trusts according to site policy. 111 Note that user entry of the URL may or may not count as a trusted 112 source, depending on the experience level of the user and site 113 policy. 115 (2) Explicit local site policy permits the client to connect to the 116 server in the URL. For example, if the client knows the site 117 domain name, site policy may dictate that any hostname ending in 118 that domain is trusted. 120 (3) The user confirms that connecting to that domain name with the 121 specified credentials and/or mechanism is permitted. 123 (4) A mechanism is used which validates the server before passing 124 potentially compromising client credentials. 126 (5) An authentication mechanism is used which will not reveal 127 information to the server which could be used to compromise future 128 connections. 130 A URL containing ";AUTH=*" should be treated with extra care since 131 it might fall back on a weaker security mechanism. Finally, clients 132 are discouraged from using a plain text password as a fallback with 133 ";AUTH=*" unless the connection has strong encryption (e.g., a key 134 length of greater than 56 bits). 136 Note that if unsafe or reserved characters such as " " or ";" are 137 present in the user name or authentication mechanism, they MUST be 138 encoded as described in RFC 1738 [BASIC-URL]. 140 5. Relative POP URLs 142 Relative POP URLs are not permitted. 144 6. Multinational Considerations 146 Since 8-bit characters are not permitted in URLs, [UTF8] characters 147 are encoded as required by the URL specification [BASIC-URL]. 149 7. Examples 151 The following examples demonstrate how a POP client program might 152 translate various POP URLs into a series of POP commands. Commands 153 sent from the client to the server are prefixed with "C:", and 154 responses sent from the server to the client are prefixed with 155 "S:". 157 The URL: 159 161 Results in the following client commands: 163 164 165 S: +OK POP3 server ready <1896.697170952@mailsrv.qualcomm.com> 166 C: USER rg 167 S: +OK 168 C: PASS secret 169 S: +OK rg's mailbox has 2 messages (320 octets) 171 The URL: 173 175 Results in the following client commands: 177 178 179 S: +OK POP3 server ready <1896.697170952@mail.eudora.com> 180 C: APOP rg c4c9334bac560ecc979e58001b3e22fb 181 S: +OK mailbox has 1 message (369 octets) 183 The URL: 185 187 Results in the following client commands: 189 190 S: +OK POP3 server ready <1896.697170952@foo.bar> 191 C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW 192 Fub3IuaW5ub3NvZnQuY29tPg== 193 S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq 194 aGNOWmxSdVBiemlGcCt2TFYrTkN3 196 C: AQAAAMg9jU8CeB4KOfk7sUhSQPs= 197 S: + U0odqYw3B7XIIW0oSz65OQ== 198 C: 199 S: +OK mailbox has 1 message (369 octets) 201 8. ABNF for POP URL scheme 203 The POP URL scheme is described using [ABNF]: 205 achar = uchar / "&" / "=" / "~" 206 ; see [BASIC-URL] for "uchar" definition 208 auth = ";AUTH=" ( "*" / enc_auth_type ) 210 enc_auth_type = 1*achar 211 ; encoded version of [POP-AUTH] "auth_type" 213 enc_user = 1*achar 214 ; encoded version of [POP3] mailbox 216 popurl = "pop://" server 218 server = [userauth "@"] hostport 219 ; See [BASIC-URL] for "hostport" definition 221 userauth = enc_user [auth] 223 9. Security Considerations 225 Security considerations discussed in the [POP3] specification and 226 the [BASIC-URL] specification are relevant. Security 227 considerations related to authenticated URLs are discussed in 228 section 4 of this document. 230 Many email clients store the plain text password for later use 231 after logging into a POP server. Such clients MUST NOT use a 232 stored password in response to a POP URL without explicit 233 permission from the user to supply that password to the specified 234 host name. 236 10. Acknowledgements 238 This document borrows heavily from Chris Newman's [IMAP-URL] 239 specification, and has attempted to follow the advice in 240 [URL-GUIDELINES]. 242 11. References 244 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 245 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 246 November 1997. 248 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 249 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 250 252 [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource 253 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 254 Minnesota, December 1994. 256 [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, 257 September 1997. 259 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 260 4rev1", RFC 2060, University of Washington, December 1996. 261 263 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 264 Requirement Levels", RFC 2119, Harvard University, March 1997. 265 267 [POP-AUTH] Myers, J., "POP3 AUTHentication command", Netscape 268 Communications, November 1997, work in progress. 269 271 [POP3] Myers, J., Rose, M., "Post Office Protocol -- Version 3", 272 RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 273 275 [URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new 276 URL Schemes", Xerox Corporation, UNINETT A/S, Wink Communications, 277 work in progress, December 1997. 278 280 [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and 281 ISO 10646", RFC 2044, Alis Technologies, October 1996. 282 284 12. Author's Address 286 Randall Gellens +1 619 651 5115 287 QUALCOMM, Incorporated +1 619 651 5334 (fax) 288 6455 Lusk Blvd. Randy@Qualcomm.Com 289 San Diego, CA 92121-2779 290 U.S.A.