Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2018-12-20
02 (System)
Received changes through RFC Editor sync (changed abstract to 'The existing IMAP URL specification (RFC 5092) lists several  identifiers and  identifier prefixes that …
Received changes through RFC Editor sync (changed abstract to 'The existing IMAP URL specification (RFC 5092) lists several  identifiers and  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  identifiers as well as an IANA mechanism to register new  identifiers for future applications.

This document updates RFC 5092. [STANDARDS-TRACK]')
2015-10-14
02 (System) Notify list changed from neil.cook@noware.co.uk, eburger@standardstrack.com, gparsons@nortel.com to eburger@standardstrack.com, gparsons@nortel.com
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-06-30
02 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-06-30
02 Cindy Morgan
[Note]: 'RFC 5593

Eric Burger is the document shepherd. This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' …
[Note]: 'RFC 5593

Eric Burger is the document shepherd. This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' added by Cindy Morgan
2009-06-29
02 (System) RFC published
2009-05-14
02 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-05-14
02 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-05-14
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-05-13
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-05-11
02 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-05-11
02 (System) IANA Action state changed to In Progress
2009-05-11
02 Amy Vezza IESG state changed to Approved-announcement sent
2009-05-11
02 Amy Vezza IESG has approved the document
2009-05-11
02 Amy Vezza Closed "Approve" ballot
2009-05-08
02 (System) Removed from agenda for telechat - 2009-05-07
2009-05-07
02 Cindy Morgan State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan
2009-05-07
02 (System) [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by IESG Secretary
2009-05-07
02 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-05-07
02 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-05-07
02 Tim Polk
[Ballot discuss]
Using "stream+testuser" as the example for  identifier prefix syntax in section
3.3 confused this reader... I was actually expecting to see two IANA …
[Ballot discuss]
Using "stream+testuser" as the example for  identifier prefix syntax in section
3.3 confused this reader... I was actually expecting to see two IANA registration templates,
or one template that indicated stream was a dual type (access identifier and access identifier
prefix).  I now gather from section 6 that "stream" is not used with the prefix notation...

I would suggest changing the example to "user+testuser", and adding text that
clearly indicates whether an identifier can have only one type or can have dual types.
2009-05-07
02 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-05-07
02 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-05-07
02 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-05-07
02 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-05-07
02 Pasi Eronen [Ballot comment]
2009-05-07
02 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-05-07
02 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2009-05-07
02 Jari Arkko
[Ballot comment]
The text "and should be taken as the master in the event of any differences or discrepancies" sounds a bit weird, we do …
[Ballot comment]
The text "and should be taken as the master in the event of any differences or discrepancies" sounds a bit weird, we do not usually emphasize that for updates relationship, as its so clear. Or maybe I'm reacting to the word "master". I'd just delete the text.
2009-05-06
02 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-05-06
02 Alexey Melnikov State Change Notice email list have been change to neil.cook@noware.co.uk, eburger@standardstrack.com, gparsons@nortel.com from neil.cook@noware.co.uk, draft-ncook-urlauth-accessid@tools.ietf.org
2009-05-05
02 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-05-05
02 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-05-05
02 Lisa Dusseault
[Ballot comment]
The URLAUTH RFC says:
  "The URLAUTH component overrides the second purpose of the enc-user in
  the IMAP URI and by default …
[Ballot comment]
The URLAUTH RFC says:
  "The URLAUTH component overrides the second purpose of the enc-user in
  the IMAP URI and by default permits the URI to be resolved by any
  user permitted by the  identifier."

The 'stream' value doesn't seem to fit this definition, because 'stream' doesn't identify a user or a class of users.  Since this draft is updating RFC5092, it would be appropriate (though a little obsessive) to update the definition given above with a new one. 

Since this has been discussed in LEMONADE where URLAUTH mostly originated, I'm making this a COMMENT and don't object to the approach taken.
2009-05-05
02 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-05-05
02 Pasi Eronen
[Ballot comment]
Couple of minor suggestions:

I would recommend using the "IETF Review" policy [RFC5226] in Section 6
(the current rules e.g. exclude …
[Ballot comment]
Couple of minor suggestions:

I would recommend using the "IETF Review" policy [RFC5226] in Section 6
(the current rules e.g. exclude IESG-approved informational RFCs,
which sounds a bit strange).

Many of the registration templates in Section 6.x should probably have
5092 instead of (or in addition to) "This RFC" in the "RFC number"
field.
2009-05-05
02 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-05-05
02 Russ Housley
[Ballot discuss]
DISCUSS DISCUSS: Sections 6.2-6.5 specify the WG mail list as the
  contact for the registrations.  Will this list still be open when …
[Ballot discuss]
DISCUSS DISCUSS: Sections 6.2-6.5 specify the WG mail list as the
  contact for the registrations.  Will this list still be open when
  the WG is closed?
2009-05-05
02 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-05-04
02 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-05-04
02 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-04-27
02 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2009-04-27
02 Alexey Melnikov Ballot has been issued by Alexey Melnikov
2009-04-27
02 Alexey Melnikov Created "Approve" ballot
2009-04-27
02 Alexey Melnikov State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Alexey Melnikov
2009-04-24
02 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-04-20
02 Amanda Baber
IANA comments:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: URLAUTH Access Identifiers
Allocation Procedures: Standards Track or …
IANA comments:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: URLAUTH Access Identifiers
Allocation Procedures: Standards Track or IESG-Approved
Experimental RFC

Initial contents of this registry will be:

Type:  identifier
Application: stream
Description: Used by SIP Media Servers to retrieve
attachments for streaming to email
clients
RFC Number: [RFC-ncook-urlauth-accessid-02]
Contact: mailto:neil.cook@noware.co.uk

Type:  identifier prefix
Application: submit
Description: Used by message submission entities to
retrieve attachments to be included in
submitted messages
RFC Number: [RFC-ncook-urlauth-accessid-02]
Contact: Lemonade WG mailto:lemonade@ietf.org

Type:  identifier prefix
Application: user
Description: Used to restrict access to to IMAP sessions
that are logged in as the specified userid
RFC Number: [RFC-ncook-urlauth-accessid-02]
Contact: Lemonade WG mailto:lemonade@ietf.org

Type:  identifier
Application: authuser
Description: Used to restrict access to to IMAP sessions
that are logged in as any non-anonymous
user of that IMAP server
RFC Number: [RFC-ncook-urlauth-accessid-02]
Contact: Lemonade WG mailto:lemonade@ietf.org

Type:  identifier
Application: anonymous
Description: Indicates that use of this URL is
not restricted by session authorization
identity
RFC Number: [RFC-ncook-urlauth-accessid-02]
Contact: Lemonade WG mailto:lemonade@ietf.org

We understand the above to be the only IANA Action for this document.
2009-04-17
02 Alexey Melnikov
(1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
  …
(1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this  version of the document, and it is ready for forwarding to the IESG  for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document is an individual submission.  However, the LEMONADE Work  Group performed an open pseudo-last call review, including expert  review by Alexey Melnikov, Dave Cridland, and Arnt Gulbrandsen.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

None.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document,  or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

None.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Strong consensus for publishing.  This is a small update to URLAUTH  (RFC 5092).

    (1.f) Has anyone threatened an appeal or otherwise indicated  extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

None.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Checked with ID nits 2.11.07.  As this document incorporates some RFC  5092 text, the pre-RFC 5378 disclaimer is appropriate.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits the references. All Normative References are at  least Proposed Standard.  The Informative Reference is the Lemonade  streaming draft, which has a Normative Reference on this document.  Thus we hope to progress both documents at the same time.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes, and we have already had an IANA review.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

ABNF validated with Bill's ABNF Parser

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary

The existing IMAP URL specification (RFC 5092) lists several 
identifiers and  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  identifiers
as well as an IANA mechanism to register new  identifiers  for
future applications.

This document updates RFC 5092.

          Working Group Summary
Nothing out of the ordinary happened in the WG to note.

          Document Quality
This document received LEMONADE work group review and expert review.
2009-04-17
02 Alexey Melnikov Placed on agenda for telechat - 2009-05-07 by Alexey Melnikov
2009-04-17
02 Alexey Melnikov
[Note]: 'Eric Burger is the document shepherd. This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' added by …
[Note]: 'Eric Burger is the document shepherd. This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' added by Alexey Melnikov
2009-04-17
02 Alexey Melnikov Area acronymn has been changed to app from gen
2009-04-03
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vidya Narayanan
2009-04-03
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vidya Narayanan
2009-03-27
02 Alexey Melnikov
[Note]: 'Eric Burger is the document shepherd.

This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' added by …
[Note]: 'Eric Burger is the document shepherd.

This document is a Normative dependency for a Lemonade WG document, updating another Lemonade document.
' added by Alexey Melnikov
2009-03-27
02 Cindy Morgan Last call sent
2009-03-27
02 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-03-27
02 Alexey Melnikov State Changes to Last Call Requested from AD Evaluation by Alexey Melnikov
2009-03-27
02 Alexey Melnikov Last Call was requested by Alexey Melnikov
2009-03-27
02 (System) Ballot writeup text was added
2009-03-27
02 (System) Last call text was added
2009-03-27
02 (System) Ballot approval text was added
2009-03-27
02 Alexey Melnikov State Changes to AD Evaluation from Publication Requested by Alexey Melnikov
2009-03-27
02 Alexey Melnikov State Changes to Publication Requested from AD is watching by Alexey Melnikov
2009-03-27
02 Alexey Melnikov [Note]: 'Eric Burger is the document shepherd.
' added by Alexey Melnikov
2009-03-26
02 Alexey Melnikov Draft Added by Alexey Melnikov in state AD is watching
2009-03-26
02 (System) New version available: draft-ncook-urlauth-accessid-02.txt
2009-01-21
01 (System) New version available: draft-ncook-urlauth-accessid-01.txt
2008-12-08
00 (System) New version available: draft-ncook-urlauth-accessid-00.txt