Re: [VCARDDAV] vendor registry lookup service

Dave Cridland <dave@cridland.net> Mon, 27 July 2009 17:49 UTC

Return-Path: <dave@cridland.net>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FDD3A6CA4; Mon, 27 Jul 2009 10:49:04 -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 rfG2gH8Ha-Bu; Mon, 27 Jul 2009 10:49:03 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 56C973A6C77; Mon, 27 Jul 2009 10:48:37 -0700 (PDT)
Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <Sm3nNQAqPx-y@peirce.dave.cridland.net>; Mon, 27 Jul 2009 18:43:17 +0100
X-SMTP-Protocol-Errors: NORDNS
References: <4A6DC20C.8040608@viagenie.ca>
In-Reply-To: <4A6DC20C.8040608@viagenie.ca>
MIME-Version: 1.0
Message-Id: <21725.1248716527.767300@puncture>
Date: Mon, 27 Jul 2009 18:42:07 +0100
From: Dave Cridland <dave@cridland.net>
To: Marc Blanchet <marc.blanchet@viagenie.ca>, General discussion of application-layer protocols <apps-discuss@ietf.org>, vcarddav@ietf.org
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Mailman-Approved-At: Mon, 27 Jul 2009 11:32:22 -0700
Subject: Re: [VCARDDAV] vendor registry lookup service
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2009 17:49:04 -0000

On Mon Jul 27 16:04:44 2009, Marc Blanchet wrote:
> I made the point at the mike that we already have a vendor  
> registry: the
> private enterprise numbers (PEN), which contains 35K entries, on a  
> first
> come first serve manner, and automated by IANA. On the contrary, the
> proposal is based on the acap registry which contains about a dozen  
> entries.

Right, that's largely because we've reused that registry in a couple  
of other protocols already, and "short tag" names seem to be  
particularly useful.

> One comment was made about the fact that the PEN are made of digits,
> therefore not user-friendly to be shown to the end-user. While I  
> don't
> think this is a real issue and can be managed differently, I'm  
> proposing
> a simple solution: a lookup service mapping PEN to vendor name, for  
> user
> display.

You'd need one the other way around, too - existing protocols, and  
all. And existing protocols are real issues, like it or not.

> Thereby, this mail announces a PEN lookup service to map the PEN to  
> the
> vendor name. This is implemented as a DNS TXT record under the
> enterprise-numbers.org domain name. It is available now.

I'm absolutely not against combining the ACAP vendor registry with  
the PEN registry, but since existing protocols use both names and  
numbers (more technically, OID arcs), I think we need both  
registered. Moreover, most protocols have severe limitations on what  
characters can be included in those names - you'll have noticed that  
one of the changes I've made between the ACAP vendor registry and my  
draft is that I've drastically sliced the possible characters  
involved. So the vast majority of the names included in the PEN  
registry are simply unsuitable from the get-go.

I'd even be happy to see a DNS based lookup, actually - it might be  
entertaining to translate to and from "vendor.isode" <=>  
"1.3.6.1.4.1.453", and it can certainly have a *very* long TTL.

Of course, whilst you're at it, one could conceivably map the whole  
of the OBJECT IDENTIFIER space to DNS.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade