--On Tuesday, August 17, 2010 06:13 -0700 The IESG <iesg-secretary@xxxxxxxx> 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 ietf@xxxxxxxx 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf