Skip to main content

The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry
RFC 6075

Revision differences

Document history

Date Rev. By Action
2015-10-14
02 (System) Notify list changed from dave.cridland@isode.com to (None)
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Gonzalo Camarillo
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2010-12-13
02 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2010-12-13
02 Cindy Morgan [Note]: 'RFC 6075' added
2010-12-13
02 (System) RFC published
2010-11-03
02 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-11-03
02 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-11-03
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-11-02
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-10-26
02 (System) IANA Action state changed to In Progress
2010-10-25
02 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-10-25
02 Amy Vezza IESG state changed to Approved-announcement sent
2010-10-25
02 Amy Vezza IESG has approved the document
2010-10-25
02 Amy Vezza Closed "Approve" ballot
2010-10-25
02 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-10-22
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-10-22
02 (System) New version available: draft-cridland-acap-vendor-registry-02.txt
2010-10-22
02 Alexey Melnikov State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Alexey Melnikov
2010-10-22
02 (System) Removed from agenda for telechat - 2010-10-21
2010-10-21
02 David Harrington [Ballot comment]
with the RFC Editor note, I am satisfied.
2010-10-21
02 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington
2010-10-21
02 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan
2010-10-21
02 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-10-21
02 Gonzalo Camarillo [Ballot Position Update] Position for Gonzalo Camarillo has been changed to No Objection from Discuss by Gonzalo Camarillo
2010-10-21
02 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss by Peter Saint-Andre
2010-10-21
02 Dan Romascanu [Ballot comment]
I support the DISCUSSes from David and Peter.
2010-10-21
02 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-10-21
02 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner
2010-10-21
02 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-10-20
02 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-10-20
02 Peter Saint-Andre
[Ballot discuss]
1. It would be helpful to justify more fully why this specification is restricting vendor tokens to "ASCII letters, digits, the
hyphen, and …
[Ballot discuss]
1. It would be helpful to justify more fully why this specification is restricting vendor tokens to "ASCII letters, digits, the
hyphen, and space". The text that Chris Newman provided would meet that need.

2. The iana-vendor-tag production is described as representing "allowed forms for current registrations". Is this production  intended to describe (a) only the registrations currently found at  or (b) any registration that would be allowed by the registration process specified in this document? I think it is (b), but it reads like (a).

3. I agree with David Harrington that the examples are confusing, in that they liberally include the forbidden '/' character; either we could change the examples or we could more clearly explain what the vendor token is in each example (perhaps by means of the concept of a "vendor-token slot", similar to the "domain name slot" from RFC 5890).

4. The phrase "UTF-8 names are restricted to ASCII" sounds paradoxical; I suggest instead "Vendor tokens are restricted to ASCII for registration purposes" or somesuch.
2010-10-20
02 Peter Saint-Andre
[Ballot discuss]
1. It would be helpful to justify more fully why this specification is restricting vendor tokens to "ASCII letters, digits, the
hyphen, and …
[Ballot discuss]
1. It would be helpful to justify more fully why this specification is restricting vendor tokens to "ASCII letters, digits, the
hyphen, and space". The text that Chris Newman provided would meet that need.

2. The iana-vendor-tag production is described as representing "allowed forms for current registrations". Is this production  intended to describe (a) only the registrations currently found at  or (b) any registration that would be allowed by the registration process specified in this document? I think it is (b), but it reads like (a).

3. I agree with David that the examples are confusing, in that they liberally include the forbidden '/' character; either we could change the examples or we could more clearly explain what the vendor token is in each example (perhaps by means of the concept of a "vendor-token slot", similar to the "domain name slot" from RFC 5890).

4. The phrase "UTF-8 names are restricted to ASCII" sounds paradoxical; I suggest instead "Vendor tokens are restricted to ASCII for registration purposes" or somesuch.
2010-10-20
02 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded by Peter Saint-Andre
2010-10-20
02 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-10-20
02 Adrian Farrel [Ballot comment]
Support Dave's Discuss about RFC 2244.
Suggest that this will make RFC 2244 a normative reference.
2010-10-20
02 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-10-20
02 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-10-20
02 Lars Eggert [Ballot comment]
I support Dave Harrington's discuss.
2010-10-20
02 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2010-10-20
02 Gonzalo Camarillo
[Ballot discuss]
The author of this draft is discussing issues related to non-ASCII registration with the Gen ART reviewer:

http://www.ietf.org/mail-archive/web/gen-art/current/msg05691.html

I would like to see …
[Ballot discuss]
The author of this draft is discussing issues related to non-ASCII registration with the Gen ART reviewer:

http://www.ietf.org/mail-archive/web/gen-art/current/msg05691.html

