Subject: Re: LDAP schema for SLP - Distinguished Names

From: James Kempf <[email-masked]>
Date: Thu, 11 Mar 1999 08:27:47 -0800 (PST)

Paul,

Thanx for the input. As Erik indicated, the LDAP translation draft
is far from frozen. In addition to the point you brought up,
the current draft refers to aspects of SLP that are specific
to SLPv1. The list of operators on pg. 16, for example, is
for SLPv1. In SLPv2, the operators exactly match the LDAP string
query syntax operators from RFC 1960, as does the SLPv2 query syntax
in general. Similarly, the SLPv2 attribute tag syntax has been changed
to match LDAPv3.

With regard to your comment about DNs, I also feel that a change
in the DN format for services would be appropriate. In particular,
I would like to see a convention whereby a new "container" RDN
(like the "ou" RDN in a standard LDAP name) is defined for collecting
all network services, and a new one for collecting instances of
service types. I'm not an LDAP or ASN.1 expert, so I'll
refrain from trying to come up with ASN.1 definitions, but the idea is
that the resulting DN for a particular printer might look something like this:

(cn=33245789, service-type=printer, services=UMPK15-2, ou=SunLabs, o=Sun, c=US)

The actual printer itself might have a service URL like:

	service:printer:ipp://mpk15-2.eng.sun.com/queue1
	
which would get transformed into the hash used for the cn. Alternatively,
the cn could be something more mneumonic, like the the host
and path part of the URL, in this case "mpk15-2.eng.sun.com/queue1".
The "services" RDN in this case is a collection of services, the name
of which corresponds to an SLP scope.

Alternatively, perhaps these two container RDNs could be handled
by adding two more "ou" components to the DN, with the convention
that they specify the service type and scope, rather than defining
new types.

There are a couple reasons for doing this. First, it provides a more
human readable syntax for services, and an organization by service
type and scope that could simplify administration by the LDAP directory
administrator. Secondly, it could help to improve query performance
by limiting queries to a particular service type and scope. This
matches well with the SLP model, and would also provide some structure
for the LDAP representation of services.

Missing in this representation is the language locale of the entry. 
I can't find anything in RFC 2251 nor in my reference on X.500 about
language locales for X.500 names. Perhaps the language locale could
be included in the cn as hash or added to the URL host + path, and
as an attribute, to distinguish two service URLs having attributes
in two languages but being otherwise the same. I recall reading
something in the Netscape LDAP server documentation about a mechanism
to set the language locale of LDAP requests, but perhaps that is
specific to Netscape's implementation.

I'd really be interested in hearing Novell's input on this, since
they have integrated X.500 naming and SLP in NDS for NetWare 5.

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

		jak

---

From: "Ryan Moats" <[email-masked]>
Date: Thu, 11 Mar 1999 12:07:33 -0600

> of which corresponds to an SLP scope.

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

To be able to build a DN like you have above, you would need to subclass
something.  The suggestion of subclassing applicationProcess from 2256
might work.  A zeroth level suggestion would be

(NAME 'serviceLocation' SUP applicationProcess MUST cn
MAY (serviceURL $ serviceAttribute $ serviceType $ serviceHash))

with the following attribute definitions

(NAME 'serviceURL' SUP name EQUALITY caseExactMatch)

(NAME 'serviceAtribute' SUP name EQUALITY caseIgnoreMatch)

(NAME 'serviceType' SUP name EQUALITY caseIgnoreMatch)

(NAME 'serviceHash' SUP name EQUALITY caseExactMatch)

The idea being that the example given above would look like:

dn: cn=queue1/printer,dc=mpk15-2,dc=eng,dc=sun,dc=com
cn: queue1/printer
dc: mpk15-2
dc: eng
dc: sun
dc: com
serviceURL: service:printer:ipp://mpk15-2.eng.sun.com/queue1
serviceAttribute: <<list of attributes>>
serviceType: printer
serviceHash: 33245789

of course, if you go this route, what is the service hash doing for
you?

Ryan