Subject: Re: LDAP schema for SLP - Distinguished Names

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

RE>>LDAP schema for SLP - Distinguished Names
James said:
> 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.

Are you including sv and dc in the distinguished name just for searching?
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.
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.

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
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.

The critical thing about the RDN is that it be unique amongst its siblings
in the directory tree.

At least that's my sense of it  - those of you actually administering
large networks may have a more realistic perspective.

Best regards,

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: "Ryan Moats" <[email-masked]>
Date: Fri, 12 Mar 1999 05:41:55 -0600

> sort of location or department? Then it might make sense in the dn.

dc is short for domainComponent.  It is an alternate method for forming a
DN.  I can't quote RFC chapter and verse right now but it is a legit method.

> omitted. Optionally, it filters for a particular location, department,

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.

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).

> large networks may have a more realistic perspective.

Yep that's right.  I personally think that the "en-us" would be the value
for an attribute.  Following my previous suggestion, we'd have

serviceAttribute: language=en-us

or something like that.  If somebody wanted to actually search on the en-us
tag, then they'd either have to do partial matching or actually define the
specific attributes they needed (this could be done too, I just wasn't
thinking
along those lines initially).

and yes, I will be in MN and plan on being at SVRLOC (got to wave the i-d
flag
if nothing else ;-)

Ryan