IPP Mail Archive: IPP> FW: Should SLP 'printer:' become an L

IPP Mail Archive: IPP> FW: Should SLP 'printer:' become an L

IPP> FW: Should SLP 'printer:' become an LDAP *abstract* schema?

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Feb 15 2000 - 13:56:24 EST

  • Next message: McDonald, Ira: "IPP> FW:[Erik G's answer about SLP templates as RFCs]"

    Hi folks,

    My apologies for the long message below. For those interested
    in LDAP schemas and SLP templates it makes very interesing reading.

    - Ira McDonald (consulting architect at Sharp Labs America)
      High North Inc

    -----Original Message-----
    From: James Kempf [mailto:James.Kempf@eng.sun.com]
    Sent: Tuesday, February 15, 2000 10:55 AM
    To: jayhawk@att.com; imcdonald@sharplabs.com; James.Kempf@Sun.COM;
    Cc: flemingp@us.ibm.com; harryl@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

    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.


    This archive was generated by hypermail 2b29 : Wed Feb 16 2000 - 09:53:07 EST