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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf