On Thu, Dec 28, 2006 at 04:55:11PM +0100, Emmanuel Lecharny wrote: > >> 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... > > 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 :) > >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. > > 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
