IANA-registered vendor subtree (RFC2244)

Phil Pennock <ietf-spodhuis@spodhuis.org> Sun, 15 June 2008 09:34 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id DB81A3A68FC; Sun, 15 Jun 2008 02:34:03 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 283473A687F for <ietf@core3.amsl.com>; Sun, 15 Jun 2008 02:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id RJv6x0AjlEcT for <ietf@core3.amsl.com>; Sun, 15 Jun 2008 02:34:01 -0700 (PDT)
Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2001:980:fff:31::a]) by core3.amsl.com (Postfix) with ESMTP id D633A3A68CC for <ietf@ietf.org>; Sun, 15 Jun 2008 02:34:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=d200803; d=spodhuis.org; h=Received:Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition; b=eKdavGNojOUspxcbmAwb87LuansQTFLqks6j/WkT6T1m7L0z+5GekV4N175fkSabXKfEWy+IdcHORsiD8okhU4x3M2ozzyodPXMBnSUDlbaazDOFpptsy4TxTKKKW2Kf9D9K7PDE9iShxKNEd/stRmxLQA8RDmsyd2GCFpceAoQ=;
Received: by smtp.spodhuis.org with local id 1K7od8-00094z-Qc; Sun, 15 Jun 2008 09:34:34 +0000
Date: Sun, 15 Jun 2008 02:34:34 -0700
From: Phil Pennock <ietf-spodhuis@spodhuis.org>
To: ietf@ietf.org
Subject: IANA-registered vendor subtree (RFC2244)
Message-ID: <20080615093434.GA34611@redoubt.spodhuis.org>
Mail-Followup-To: ietf@ietf.org, ietf-imapext@imc.org
MIME-Version: 1.0
Content-Disposition: inline
Cc: ietf-imapext@imc.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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).

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?

IETF mailing list