IANA-registered vendor subtree (RFC2244)

The "vendor subtree" for ACAP, establishing a textual namespace for
components in hierarchical metadata, has the registry of assignments at:

  http://www.iana.org/assignments/acap-registrations

This RFC 2244 data is also used by IMAP ANNOTATE (RFC 5257,
experimental) and the ANNOTATEMORE/ANNOTATEMORE2/METADATA draft series
(now: draft-daboo-imap-annotatemore-13.txt).

Given that ACAP has not been a success, is there a more up-to-date
reference for valid syntax of these names, both for developers and as
guidance to IANA?  As far as I can tell, four of the nine registrations
are syntactically invalid and this appears to have arisen because of
unfortunate labelling in RFC 2244.  If there is a more up-to-date
reference, or even if not, can guidance be provided to IANA?  What
should happen about existing registrations?  I suspect that they can
safely be truncated just before the invalid "/" and still provide a
complete and consistent registry.

The vendor-token which has to be registered with IANA is described in
RFC2244 as vendor.<vendor/product> which seems to have been interpreted
as: "vendor." <vendor> "/" <product>
Similarly, "vendor.<company/product name>." is used in section 7.4,
which also makes it clear that all subtrees are covered by a given
registration (leading to my belief that truncation in the existing
registry is the correct approach).

The ABNF in RFC2244 section 4.3 uses vendor-name twice and defines it:
----------------------------8< cut here >8------------------------------
   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
----------------------------8< cut here >8------------------------------

This ties in intuitively with the use of both "/" and "." as hierarchy
separators by the various protocols using this registration.

Furthermore, taken too literally, given the registration of
vendor-token, the definition of vendor-token in RFC2244 and the
reference to vendor-token in RFC5257, for a registration "vendor.foo" we
would end up with IMAP annotation entries named "/vendor/vendor.foo/bar"
when clearly what's intended is to end up with "/vendor/foo/bar".

Common sense makes it easy enough to pick out what is meant, but what is
defined in ABNF in two RFCs doesn't match.

With two RFCs and a draft on the way, what's the cleanest way to deal
with this?

-Phil
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf