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@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf