Re: IANA-registered vendor subtree (RFC2244)

Alexey Melnikov <> Fri, 20 June 2008 18:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3800028C151; Fri, 20 Jun 2008 11:36:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2E2F28C151 for <>; Fri, 20 Jun 2008 11:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Tsu+c6XwH9e for <>; Fri, 20 Jun 2008 11:36:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A26328C146 for <>; Fri, 20 Jun 2008 11:36:00 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Fri, 20 Jun 2008 19:36:01 +0100
Message-ID: <>
Date: Fri, 20 Jun 2008 19:35:33 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Phil Pennock <>
Subject: Re: IANA-registered vendor subtree (RFC2244)
References: <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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:
>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
I am afraid not.

>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.
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 "" we
>would end up with IMAP annotation entries named "/vendor/"
>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