Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
draft-ncook-urlauth-accessid-02

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]')

[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

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

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

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

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

[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?

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.

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

[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

[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