Return-Path: 
 <dev-return-14826-apmail-directory-dev-archive=directory.apache.org@directory.apache.org>
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: (qmail 14351 invoked from network); 28 Dec 2006 15:36:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 28 Dec 2006 15:36:21 -0000
Received: (qmail 91821 invoked by uid 500); 28 Dec 2006 15:36:28 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 91665 invoked by uid 500); 28 Dec 2006 15:36:27 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@directory.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@directory.apache.org>
List-Post: <mailto:dev@directory.apache.org>
List-Id: <dev.directory.apache.org>
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 91654 invoked by uid 99); 28 Dec 2006 15:36:26 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Dec 2006 07:36:26 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [88.198.17.232] (HELO easy2.in-chemnitz.de) (88.198.17.232)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Dec 2006 07:36:16 -0800
Received: from localhost (localhost [127.0.0.1])
	by easy2.in-chemnitz.de (Postfix) with ESMTP id 22F62B1F21
	for <dev@directory.apache.org>; Thu, 28 Dec 2006 16:35:55 +0100 (CET)
Received: from easy2.in-chemnitz.de ([127.0.0.1])
	by localhost (easy.in-chemnitz.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id IYo2l-Pqvf9k for <dev@directory.apache.org>;
	Thu, 28 Dec 2006 16:35:55 +0100 (CET)
Received: by easy2.in-chemnitz.de (Postfix, from userid 1013)
	id 1121DB1F15; Thu, 28 Dec 2006 16:35:55 +0100 (CET)
Date: Thu, 28 Dec 2006 16:35:55 +0100
From: Tino Schwarze <tisc@in-chemnitz.de>
To: dev@directory.apache.org
Subject: Re: OID size limit?
Message-ID: <20061228153555.GF24862@easy2.in-chemnitz.de>
References: <20061228141303.GD24862@easy2.in-chemnitz.de>
 <d45b08f00612280656v4fe58c50u960d710552ae3905@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d45b08f00612280656v4fe58c50u960d710552ae3905@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Emmanuel,

On Thu, Dec 28, 2006 at 03:56:50PM +0100, Emmanuel Lecharny wrote:

> so far, OID parts are stored in java long, so into the interval [-2^63,
> 2^63-1]. You can use up to 19 digits for an element of an OID, so your
> sample won'ty be accepted.
> 
> If you want to generate "random" OID, what I suggest is that you store 32
> bits values separated by a '.', like :
> 
> 1.3.6.1.4.1.<myprivateOID>.0.<first 32 bits value>.<second 32 bits value>.
> ... .<last 32 bits value>.

Oh, I see. That's rather cumbersome and would clutter the structure a
lot. Well, one's not supposed to parse the structure anyway...

> Do also remember that, in LDAP, OID are used to declare new attribute types,
> so creating arbitrary long OID does not make a lot of sense, but as I'm not
> aware of all the possible use-cases...
> 
> I would be very interested to know why you need such OID values.

Well, I'd like to create an automated open-EIS to LDAP mapping. In
open-EIS we've got so-called templates (which are basically RDBMS tables
with lots of sugar and niceties like multi-language support etc.). A
template has a uniqe name called GUID, e.g. "c4u_classic_email". To
avoid having to assign a unique template OID for each open-EIS template
(extending the data model etc.), I just took the template GUID (which
consist of [a-zA-Z0-9_] and is up to 128 characters long) and converted
it to a number.

That way, the template GUID -> OID mapping is unique and I don't need a
central registry (which is rather cumbersome because third parties may
develop open-EIS modules themselves and currently, they don't need to
tell us; then they'd need to apply for template OID, wait for it etc.).

I'll try the 32-bits approach (BTW why 32 and not 42? ;-) ).

> >is there any known limitation of OID size or the size of an OID part?
> >I'm going to use auto-generated OIDs and they will look like:
> >1.3.6.1.4.1
> >.<myprivateOID>.0.8228681198498217497059596.0.7212074495361812662326490325180684
> >
> >The OID BNF grammar doesn't specify any limits, so I'm only wondering
> >whether there are known real-life limits. Will performance be affected
> >by these monsters?

Thanks,

Tino.

-- 
www.quantenfeuerwerk.de
www.spiritualdesign-chemnitz.de
www.lebensraum11.de