INTERNET-DRAFT                                            M. Yevstifeyev
Intended Status: Standards Track
Expires: September 10, 2011                                  A. Melnikov
                                                           Isode Limited
                                                           March 9, 2011

                         The 'pops' URI Scheme
                 <draft-yevstifeyev-pops-uri-scheme-02>

Abstract

   This document specifies the 'pops' URI scheme, that is used to
   designate the access to POP3 mailboxes over TLS, and the procedure
   the user agent should follow using it - POP3 over TLS transport
   binding.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents



Yevstifeyev & Melnikov Expires September 10, 2011               [Page 1]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
      1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The 'pops' URI Scheme . . . . . . . . . . . . . . . . . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
      5.1.  Normative References . . . . . . . . . . . . . . . . . . . 8
      5.2.  Informative References . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
































Yevstifeyev & Melnikov Expires September 10, 2011               [Page 2]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


1.  Introduction

   The Post Office Protocol, Version 3 (POP3), that is defined in RFC
   1939 [RFC1939], is an application-layer protocol used by local e-mail
   clients to retrieve e-mail from a remote server over a simple TCP/IP
   connection.  However since the time of appearance of this protocol,
   it has been widely implemented over Transport Layer Security (TLS)
   [RFC5246] and its deprecated predecessor Secure Sockets Layer (SSL).

   RFC 2384 [RFC2384] already defines the Uniform Resource Identifier
   (URI) 'pop' scheme that is used for referencing the POP3 mailboxes.
   However this scheme supports only usual POP3 over TCP [RFC793]
   operations; not aforementioned POP3 over TLS binding.  This document
   specifies the URI scheme used for referencing the POP3 mailboxes that
   are available using POP3 over TLS connection and the procedure the
   user agent should follow when using this scheme - POP3 over TLS
   transport binding.

   Generic URI syntax is described in RFC 3986 [RFC3986].  Procedures
   for registration of new URI schemes are defined in RFC 4395
   [RFC4395].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
























Yevstifeyev & Melnikov Expires September 10, 2011               [Page 3]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


2.  The 'pops' URI Scheme

   The 'pops' URI scheme is used to designate the access to POP3
   [RFC1939] mailboxes over secure TLS connection, as described below.
   The user agent, using 'pops' URI scheme SHALL: request the password
   (and user name, if not given in the URI) in the case this is required
   by the used authentication method; establish the TCP [RFC793]
   connection to the TCP port, given in URI (or 995, if not given
   there), of the endpoint, identified as <host> in the URI; perform the
   TLS handshake, as described in RFC 5246 [RFC5246] (all data now SHALL
   be sent under TLS layer); open the POP3 transaction and authenticate
   itself using the chosen authentication method using the credentials
   requested before; begin exchanging POP3 commands and responses.  This
   procedure is called POP3 over TLS transport binding.

   There is already the 'pop' URI scheme used for referencing the POP3
   mailboxes over usual TCP connection [RFC2384].  Since the 'pops' URI
   scheme defined by this document is used to provide the access to the
   same resources as 'pop' one (i. e. POP3 mailboxes), only using
   different connections, the syntax of these schemes are the same
   either, except the 'scheme' part.  The 'pops' URI is described using
   Augmented Backus-Naur Form (ABNF) [RFC5234] as follows:

   pops-uri    = pops-scheme ":" pops-hier-part
   pops-scheme = "pops"
   pops-hier-part = "//" [user-auth "@"] host [":" port] ["/"]
   user-auth   = user [auth]
   user        = 1*achar
   auth        = ";AUTH=" ("*" / auth-type)
   auth-type   = auth-sasl / auth-ext
   auth-sasl   = 1*achar
   auth-ext    = "+" ("APOP" / 1*achar)
   achar       = ALPHA / DIGIT / pct-encoded / "$" / "-" / "_" / "."
                / "+" / "!" / "'" / "(" / ")" / "," / "=" / "*" / "~"
                / "&"

   The <host>, <port> and <pct-encoded> rules are described in
   Appendix A of RFC 3986 [RFC3986].  The core rules <ALPHA> and <DIGIT>
   are used as described in Appendix B of RFC 5234 [RFC5234].

     Note: The <achar> rule contains the <userinfo> production of RFC
     3986 [RFC3986] except the ";" character.  This is made in order not
     to create confusion with <auth> part, that uses ";" as the
     delimiter.

   If <port> part is omitted, it SHALL default to 995.  If the
   characters, not listed in the <achar> rule, appear in the <user>
   part, they MUST be percent-encoded.  The final character "/" MAY be



