Hi folks,
My apologies for the long message below. For those interested
in LDAP schemas and SLP templates it makes very interesing reading.
Cheers,
- Ira McDonald (consulting architect at Sharp Labs America)
High North Inc
-----Original Message-----
From: James Kempf [mailto:James.Kempf at eng.sun.com]
Sent: Tuesday, February 15, 2000 10:55 AM
To: jayhawk at att.com; imcdonald at sharplabs.com; James.Kempf at Sun.COM;
Pete.StPierre at eng.sun.com
Cc: flemingp at us.ibm.com; harryl at us.ibm.com
Subject: RE: Should SLP 'printer:' become an LDAP *abstract* schema?
>>There is only one SLP 'printer:' template defined (apart from
>Michael Pahmp's extension to 'printer:' defined for raw-tcp
>printing). Although a printer (or spooler/supervisor) offering
>print services has to choose *one* particular URL to register
>for SLP service advertising, all of the *other* URLs for various
>print protocols (typically half a dozen or more across several
>different protocol suites) only show in SLP as values of the
>'printer-uri-supported' attribute.
>
If that's the case, then it seems fairly clear that there should
be one LDAP schema for "service-printer" and the schema supports
an attribute called "printer-uri-supported" that contains the
URLs for the different protocols. If a separate schema
is desired for the service:printer:raw-tcp, then that could
be service-printer-raw-tcp. Similarly for other concrete
types (if they are desired).
>An SLP DA (unless it has special application code) won't know
>how to propagate all those other URLs into an LDAP-accessible
>directory.
>
If there is one service-printer schema with a printer-uri-supported
attribute, then the attribute will be propagated by the DA
just like any other one.
>There already are a number of vendor private definitions of
>'printer' being placed in LDAP-accessible directories. There
>is also (I think?) a DMTF CIM definition of 'printer'.
>
We looked briefly at using the DMTF CIM definition, but opted
for something that is more specifically designed for service discovery
because the CIM definitions seemed more oriented to management and
not service discovery. Private schema are always a possibility,
the problem is, of course, interoperability. The template
translation draft is designed to help foster interoperability
between SLP and LDAP, as well as between LDAP applications, to
the extent they use the schema defined by the draft.
>Are there *many* LDAP schema translations of the SLP 'printer:'
>template (all with identical base attributes) or is there one?
>LDAP schemas have been published as RFCs (and not just as
>registrations in an IANA-maintained directory like SLP templates).
>Do we need to develop multiple (nearly identical) RFCs?
>
IMHO, there may be different schema for different purposes, just like
there are MIBs for management and SLP templates for discovery.
In an ideal world, I suppose these could all be unified into one data model
but evolving them might become more difficult than having distributed
definitions as is currently the case. Given that schema defintion
and registration is not currently centrally controlled, the distributed
model is likely to persist. The primary issue is interoperability,
and given the current environment, it seems the most likely way
to foster interoperability is to concentrate on particular areas,
like managment or service discovery, and define schema translation
and generation rules for them. That is what we are trying to do
with the template translation draft, and I think that is what Ryan
is trying to do with his draft on translating the DMTF data model
into schema.
jak