Nope that is accurate with IANA – goto 
http://pen.iana.org/pen/PenApplication.page

 

   joe

 

--

O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm

 

 

From: [email protected] 
[mailto:[email protected]] On Behalf Of Dustin 
Puryear
Sent: Wednesday, April 21, 2010 1:29 PM
To: Peter Brooks
Cc: [email protected]
Subject: [ldap] RE: Using ldap to support an ontology

 

To answer one of your questions: I believe you go through IANA to get a OID, 
although it's been so long since I've done that so I may be wrong.

 

One quick note: Be sure to name the attributes with an org identifier, e.g., 
you would name responsible as yourOrgResponsible. This reduces the chance that 
you will use a custom attribute name that somebody else uses but for different 
purposes.

 

As far as " Obviously there'd be much more to it than this, but the authorised 
person ought to be able to update the status whilst others can read it, with 
the status being, effectively, an enum or enumerated type.", yes, with LDAP you 
can do all of that.

 

I'm happy to help further.

 

Thanks.

 

From: Peter Brooks [mailto:[email protected]] 
Sent: Wednesday, April 21, 2010 11:36 AM
To: Dustin Puryear
Cc: [email protected]
Subject: Re: [ldap] Using ldap to support an ontology

 

On 21 April 2010 17:46, Dustin Puryear <[email protected]> wrote:

Can you be a little more specific in what you're trying to do? What kind
of data are you going to store? Do you need to do any serious
computations based on that data?

 

Yes, I do. The data are the triplets of an ontology. I'm looking at it as a 
means of keeping, and updating, status and other details of strings of records 
of an ontology. Here's some pseudo code that I hope gives a flavour:

 

attributetype (

        1.3.6.1.4.1.4203.666.42.40

        NAME 'responsible'

        SYNTAX '1.3.6.1.4.1.1466.115.121.1.12'

        SINGLE-VALUE )

attributetype ( 

        NAME 'status'

        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

objectclass ( 

        1.3.6.1.4.1.4203.666.42.50

        NAME 'service-status'

        SUP leaf

        ABSTRACT

        MAY (status $ responsible) )

objectclass (

        1.3.6.1.4.1.4203.666.42.70

        NAME 'SDP'

        SUP top

        AUXILIARY

        DESC 'Service Design Package'

        MAY ( service-status $ service-name $

        service-owner $ 

                SDP-Version ) )

 

Obviously there'd be much more to it than this, but the authorised person ought 
to be able to update the status whilst others can read it, with the status 
being, effectively, an enum or enumerated type.

 

Does this make it any clearer?

 

 

Reply via email to