Yevstifeyev & Melnikov Expires September 10, 2011               [Page 4]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


   omitted.

   The <auth> part of the 'pops' URIs allows to choose what
   authentication mechanism will be used after the establishing the
   connection.  The ";AUTH=*" assumes that no special authentication
   mechanism SHOULD be used - i. e. the user name and password SHOULD be
   transmitted via the USER and PASS commands, respectively.  If another
   authentication type is assumed, it SHOULD be used after the
   establishing the connection, as described below.

   If the <auth-type> part does not starts with "+", the Simple
   Authentication and Security Layer (SASL) [RFC4422] SHOULD be used for
   authentication.

   If the <auth-type> part starts with "+", that APOP or other specified
   external authentication mechanism SHOULD be assumed to be used.

   Please note that the user agent MAY use another authentication
   mechanism than defined in the 'pops' URI if it is properly set.
































Yevstifeyev & Melnikov Expires September 10, 2011               [Page 5]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


3.  Security Considerations

   Generic security considerations for the usage of URIs are discussed
   in Section 7 of RFC 3986 [RFC3986].

   The 'pops' URI designates the secure TLS connection for POP3
   transaction.  Moreover, it allows to choose what authentication
   mechanism SHOULD be used for user authentication over such
   connection.

   More security issues may be added by other authentication mechanisms
   for POP3.  These mechanism are not discussed by this memo.







































Yevstifeyev & Melnikov Expires September 10, 2011               [Page 6]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


4.  IANA Considerations

   IANA is asked to register the 'pops' URI scheme using the following
   template (see RFC 4395 [RFC4395]):

     URI scheme name: pops

     Status: Permanent

     URI scheme syntax: see Section 2 of RFC xxxx

     URI scheme semantics: see Section 2 of RFC xxxx

     URI scheme encoding considerations: Generic encoding considerations
     for URI schemes, defined in Section 2 of [RFC3986], concern 'pops'
     one as well.  Non-ASCII characters are to be mapped as defined in
     Section 3.1 of RFC 3987 [RFC3987].  Note that there are the
     restrictions for usage of some characters in the <user> part of the
     URI - see Section 2

     Protocols that use the scheme: POP3 over TLS connections, as
     described in RFC xxxx

     Security considerations: see Section 3 of RFC xxxx

     Contact: IESG <iesg@ietf.org>

     Author/Change controller: IETF <ietf@ietf.org>

     References: see Section 5 of RFC xxxx

   [RFC Editor: Replace xxxx with assigned RFC number]



















Yevstifeyev & Melnikov Expires September 10, 2011               [Page 7]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


5.  References

5.1.  Normative References

   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC1939]   Myers, J. and M. Rose, "Post Office Protocol - Version
               3", STD 53, RFC 1939, May 1996.

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66, RFC
               3986, January 2005.

   [RFC3987]   Duerst, M. and M. Suignard, "Internationalized Resource
               Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4422]   Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
               Authentication and Security Layer (SASL)", RFC 4422, June
               2006.

   [RFC5234]   Crocker, D., Ed., and P. Overell, "Augmented BNF for
               Syntax Specifications: ABNF", STD 68, RFC 5234, January
               2008.

   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.2", RFC 5246, August 2008.

5.2.  Informative References

   [RFC2384]   Gellens, R., "POP URL Scheme", RFC 2384, August 1998.

   [RFC4395]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
               Registration Procedures for New URI Schemes", BCP 35, RFC
               4395, February 2006.













Yevstifeyev & Melnikov Expires September 10, 2011               [Page 8]


INTERNET DRAFT           The 'pops' URI Scheme             March 9, 2011


Appendix A.  Acknowledgments

   Many thanks to /TBD/ for their input to this document.


Authors' Addresses

   Mykyta Yevstifeyev
   8 Kuzovkov St., flat 25,
   Kotovsk
   Ukraine

   EMail: evnikita2@gmail.com


   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: Alexey.Melnikov@isode.com




























Yevstifeyev & Melnikov Expires September 10, 2011               [Page 9]