I would like to see the conclusion of those discussions. If the decision is to move forward with ASCII-only names, the document needs to discuss backwards compatibility issues (David's discuss also deals with this point).
2010-10-20
02 Gonzalo Camarillo [Ballot Position Update] New position, Discuss, has been recorded by Gonzalo Camarillo
2010-10-18
02 David Harrington
[Ballot discuss]
1) does this document officially update RFC2244? it doesn't state that in the header
2) you have restricted name-component from utf-8 to …
[Ballot discuss]
1) does this document officially update RFC2244? it doesn't state that in the header
2) you have restricted name-component from utf-8 to ascii. this is not backwards compatible. you should discuss backwards compatibility, and how to handle receiving a previously compliant utf-8 name component.
3) are these two consistent? "Therefore, this document allows only ASCII letters, digits, the hyphen, and space to be used." and "name-component = *(name-char / UTF8-2 / UTF8-3 / UTF8-4) "?
4) I don't understand section 3.3, which gives an example of "/shared/vendor/vendor.example/product" and  section 3.4 that says ""vendor.company/ product" is and always has been illegal
2010-10-18
02 David Harrington [Ballot Position Update] New position, Discuss, has been recorded by David Harrington
2010-10-18
02 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-10-17
02 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2010-10-17
02 Alexey Melnikov Ballot has been issued by Alexey Melnikov
2010-10-13
02 Cindy Morgan State changed to IESG Evaluation from Waiting for AD Go-Ahead by Cindy Morgan
2010-10-13
02 Cindy Morgan Ballot has been issued by Cindy Morgan
2010-10-13
02 Cindy Morgan Created "Approve" ballot
2010-09-17
02 Alexey Melnikov Placed on agenda for telechat - 2010-10-21 by Alexey Melnikov
2010-09-15
02 Cindy Morgan State changed to Waiting for AD Go-Ahead from In Last Call by Cindy Morgan
2010-09-10
02 Amanda Baber
IANA has a question regarding the IANA Actions in this document.

IANA understands that, upon approval of this document, there is a single
IANA Action …
IANA has a question regarding the IANA Actions in this document.

IANA understands that, upon approval of this document, there is a single
IANA Action that must be completed.

Upon approval of this document the Vendor Subtrees subregistry in the
Application Access Protocol (ACAP) Numbers registry located at:

http://www.iana.org/assignments/acap-registrations/acap-registrations.xhtml

should be revised.

The subregistry should include the following description:

"A Vendor Token is a UTF-8 string beginning with "vendor.", and followed
by the name of the company or product. This name MUST NOT contain any
slash character, period, or the percent and asterisk characters
typically used as wildcards.

Following this may be names, separated from the Vendor Token by a
period, which need not be registered, thus forming a complete Vendor Name.

Vendors may reserve a portion of the ACAP namespace, which is also used
as the namespace for several other protocols, for private use. Vendor
Names are reserved for use by that company or product, wherever used,
once registered. Registration is on a first come, first served basis.
Whenever possible, private attributes and classes should be eschewed in
favour of improving interoperable protocols.

Vendors may only use names conforming to iana-vendor-tag at the current
time, future revisions of this specification may change this."

Registration Procedures:
First-come, first served using a registration template in [ RFC-to-be ]

IANA is to add a registration to the subregistry as if it had received
the following template:

To: iana@iana.org
Subject: Registration of ACAP vendor subtree

Private Prefix: vendor.example
Person and email address to contact for further information:
Dave Cridland

Initial registrations:

IANA Question: is IANA to leave the existing vendor subtrees in place,
or restart with a clean registry with only the example registration?

IANA understands that this single action, once clarification on initial
registrations is available, is the only action required to be completed
upon approval of this document.
2010-08-25
02 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer.
2010-08-20
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2010-08-20
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2010-08-17
02 Amy Vezza Last call sent
2010-08-17
02 Amy Vezza State changed to In Last Call from Last Call Requested by Amy Vezza
2010-08-17
02 Alexey Melnikov State Changes to Last Call Requested from AD Evaluation::AD Followup by Alexey Melnikov
2010-08-17
02 Alexey Melnikov Last Call was requested by Alexey Melnikov
2010-08-17
02 (System) Ballot writeup text was added
2010-08-17
02 (System) Last call text was added
2010-08-17
02 (System) Ballot approval text was added
2010-08-17
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-08-17
01 (System) New version available: draft-cridland-acap-vendor-registry-01.txt
2009-11-28
02 Alexey Melnikov State Changes to AD Evaluation::Revised ID Needed from AD is watching::Revised ID Needed by Alexey Melnikov
2009-07-06
02 Alexey Melnikov Draft Added by Alexey Melnikov in state AD is watching
2009-07-06
00 (System) New version available: draft-cridland-acap-vendor-registry-00.txt