The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry
draft-cridland-acap-vendor-registry-02

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry' to Proposed Standard

The IESG has approved the following document:

- 'The Internet Assigned Number Authority (IANA) Application 
   Configuration Access Protocol (ACAP) Vendor Subtrees Registry '
   <draft-cridland-acap-vendor-registry-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-cridland-acap-vendor-registry-02.txt

Ballot Text

Technical Summary

   ACAP specification (RFC 2244) includes the specification and creation of
   the ACAP Vendor Registry, and this registry has subsequently been
   reused by several specifications, including both IMAP ANNOTATE (RFC 5257)
   and IMAP METADATA (RFC 5464), and is proving to be a useful mechanism for
   namespacing various names to within a specific vendor's scope.

   This document updates the registry to reduce syntax ambiguities in the
   original specification, and dissociates the registry from the original document
   allowing for easier referencing.  It replaces section 7.4 and portions of
   section 4, particularly 4.3, of RFC 2244.

Working Group Summary

   This is not a WG document.

Document Quality

   Multiple non-ACAP related documents use the registry, including RFC 5258,
   RFC 5257 and RFC 5464.

Personnel

   Alexey Melnikov is the  Responsible Area Director.

RFC Editor Note

In Section 3.1, 2nd paragraph:

OLD:
   Therefore, this document allows only ASCII letters, digits, the
   hyphen, and space to be used (the <iana-vendor-tag> ABNF production
   in Section 3.2).

NEW:
   Therefore, this document allows only ASCII letters, digits, the
   hyphen, and space to be used in registrations (the <iana-vendor-tag> ABNF production
   in Section 3.2).

Please update the 2nd and 3rd paragraphs of 3.3 to read:

OLD:
   These names might be used in several protocols, and are reserved in
   all the relevant protocols, so "vendor.example" might be an ACAP
   dataset class name, and "/vendor/vendor.example" might be a tree of
   IMAP ANNOTATE entries.

   Example Ltd is free to use either "vendor.example", and group
   specific products under it using the relevant protocol's hierarchy -
   perhaps "/shared/vendor/vendor.example/product", or using more
   specific names, such as "/shared/vendor/vendor.example.product".

NEW:
   These names might be used in several protocols, and are reserved in
   all the relevant protocols, so "vendor.example" might be an ACAP [ACAP]
   dataset class name, and "/vendor/vendor.example" might be a tree of
   IMAP ANNOTATE entries [ANNOTATE].

   Example Ltd is free to use either "vendor.example", and group
   specific products under it using the relevant protocol's hierarchy -
   perhaps "/shared/vendor/vendor.example/product" annotation [ANNOTATE], or using more
   specific names, such as "/shared/vendor/vendor.example.product" annotation.

RFC Editor Note