|
Home > Archive > Apache Directory Project > December 2006 > OID size limit?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Tino Schwarze 2006-12-28, 1:11 pm |
| 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.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?
Thank you,
Tino.
--
www.quantenfeuerwerk.de
www.spiritualdesign-chemnitz.de
www.lebensraum11.de
| |
| Emmanuel Lecharny 2006-12-28, 1:11 pm |
| 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.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?
>
> Thank you,
>
> Tino.
>
> --
> www.quantenfeuerwerk.de
> www.spiritualdesign-chemnitz.de
> www.lebensraum11.de
>
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Tino Schwarze 2006-12-28, 1:11 pm |
| 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? ;-) ).
[vbcol=seagreen]
Thanks,
Tino.
--
www.quantenfeuerwerk.de
www.spiritualdesign-chemnitz.de
www.lebensraum11.de
| |
| Emmanuel Lecharny 2006-12-28, 1:11 pm |
| 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 converted
> 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
| |
| Tino Schwarze 2006-12-28, 1:11 pm |
| 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
| |
| Emmanuel Lecharny 2006-12-28, 1:11 pm |
| >
> 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
| |
| Tino Schwarze 2006-12-28, 1:11 pm |
| 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
| |
| Alex Karasulu 2006-12-28, 7:11 pm |
| 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 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? ;-) ).
>
>
> Thanks,
>
> Tino.
>
| |
| Alex Karasulu 2006-12-28, 7:11 pm |
| 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
|
|
|
|
|