Hi James,
I have been thinking that there are three kinds of automatic shadowing
that an SLP DA might use to discovered (via DNS, DHCP, or SLP) LDAP
servers:
1) For IANA registered well-known templates (e.g., 'service:printer')
with standard translations (e.g., the LDAP Printer Schema that
Pat Fleming and I wrote), do INTELLIGENT shadowing according to
a configured policy - e.g., attach the LDAP Printer aux class to
the matching (same 'lpr:' URL) already configured LDAP DMTF
CIM_Printer logical device, instead of creating a brand new
LDAP Printer object for the shadow copy.
2) For IANA registered well-known templates ONLY (not privates)
without standard translations, according to configured policy
do simple rule-based shadowing according to RFC 2926. Due to
administrative configuration, the LDAP server should already
know about the resulting LDAP object class, so that the SLP DA
need not register the object class and _then_ the instance with
the LDAP server.
3) For private templates (unknown to the SLP DA), according to a
SEPARATE configured policy, do simple rule-based shadowing
according to RFC 2926. This is probably the worst case -
because the LDAP server probably won't know about the object
class.
Now, about where to configure the shadowed objects in the LDAP tree:
[We had an interesting brief chat with Hugo Parra and Ted Tronson
of Novell about this last week - they also think auto-shadowing
into LDAP objects is tricky to very difficult, so you're not alone.]
Why not copy the advertised SLP scope names (which are generally
geographic and/or organizational in realistic use cases) into
a concatenated single string (say with hyphens between) and use
that value for an 'ou=' (Organizational Unit) LDAP attribute,
to place the advertised service (e.g., a printer) into the
organizational subtree of the enterprise network (as opposed
to the user subtree, where the LDAP Printer aux class is useful)?
Comments?
Cheers,
- Ira McDonald
-----Original Message-----
From: James Kempf [mailto:James.Kempf at Sun.COM]
Sent: Friday, July 20, 2001 11:47 AM
To: mike at easysw.com; imcdonald at sharplabs.com;
Srvloc-discuss at lists.sourceforge.net
Cc: ipp at pwg.org
Subject: RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a
singl e print device]
Ira,
>While this behavior is not required of SLPv2 DAs, it is considered
>(at least by some) to be the best practice default DA behavior (i.e.,
>find an LDAP server via DNS or DHCP or SLP during bootup and then
>automatically begin shadowing service registrations into LDAP).
>
I would not call this "best practice". At this point, it is a
hypothetical practice recommended as a way of fostering SLP/LDAP
interoperability. To my knowledge, there is no commercial DA
currently available that shadows service registrations into LDAP.
Sunlabs did a prototype that validated the RFC 2926 schema conversion
draft, but the code was never productized.
jak