Re: Last Call: draft-cridland-acap-vendor-registry (The Internet Assigne

Thanks for your review, you've identified at least one error on my  
part for certain, and raised an issue of clarity I'd like to address.
On Tue Aug 17 20:37:16 2010, John C Klensin wrote:
> 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.
This is only partly a matter of process. The registry definition  
itself needs updating, mostly to tighten the syntax for  
registrations, for many of the reasons you list below.
But I readily agree that ACAP has a lot of good ideas not yet  
extracted - I'm still finding it useful as an actual working  
protocol, too. I'm typing this in a fully ACAP-aware MUA, after all.
> 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.
Well, it's a registry of vendor names, or at least name-tokens, but  
retaining the "ACAP" name in the name of the registry is mostly a nod  
to history. It's the least of our historical warts, I think.

> (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.
Right, that wasn't the intention, and yes, I see I've let a few more  
slip through when rewriting that rule, I'll correct that. I'd greatly  
appreciate some text along the lines of the above, incidentally.
The intention was to document the vendor-token as it should have been  
in ACAP (and, I note, was documented - that there are errors in the  
registry currently isn't really the fault of RFC 2244), and then also  
restrict the rules for new registrations to be a proper subset,  
allowing us to take advantage of all the advice you give here.

> (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.
The quoting in ACAP is largely orthogonal to this - a vendor name is  
used, in ACAP, in various places as a portion of an identifier that  
is itself then quoted in the wire protocol - in the model itself,  
however, vendor names are not quoted.
So attributes like "vendor.Cyrusoft.config", or datasets such as  
"/vendor.Eudora/~/" - and please note I do these from memory - are  
quoted on the wire as a whole, but "vendor.Cyrusoft" and  
"vendor.Eudora" are themselves not quoted individually.

> (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.
Well, basically nor do I, but the registry originally allowed for  
vendor names to be fairly unrestricted.
The dataset and attribute syntax in ACAP is specified in §4.3, rather  
than §8, and it's here that vendor tokens are defined in RFC 2244.
It says:

  name-component  = 1*UTF8-CHAR
                    ;; MUST NOT contain ".", "/", "%", or "*"

  vendor-name     = vendor-token *("." name-component)

  vendor-token    = "vendor." name-component
                    ;; MUST be registered with IANA

UTF8-CHAR itself is in the main Formal Syntax in §8, where it's  
defined as:
  UTF8-CHAR          = TEXT-UTF8-CHAR / CR / LF
  TEXT-UTF8-CHAR     = SAFE-UTF8-CHAR / QUOTED-SPECIALS
  SAFE-UTF8-CHAR     = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 /
                       UTF8-5 / UTF8-6

[etc]

Basically, any 8-bit sequence that looks like UTF-8. As a way of  
ensuring backwards compatibility, applications are basically told  
they might experience these. My intent was to describe this in the  
<possible-vendor-tag> production, rather than the <iana-vendor-tag>  
that describes what registrations are allowed.
Now, compare this to what the ABNF actually specifies for  
registrations:
  vendor-token        = "vendor." vendor-tag

  vendor-tag          = iana-vendor-tag / possible-vendor-tag

  iana-vendor-tag     = 1*(ALPHA / DIGIT / SP / "-")
                    ;; This production represents
                    ;; allowed forms for current registrations.

That's just ASCII letters, digits, space, and hyphen - there is no  
contradiction between the formal syntax and §3.1.
I'm sure this can be made clearer, and I'd welcome suggestions.

> (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.
As I said before, ACAP makes no comment about direct quotation of  
vendor tags, only when they are part of dataset or attribute names,  
which are indeed quoted.
As for comparison, that's an interesting problem. In ACAP, these are  
used in names which are compared case-sensitively (and without  
normalization of the UTF-8, for maximum fun). I don't think we should  
be registering names which differ only in case.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf