IPP Mail Archive: RE: IPP> FW: [Srvloc-discuss] [Multiple re

IPP Mail Archive: RE: IPP> FW: [Srvloc-discuss] [Multiple re

RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a singl e print device]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sun Jul 22 2001 - 18:08:57 EDT

  • Next message: joannalojk@yahoo.com: "IPP> Requesting Info....!"

    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

    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

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


    - Ira McDonald

    -----Original Message-----
    From: James Kempf [mailto:James.Kempf@Sun.COM]
    Sent: Friday, July 20, 2001 11:47 AM
    To: mike@easysw.com; imcdonald@sharplabs.com;
    Cc: ipp@pwg.org
    Subject: RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a
    singl e print device]


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


    This archive was generated by hypermail 2b29 : Sun Jul 22 2001 - 18:17:04 EDT