Subject: Re: Sanity check - LDAP DSA Schema

From: "Sukanta Ganguly" <[email-masked]>
Date: Wed, 01 Sep 1999 11:53:40 -0600

Hi,
   According to what I understood from the proposal "ldapApplicationEntity" class has its SUP as "top" and "ldapDSA" class has its SUP as "ldapApplicationEntity". Now this is confusing to me.

I guess I didnot catch the gist of the "ldapDSA" class. I think "ldapApplicationEntity" should have "ldapDSA" as its SUP. Cause the way I expect it to act is locate the ldapDSA, which provide me routes to the ldap applications that I am interested in.

  From the point of a client I would like to query all the LDAP DSA's which support the LDAP application(s) satisfying my needs. My goal is to get to the LDAP applications. Also, the ldapDSA may host the application on the local server or a remote server. These ldap applications may offer different quality of service and I may need certain preferred QoS.

  Does that make sense to you folks or am I on a different planet!

Thanks
SG

Sukanta Ganguly
Research Scientist
Novell Inc
Phone 801-861-5190

>>> "Ed Reed" <[email-masked]> 08/31/99 07:58PM >>>
Attached is a short schema description of an LDAP directory service agent object class (ldapDSA), that makes use of labeledURI presentation addresses instead of OSI ones.  If there's no violent opposition, I expect to make the LDUP information model refer to these definitions (they're broken out here from the LDUP schema for the same reason we broke out the ldapSubEntry definition - 'cause they seem more generally useful than for just LDUP).

Ed

=================
Ed Reed, Technologist
Novell Product Management
+1 801 222 3944 (new number!)

---

From: "Ed Reed" <[email-masked]>
Date: Wed, 01 Sep 1999 16:59:00 -0600

Nope - keep in mind the perspective, and the reading of, the X.500 folks.

A DSA is not a server, it is a service.  Thus, it is an instance of an applicationEntity.  See X.521.

Other examples of an applicationEntity would be a web service on a particular port,
or an ftp daemon.

The ldapDSA is a class derived from an ldapApplicationEntity...which is defined in LDAP to
use ldap url syntax as a replacement for an OSI network entity title as the network address
representation syntax.

Thus, I would create and ftp daemon as an instance of an ldapApplicationEntity directly,
or if I needed to add more attributes for the ftp service, I could define a new class
for ftp daemons (call it an ftpServic object class) with the additional attributes, and create
instances of those...if I were so inclined.

Ditto, an IMAP4 post office server, etc.

Ed

=================
Ed Reed, Technologist

>>> "Sukanta Ganguly" <[email-masked]> 09/01/1999 11:53:40 >>>
Hi,
   According to what I understood from the proposal
"ldapApplicationEntity" class has its SUP as "top" and "ldapDSA" class
has its SUP as "ldapApplicationEntity". Now this is confusing to me.

I guess I didnot catch the gist of the "ldapDSA" class. I think
"ldapApplicationEntity" should have "ldapDSA" as its SUP. Cause the way
I expect it to act is locate the ldapDSA, which provide me routes to the
ldap applications that I am interested in.

  From the point of a client I would like to query all the LDAP DSA's
which support the LDAP application(s) satisfying my needs. My goal is to
get to the LDAP applications. Also, the ldapDSA may host the application
on the local server or a remote server. These ldap applications may
offer different quality of service and I may need certain preferred
QoS.

Thanks
SG

Sukanta Ganguly
Research Scientist
Novell Inc
Phone 801-861-5190

>>> "Ed Reed" <[email-masked]> 08/31/99 07:58PM >>>
Attached is a short schema description of an LDAP directory service
agent object class (ldapDSA), that makes use of labeledURI presentation
addresses instead of OSI ones.  If there's no violent opposition, I
expect to make the LDUP information model refer to these definitions
(they're broken out here from the LDUP schema for the same reason we
broke out the ldapSubEntry definition - 'cause they seem more generally
useful than for just LDUP).

Ed

=================
Ed Reed, Technologist

---

From: "Natarajan SK" <[email-masked]>
Date: Sat, 04 Sep 1999 13:56:16 -0600

Hi Ed,
             In the draft 'ldapPresentationAddress' represents the URL of the ldap server that the client is to contact to receive certain services. Now the ldapPresentationAddress attribute as per the draft is identicalto the 'ref' attribute which can be of the type "ldap://hostA/o=abc,c=us"(as per  [NAMEDREF]) . Thus a client seeking some ldap service might search for an ldapApplicationEntity  which has a supportedApplicationcontext resolving the clients needs and the client might then go on to find that the ldapPresentationAddress is of the type  
           "ldap://hostA/o=abc,c=us"
          In this case is it the client that needs to parse the URI and extract the host discarding the contexts.  
         Or do we modify the ldapPresentationAddress to mention that the address is of the type ldap://<hostname> explicitly saying that the ou=abc,c=us which might follow if the ldapPresentationAddress is identical to "ref" is not applicable.
          
           In any case if the ldapPresentationAddress is to represent the address of the server I think  it should differ from a "ref" by not including the  context  that a ref might contain.        

Hope I've not confused you,
Natarajan

S.K.Natarajan
Senior Software Engineer
Novell Software, Bangalore
E-mail [email-masked]
Ph. no. 91-80-572-1856/58 Extn. 2213
Fx 91-80-572-1870

>>> "Ed Reed" <[email-masked]> 09/01/99 07:28AM >>>

Ed

=================
Ed Reed, Technologist