Hi there,

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.7212074495361812662
326490325180684

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?

Thank you,

Tino.

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

[ Post a follow-up to this message ]

Hi Tino,

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

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.

Emmanuel

On 12/28/06, Tino Schwarze <tisc-CdamFmlgbXPX2ID+q72mRQ@public.gmane.org> wrote:
>
> Hi there,
>
> 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.7212074495361812662326490325
180684
>
> 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?
>
> Thank you,
>
> Tino.
>
> --
> www.quantenfeuerwerk.de
> www.spiritualdesign-chemnitz.de
> www.lebensraum11.de
>



-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ Post a follow-up to this message ]

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 type
s,
> so creating arbitrary long OID does not make a lot of sense, but as I'm no
t
> 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? ;-) ).
[vbcol=seagreen] 

Thanks,

Tino.

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

[ Post a follow-up to this message ]

Hi Tino,

On 12/28/06, Tino Schwarze <tisc-CdamFmlgbXPX2ID+q72mRQ@public.gmane.org> wrote:
>
> Hi Emmanuel,
> 
> 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...


The question is : will you AttributeType be OID ? Becuase then, well, we
won't accept attribute values with OIDs containing arks above this interval.
.
We could have used BigInterger, I know ... Anyway 

> Do also remember that, in LDAP, OID are used to declare new attribute
> types, 
> not 
>
> 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 converte
d
> it to a number.


What about doing a conversion like : A-> 10+ 1, B-> 10 + 2, ... Z->10 + 26,
0 -> 0, 1 -> 1, ...etc leading to OIDs like that :
GUID = azerty12345
OID = 11.36.15.28.30.35.1.2.3.4.5

Just a suggestion ...

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


Because.

42 is totally different, and should be used with respect :
http://de.wikipedia.org/wiki/42_(Antwort)


-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ Post a follow-up to this message ]

On Thu, Dec 28, 2006 at 04:55:11PM +0100, Emmanuel Lecharny wrote:
 
>
> The question is : will you AttributeType be OID ?

Yes, I will be generating attribute types on demand.

> Becuase then, well, we won't accept attribute values with OIDs
> containing arks above this interval.  We could have used BigInterger,
> I know ... Anyway 
 
>
> What about doing a conversion like : A-> 10+ 1, B-> 10 + 2, ... Z->10 + 26
,
> 0 -> 0, 1 -> 1, ...etc leading to OIDs like that :
> GUID = azerty12345
> OID = 11.36.15.28.30.35.1.2.3.4.5
>
> Just a suggestion ...

Good point, very simple indeed. I could even stick to ASCII and
zero-terminate the "string". That way it would be "human readable" for
fluent ASCII speakers.

Thanks,

Tino.

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

[ Post a follow-up to this message ]

> 
> 26, 
>
> Good point, very simple indeed. I could even stick to ASCII and
> zero-terminate the "string". That way it would be "human readable" for
> fluent ASCII speakers.


you mean,  OID= 65.90.69.82.84.89.49.50.51.52.53 for arzerty12345 ? Even
better than what I suggested. Not necessary to zero terminate the OID...

Thanks,
>
> Tino.
>
> --
> www.quantenfeuerwerk.de
> www.spiritualdesign-chemnitz.de
> www.lebensraum11.de
>



-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ Post a follow-up to this message ]

On Thu, Dec 28, 2006 at 06:31:56PM +0100, Emmanuel Lecharny wrote:
 
>
> you mean,  OID= 65.90.69.82.84.89.49.50.51.52.53 for arzerty12345 ?

Yes.

> Even better than what I suggested. Not necessary to zero terminate the
> OID...

Well, the (optional) zero would allow the hierarchy to be extended below
the encoded GUID. I even need that because this way I can assign each
open-EIS module a unique OID. My LDAP server would get an OID like this
(in decoded form):
...private-number.0.c4u_ldapserver.0.c4u_classic_email
the next module could get it's own OID space:
...private-number.0.c4u_something_else.0.custom-use

Hm. Supposed, anyone would need to parse back the OIDs. Otherwise, the
zero-termination is not neccessary, that's right.

Bye,

Tino.

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

[ Post a follow-up to this message ]

Can't us just use a separate attribute for the correlation instead of
using an OID?

Alex

Tino Schwarze wrote:
> Hi Emmanuel,
>
> On Thu, Dec 28, 2006 at 03:56:50PM +0100, Emmanuel Lecharny wrote:
> 
>
> Oh, I see. That's rather cumbersome and would clutter the structure a
> lot. Well, one's not supposed to parse the structure anyway...
> 
>
> 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 converte
d
> 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? ;-) ).
> 
>
> Thanks,
>
> Tino.
>

[ Post a follow-up to this message ]

Tino Schwarze wrote:
> On Thu, Dec 28, 2006 at 04:55:11PM +0100, Emmanuel Lecharny wrote:
> 
>
> Yes, I will be generating attribute types on demand.

Ok ignore my previous email ... now that I know what you're doing yes
you do need an OID for this.

Alex

[ Post a follow-up to this message ]