Re: IANA-registered vendor subtree (RFC2244)
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 20 June 2008 18:36 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3800028C151; Fri, 20 Jun 2008 11:36:02 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E2F28C151 for <ietf@core3.amsl.com>; Fri, 20 Jun 2008 11:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tsu+c6XwH9e for <ietf@core3.amsl.com>; Fri, 20 Jun 2008 11:36:00 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6A26328C146 for <ietf@ietf.org>; Fri, 20 Jun 2008 11:36:00 -0700 (PDT)
Received: from [172.16.2.120] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <SFv4kQBZBAz0@rufus.isode.com>; Fri, 20 Jun 2008 19:36:01 +0100
Message-ID: <485BF875.8010504@isode.com>
Date: Fri, 20 Jun 2008 19:35:33 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <ietf-spodhuis@spodhuis.org>
Subject: Re: IANA-registered vendor subtree (RFC2244)
References: <20080615093434.GA34611@redoubt.spodhuis.org>
In-Reply-To: <20080615093434.GA34611@redoubt.spodhuis.org>
MIME-Version: 1.0
Cc: ietf-imapext@imc.org, ietf@ietf.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- IANA-registered vendor subtree (RFC2244) Phil Pennock
- Re: IANA-registered vendor subtree (RFC2244) Alexey Melnikov