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

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

IPP> FW: [Srvloc-discuss] [Multiple registrations for a single print d evice]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sat Jul 14 2001 - 12:32:40 EDT

  • Next message: mjoel@netreon.com: "RE: IPP> ippget Spec Changes"

    Hi folks,

    This thread has been going for several weeks on the SLP mailing
    list. Could IPP implementors who plan to support SLP (at some
    point) please participate (here on the IPP list and _then_ on
    the SLP list)?

    This is the same phantom issue that wasted three months in late
    1999 on the SLP and IPP lists. The PWG concensus at that time
    was _one_ registration for _one_ print device.

    Novell and IBM folks - comments?

    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    PS - Please note that the new SLP mailing list at Source Forge
    is entirely closed - you _must_ first join the list to make
    a posting.

    -----Original Message-----
    From: McDonald, Ira
    Sent: Saturday, July 14, 2001 12:27 PM
    To: 'James Kempf'; Erik.Guttman@Sun.COM; JMayer@crt.xerox.com; McDonald,
    Cc: Srvloc-discuss@lists.sourceforge.net
    Subject: RE: [Srvloc-discuss] When one device or server supports
    multiple service types

    Hi James,

    We're talking at cross purposes.
    Although the data load on SLP DAs and LDAP DSAs is significant
    with multiple advertisements of a single print device, the
    important point is pollution of the customer's LDAP namespace
    with the duplicate registrations.

    This pollution is impossible to avoid with SLP DAs that
    automatically shadow registrations via LDAP.

    Changing the protocol to allow the registration of an abstract
    type ('service:printer:') WITHOUT a full concrete URL is not
    a reasonable solution.

    New service types (like 'service:print-device:' from Erik's
    note) also are not a reasonable solution.

    The SLP Printer v2.0 and the equivalent LDAP Printer Schema
    have been stable for 18 months, based on our complete concensus
    on the PWG mailing lists for IPP and Printer MIB. It's a lot
    too late to change the rules for implementors at a number of
    printer vendors.

    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: James Kempf [mailto:James.Kempf@Sun.COM]
    Sent: Friday, July 13, 2001 12:02 PM
    To: Erik.Guttman@Sun.COM; JMayer@crt.xerox.com; imcdonald@sharplabs.com
    Cc: Srvloc-discuss@lists.sourceforge.net
    Subject: RE: [Srvloc-discuss] When one device or server supports
    multiple service types

    Hi Ira,

    There is an alternative that could still support the original intended
    SLP semantic and not require the UA to have to sort through the
    returned attributes.

    The primary issue seems to be the size of the multiple advertisements.
    If the printer supports 6 protocols, it would have to support 6
    sets of identical or almost identical advertisements, consuming
    more memory. Is that so?

    What if we allow the printer to advertise all the common attributes
    under the abstract service type "service:printer"? The attributes
    that differ would be registered under the particular concrete types.
    When the DA (or SA) goes to perform query evaluation for a concrete
    type, it would append the abstract type attributes to the
    concrete type and perform query evaluation on that. The concerte type
    would "inherit" in a way the attributes from the abstract type.

    This would have only one set of printer attributes in the DA. It
    would not require a change in wire format, just a change in the
    query evaluation and registration rules.


    >From: "McDonald, Ira" <imcdonald@sharplabs.com>
    >To: "'Erik Guttman'" <Erik.Guttman@Sun.COM>, "Mayer, Jim"
    >Cc: "'Srvloc-discuss@lists.sourceforge.net'"
    >Subject: RE: [Srvloc-discuss] When one device or server supports multiple
    service types
    >X-BeenThere: srvloc-discuss@lists.sourceforge.net
    >X-Mailman-Version: 2.0.5
    >List-Post: <mailto:srvloc-discuss@lists.sourceforge.net>
    >List-Id: Service Location Protocol discussion
    >Date: Thu, 12 Jul 2001 18:37:34 -0700
    >Hi Erik and Jim,
    >Wait - the Printer template does have 'printer-xri-supported'.
    >(all supported URLs in ALL protocol suites, not just Internet
    >A _single_ registration under any of the valid URL types will
    >(with Erik's extension to return attributes with the initial
    >service search, which is a _very_ good idea) return all the
    >necessary URLs without the duplicate SLP registrations for
    >the same print system and therefore without the duplicate
    >LDAP Printer objects that are going to get automatically
    >shadowed by a good SLPv2 DA.
    >Since the implementation of scrolling results extension in
    >to LDAPv3 (i.e., give me the _next_ max-results matches) is
    >OPTIONAL and far from widely implemented or deployed,
    >populating the customer's LDAP enterprise directory with
    >5 to 10 times as many Printer objects can cause awful
    >performance, with no visible benefit.
    >All of the current printer standards developed by the PWG
    >[Printer MIB (RFC 1759), Job Monitoring MIB (RFC 2707), and
    >IPP/1.1 (RFC 2910/2911)] advertise a print device _once_
    >and then show all the supported 'channels' (i.e., print
    >protocols and URL paths) on that single print device.
    >- Ira McDonald, consulting architect at Sharp and Xerox
    > High North Inc
    >-----Original Message-----
    >From: Erik Guttman [mailto:Erik.Guttman@Sun.COM]
    >Sent: Thursday, July 12, 2001 7:01 AM
    >To: Mayer, Jim
    >Cc: 'Erik Guttman'; 'Srvloc-discuss@lists.sourceforge.net'
    >Subject: RE: [Srvloc-discuss] When one device or server supports
    >multiple service types
    >> Erik,
    >> Thanks for your reply. Here is a followup question:
    >> When you said:
    >> > One has to distinguish between a service with multiple access
    >> > protocols
    >> > and two distinct services. The only reason to have an
    >> > abstract service
    >> > type is to group multiple access protocols under one category
    >> > - so that
    >> > one can search for the service irrespective of the access protocol.
    >> Were you suggesting that each service should only be registered once, or
    >> that each service should be registered once per access protocol? Or
    >> something else?
    >You have to register N times, regardless.
    >service:printer:ipp://foo.org + attrs
    >service:printer:lpr://foo.org/queue + attrs
    >Or (assuming there are 'ipp' and 'lpr' schemes that will be used
    >for service discovery):
    >ipp://foo.org + attrs
    >lpr://foo.org/queue + attrs
    >> Here's a concrete example:
    >> A printer supports both IPP and LPR access. The printer is to be
    >> advertised using the printer template (v2). The
    >> "printer-xri-supported"
    >> attribute from the template indicates that the printer supports
    >> three
    >> different URLs:
    >> ipp://printer.somewhere.com
    >> ipp://printer.somewhere.com/alternate
    >> lpr://printer.somewhere.com
    >> What registrations should the SA for this printer make?
    >Those 3.
    >The added benefit of registering
    >is that I could issue a service request with service type 'service:printer'
    >and get back all 4 instances. With your example, I would have to issue
    >two requests, one with service type 'ipp', the other with service type
    >to get this list.
    >Srvloc-discuss mailing list
    >Srvloc-discuss mailing list

    This archive was generated by hypermail 2b29 : Sat Jul 14 2001 - 12:39:31 EDT