Re: Last Call: draft-cridland-acap-vendor-registry (The Internet Assigned Number Authority (IANA) Application Configurations Access Protocol (ACAP) Vendor Subtrees Registry) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Tuesday, August 17, 2010 06:13 -0700 The IESG
<[e-mail]> wrote:

> The IESG has received a request from an individual submitter
> to consider  the following document:
> 
> - 'The Internet Assigned Number Authority (IANA) Application 
>    Configurations Access Protocol (ACAP) Vendor Subtrees
> Registry '    <draft-cridland-acap-vendor-registry-01.txt> as
> a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send
> substantive comments to the [e-mail] mailing lists by
> 2010-09-14. 
>...
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-cridland-acap-vendor
> -registry-01.txt
>...

IESG,

This is very interesting.  In the applications area during the
last 15 years, I consider ACAP to be one of two major examples
of "good idea, no traction", so I suppose that updating this
spec to avoid the reference to it is A Good Thing.  I continue
to be concerned that the IESG apparently prefers to have the
community go to the trouble of generating and processing
standards-track RFCs to accomplish this sort of correction to a
registry, rather than devising some lighter weigh administrative
procedure.  In particular, I have no idea what it would mean to
do interoperability testing on a spec that claims to just update
an IANA registry, so have to question "standards track" unless
it is listed as updating RFC 5257, 5464, and perhaps 2244
itself.   This is probably not the time to try to solve the more
general problem.


The draft does, however, raise several questions.

(1) Why not go all the way: rename the registry to something
more neutral that avoids "ACAP", update the two newer protocol
specifications to point to the new registry, and advise IANA to
include "(formerly 'ACAP Vendor Registry')" in the newly-renamed
registry and to index it both ways?  I note that the ACAP
document does not specify a name for that registry or calls it
"ACAP vendor subtree" (RFC 2244, Section 7.4) not "ACAP vendor
registry", so the current name is already the result of an
administrative procedure, not an RFC requirement.

(2) If we are going to start tampering with syntax, I believe
that we have discovered many times over the years that embedding
ASCII (or Unicode C1) control characters in identifiers is an
invitation to nothing but trouble.  RFC 5198 recommends against
them, the various NVT specs recommend against them (see RFC 5198
for references and discussion), the Unicode Identifier and
Pattern Syntax document (UAX# 31) and associated Security
Considerations document (UTR# 36) strongly recommend against
permitting them, and so forth.  It was a mistake for ACAP to
allow some of them (as "SAFE-CHAR") in 1997; it seems
inexcusable for a document in 2010 to allow even more of them
(as "name-char"), at least without a thorough explanation.

(3) I note that the new spec even allows spaces and tabs in
vendor names, but appears to drop the quoting conventions of the
ACAP spec.  Again, this seems unwise; at minimum, I think the
community should see the rationale.

(4) In that same context, the first bullet in Section 3.4 of the
current document says "UTF-8 names are restricted to ASCII".
The ABNF suggests no such restriction, but appears to allow
essentially unrestricted Unicode characters in <name-component>,
with only  ".", "/", "%", and "*" excluded.  Section 3.1 says 

	"this specification restricts the current registrations
	to the ASCII subset of UTF-8.
	
	"Furthermore, characters such as control characters,
	whitespace, and quotes are likely to be confusing and
	have been similarly restricted."
	
	"Therefore, this document allows only ASCII letters,
	digits, the hyphen, and space to be used."

If that is actually the intent, let's do it rather than talking
about "the ASCII subset of UTF-8" and not have the ABNF formal
syntax in Section 3.2 appear to explicitly contradict the
description in Section 3.1.

Specifically, if the intent is what Sections 3.1 and 3.4 say it
is, then 3.1 should appeal to the "protocol identifier" argument
(which can be copied from, or referenced in, any number of
specs) and say "ASCII", not "subset of UTF-8".   And the ABNF in
Section 3.2 should include something like:

  name-component = *(name-char)

  name-char = %x20 / %x2D / %x30-39 / %x41-5A / %x61-7A

Which really is space, hyphen, digits and letters as Section 3.1
says.

If the intent is really to permit nearly-unlimited Unicode in an
informal "vendor name" but ASCII-only in the registered
identifier (possibly a good model), then the document is
massively confusing.  And I still don't believe that permitting
C0 or C1 control characters (other than space) anywhere is a
good idea.


(5) If space and/or both cases of characters are to be
permitted, I believe the document needs some hints about quoting
of the former (which was present in the ACAP spec) and whether
or not comparison of these identifiers is to be consider
case-sensitive or case-insensitive.

If we are going to go to the trouble to do this, let's at least
get it right and make it clear.  The present draft appears to
fail on both of those requirements.

    john