Protocol Action: 'Internet Message Access Protocol (IMAP) - URL Access Identifier Extension' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Mon, 11 May 2009 18:06 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 381153A6E51; Mon, 11 May 2009 11:06:16 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Internet Message Access Protocol (IMAP) - URL Access Identifier Extension' to Proposed Standard
Message-Id: <20090511180617.381153A6E51@core3.amsl.com>
Date: Mon, 11 May 2009 11:06:17 -0700
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2009 18:06:17 -0000

The IESG has approved the following document:

- 'Internet Message Access Protocol (IMAP) - URL Access Identifier 
   Extension '
   <draft-ncook-urlauth-accessid-02.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ncook-urlauth-accessid-02.txt

Technical Summary

   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.

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.

Personnel

   Eric Burger is the document shepherd. Alexey Melnikov is the
   responsible Area Director.

RFC Editor Note

Please change the bullet list in Section 3 to read:

OLD:
   o  <access> identifier - The name of the application e.g. "stream"

   o  <access> identifier prefix - The name of the application e.g.
      "stream" followed by a "+" and then a userid.  For example
      "stream+testuser".
NEW:
   o  <access> identifier - The name of the application e.g. "exampleapp"

   o  <access> identifier prefix - The name of the application e.g.
      "exampleapp3" followed by a "+" and then a userid.  For example
      "exampleapp3+testuser".

   Note that an <access> identifier name can also be registered as 
   an <access> identifier prefix. However this would require 2 separare
   IANA registrations.


Please change the 1st sentence of the 2nd paragraph in Section 6 to read:

OLD:
   Access identifiers and prefixes MUST be specified in a standards
   track or IESG approved experimental RFC.
NEW:
   Access identifiers and prefixes MUST be registered using 
   the "IETF Review" policy (RFC 5226).


For sections 6.3-6.6 please add a reference to RFC 5092 as an additional
reference to this document.