datatracker.ietf.org
Sign in
Version 5.6.2.p3, 2014-07-31
Report a bug

Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
RFC 5593

Network Working Group                                            N. Cook
Request for Comments: 5593                                     Cloudmark
Updates: 5092                                                  June 2009
Category: Standards Track

               Internet Message Access Protocol (IMAP) -
                    URL Access Identifier Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The existing IMAP URL specification (RFC 5092) lists several <access>
   identifiers and <access> identifier prefixes that can be used to
   restrict access to URLAUTH-generated URLs.  However, these
   identifiers do not provide facilities for new services such as
   streaming.  This document proposes a set of new <access> identifiers
   as well as an IANA mechanism to register new <access> identifiers for
   future applications.

   This document updates RFC 5092.

Cook                        Standards Track                     [Page 1]
RFC 5593               IMAP URL Access Identifier              June 2009

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. Additional Authorized Access Identifiers ........................3
      3.1. Existing Access Identifiers ................................3
      3.2. Requirement for Additional Access Identifiers ..............3
      3.3. Additional Access Identifier Specification .................4
      3.4. Defining an Access Identifier for Streaming ................5
   4. Formal Syntax ...................................................5
   5. Acknowledgements ................................................6
   6. IANA Considerations .............................................6
      6.1. Access Identifier Registration Template ....................7
      6.2. Stream Application Registration ............................7
      6.3. Submit Application Registration ............................8
      6.4. User Application Registration ..............................8
      6.5. Authuser Application Registration ..........................9
      6.6. Anonymous Application Registration .........................9
   7. Security Considerations .........................................9
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10

1.  Introduction

   The IMAP URL specification [RFC5092] provides a way to carry
   authorization information in IMAP URLs.  Several authorization
   <access> identifiers are specified in the document that allow
   URLAUTH-authorized URLs to be used only by anonymous users,
   authenticated users, or message submission entities.  However, there
   is no mechanism defined to create new <access> identifiers, and
   overloading the existing mechanisms has security as well as
   administrative implications.

   This document describes a new <access> identifier, "stream", to be
   used by message streaming entities (as described in [STREAMING]), and
   defines an IANA registration template, which can be used to register
   new <access> identifiers for future applications.  IANA definitions
   for the existing access identifiers and prefixes from RFC 5092 are
   also defined in this document -- this document updates RFC 5092 and
   should be taken as the master in the event of any differences or
   discrepancies.

2.  Conventions Used in This Document

   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].

Cook                        Standards Track                     [Page 2]

[include full document text]