Subject: Re: LDAP schema for SLP - Distinguished Names

From: "Paul Collins" <[email-masked]>
Date: Thu, 11 Mar 1999 9:3:0 -0800

RE>>LDAP schema for SLP - Distinguished Names
Erik said:

> We certainly can.  This document has had very little review.  I want to
> make sure that we proceed correctly even if it means completely 
> reworking this document.
> 
> It is my hope that we can get concerted attention on this document from
> folks in the LDAP community and that we can move quickly to a workable
> naming scheme.

Ryan said:
> I tend to agree with Paul on this one. . . . 
> I need to think about this some more before next week to have a coherent
> counter proposal though.

Great! I'll try to elicit some feedback/info before your meeting. 

There is an X.500 "Application Process" object class that is referenced by
LDAPv3 that may be for this purpose. It might be most "compatible" for
your template to define a subclass of that or another existing LDAP class.
These are in RFC2256.7.12-15 if anybody wants to take a look.
Unfortunately, key parts are defined in X.521 which defines them in terms
of ISO 7498, which I don't have access to yet. I don't really understand
how these are used.

Paul Collins

** One Click Systems   http://www.oneclick.com/   [email-masked] **
** ClickMail Central Directory - master address book - LDAP server  **
** Chat with us--Wednesdays 10AM Pacific/1PM EST (www.oneclick.com) **

---

From: James Kempf <[email-masked]>
Date: Thu, 11 Mar 1999 15:09:06 -0800 (PST)

Ryan,

>
>Well, if you are looking at the name/host part of the URL, you should look
>at the informational RFC 2377 which discusses something similar to this.
>There is a standards track RFC for the domainComponent attribute, which
>must be supported by LDAPv3 implementations (RFC 1274).  This would help
>in building a DN like "cn=queue1/printer,dc=mpk15-2,dc=eng,dc=sun,dc=com".
>

I think you'd want to have the service type (printer) specifically be
a context rather than simply part of the terminal cn. The reason
is to facilitate searching. Maybe something like:

	cn=queue1/en-us,sv=printer,dc=mpk15-2,dc=eng,dc=sun,dc=com
	
One could thus make the search relative to the printer RDN to find
a printer.
	
And, yes, the hash wouldn't be needed in this case.

		jak

---

From: "Paul Collins" <[email-masked]>
Date: Thu, 11 Mar 1999 18:37:19 -0800

> I hope you'll join us at the working group meeting on Wed. afternoon
> next week.

Thanks! I would love to but I won't be able to make it--have to keep the
home fires burning here in Ashland, OR.

I was just rereading your post and think I came down too hard against more
items in the dn. Certainly organizing the printer, file server, and other
entries is important. It may not be necessary to specify this in your
template, however. The dn is not part of the definition of an LDAP
objectClass. Only the RDN, the first part of the dn, is defined. 

However, you can certainly recommend or require that SLP objects in the
LDAP directory be organized a certain way if that helps.

Anyway, I too would like to hear from someone at Novell or Apple or
Netscape.

Paul

---

From: James Kempf <[email-masked]>
Date: Fri, 12 Mar 1999 08:52:18 -0800 (PST)

Paul & Ryan,

>Are you including sv and dc in the distinguished name just for searching?

Yes and no. It's there partially to limit searching to a particular
subtree of the DIT, and partially as an organizing convention for
allowing services to be organized and provisioned by department,
physical location, etc. 

>If so, it may be simpler to have these as attributes instead. Attributes
>are fully indexed by LDAP servers and easy to specify in an LDAP search.

Yes, it could be an attribute.

>Also, you have to create entries for each level (an entry for sv=printer,
>and one for dc=mpk15-2). I don't know the "dc" type. Is dc=mpk15-2 some
>sort of location or department? Then it might make sense in the dn.
>

Actually, it's mean to be a physical location, building, floor, 
but it could be an organization name, project name, that kind of thing.
In general, its a name that's used to group or provision services.
As Ryan indicated in his email, "dc" is domain component, so maybe
that's not the right RDN type to use. Maybe "ou" would be better,
or define a new type

>It would be simplest and most flexible to just define the RDN (in your
>example the cn) and let the directory administrator decide how to organize
>entries (by location, entry type, project, or whatever). Anytime an SLP

Yes, that's what I was thinking of. The fundamental point I was
trying to get is to allow a provisioning of services such that
a sysadmin could configure applications to be
handed the DN to use when doing searches for services, and all
services would be found relative to that DN. As an added convenience,
service types would be classified within the context represented
by that DN as RDN's. I used the type "sv" in the example. The
"sv" type would be a context in which individual service instances
would be found. That way, an application that is looking for
printers would only need the base DN to determine what services
it's allowed to see, and from there it could search under the
"sv=printers" RDN for the actual instances of printers that it wanted.

>Certainly organizing the printer, file server, and other

Right, that's what I was trying to get at. I confess to not being
an LDAP expert so perhaps I wasn't quite clear. 

Most of these ideas are based on a prototype Java Naming and Directory
Interface (JNDI) service provider I did for SLPv1 that tried to fit
SLP into the LDAP model, which JNDI implements.

>Anyway, I too would like to hear from someone at Novell or Apple or

Yes, definitely! It would be great to get some input from real LDAP
experts on this. We would like to get agreement on conventions and
standardized scheme templates for service representation. Note that
this will not only benefit SLP interoperability, but also LDAP
usage, because I've heard that there is currently no standard for
service representation in LDAP, although I believe DMTF is working
on it.

		jak

---

From: "Paul Collins" <[email-masked]>
Date: Fri, 12 Mar 1999 8:32:29 -0800

RE>>LDAP schema for SLP - Distinguished Names
Talking about Ryan's printer DN example:
       	cn=queue1/en-us,sv=printer,dc=mpk15-2,dc=eng,dc=sun,dc=com
...

>> application wants to get all the printer entries, it just asks the LDAP
>> server for all objects in the whole directory with a filter for
>> "objectClass=printer". It doesn't even need a base object DN, that can
be
>> omitted. Optionally, it filters for a particular location, department,
>> URL, or other attribute.

> Paul is somewhat right.  Defining the search in this way will work, but
> it may be slow ;-).  Any attribute may be searched on and if the
> directory implementation indexes on it, then the search will go faster.

True! I don't know how you tell LDAP servers they must index particular
attributes. My server just indexes whatever it gets, but I don't follow
all the rules (shame on me). 

I'm just worried that specifying the latter parts of the DN would force a
particular organization of the directory and require the existence of more
objects to act as parents.

> The reference to leaving off the base object DN is on the search (I
> hope). The first time I read this, I began to think you were saying the
> printer object didn't need a DN (heh, heh).

I call it "directory services by wandering around." :-)  That's right, I
just mean the LDAP search command doesn't have to use a DN. 

Regards,

Paul