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?
Cheers,
- 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 at Sun.COM; JMayer at crt.xerox.com; McDonald,
Ira
Cc: Srvloc-discuss at 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.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: James Kempf [mailto:James.Kempf at Sun.COM]
Sent: Friday, July 13, 2001 12:02 PM
To: Erik.Guttman at Sun.COM; JMayer at crt.xerox.com; imcdonald at sharplabs.com
Cc: Srvloc-discuss at 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.
jak
>From: "McDonald, Ira" <imcdonald at sharplabs.com>
>To: "'Erik Guttman'" <Erik.Guttman at Sun.COM>, "Mayer, Jim"
<JMayer at crt.xerox.com>
>Cc: "'Srvloc-discuss at lists.sourceforge.net'"
<Srvloc-discuss at lists.sourceforge.net>
>Subject: RE: [Srvloc-discuss] When one device or server supports multiple
service types
>X-BeenThere: srvloc-discuss at lists.sourceforge.net>X-Mailman-Version: 2.0.5
>List-Help:
<mailto:srvloc-discuss-request at lists.sourceforge.net?subject=help>
>List-Post: <mailto:srvloc-discuss at lists.sourceforge.net>
>List-Id: Service Location Protocol discussion
<srvloc-discuss.lists.sourceforge.net>
>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
>suite).
>>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.
>>Cheers,
>- Ira McDonald, consulting architect at Sharp and Xerox
> High North Inc
>>-----Original Message-----
>From: Erik Guttman [mailto:Erik.Guttman at Sun.COM]
>Sent: Thursday, July 12, 2001 7:01 AM
>To: Mayer, Jim
>Cc: 'Erik Guttman'; 'Srvloc-discuss at 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
>service:printer:ipp://printer.somewhere.com>service:printer:ipp://printer.somewhere.com/alternate>service:printer:lpr://printer.somewhere.com>service:printer:raw-tcp://printer.somewhere.com>>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
'lpr'
>to get this list.
>>Erik
>>>>>>_______________________________________________
>Srvloc-discuss mailing list
>Srvloc-discuss at lists.sourceforge.net>http://lists.sourceforge.net/lists/listinfo/srvloc-discuss>>_______________________________________________
>Srvloc-discuss mailing list
>Srvloc-discuss at lists.sourceforge.net>http://lists.sourceforge.net/lists/listinfo/srvloc-discuss