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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
