Hi Phil,
Phil Pennock wrote:
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).
as well as RFC 5258.
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 you are referring to the following text in section 4.1:
The dataset namespace is a slash-separated hierarchy. The first
component of the dataset namespace is a dataset class. Dataset
classes MUST have a vendor prefix (vendor.<vendor/product>) or be
specified in a standards track or IESG approved experimental RFC.
See section 7.3 for the registration template.
then I agree it is unfortunate. The difference between
vendor.<vendor/product> (i.e. vendor.<"vendor or product">) and
vendor.<vendor>/<product> is a bit subtle.
If there is a more up-to-date
reference,
I am afraid not.
or even if not, can guidance be provided to IANA?
Yes.
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.
Your suggestion seems reasonable.
As a side not I would just note that people who would like to keep using
"vendor.<vendor>/<product>" can still do that, because the structure of
vendor specific namespace is up to the vendor.
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".
IMHO, I would suggest keep existing definitions in RFC5257 as is, unless
there is a compelling reason to change.
I don't find "less ugly" to be a compelling reason in this case.
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?
I think the best way is to publish a short draft that updates the vendor
registry and makes it non-specific to ACAP.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf