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

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

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

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

[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

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.