IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

Robert Herriot robert.herriot at Eng.Sun.COM
Fri Nov 6 22:33:01 EST 1998

I talked to Ira about the differences of our ideas and I think that we have 
a resolution.  But I hope others from ipp and svrloc will reply to these

Before our discussions, I was assuming that an SLP DA would contain a 
separate entry for each URI associated with a printer. This seems to be the 
natural way to use SLP where a printer URI is associated with a collection 
of attributes.

Ira was assuming that an SLP DA would contain exactly one entry per printer. 
It would be arbitrarily associated with one of the printer's URI and the 
collection of attributes would contain information for all of the printer's 
URI. Ira preferred having one entry per printer because it reduces the 
amount of information to register and avoids the propagation problem where a 
DA, during times of re-registration has a mixture of new and old 
registrations for a printer. This problem arises with printers because they 
typically support many protocol stacks, and thus potentially many URI's.

As we talked about it, I realized that Ira's solution is closer to the way I 
understand Jini to work. Each name service entry in Jini is just a 
collection of objects without any special name associated with it. We can 
make SLP look like Jini if we view the SLP name as an object handle, and the 
SLP entry as the collection of objects referenced by this object handle.

When we examined the issue of associating each URI with security 
information, I realized that we could use the "service: URL" 
syntax for security information. A "service: URL" can have attributes that 
follow the URL path and that these attributes can be defined in the printer 
template document. It isn't clear to us if the attributes names in the 
"service: URL" should also appear as regular attributes in the template. Do 
any svrloc experts know?

So we think that the solution is that a printer registers a single entry and 
that one of the attributes is "printer-uri-supported", which contains a 
collection of "service: URLs", one for each way that the printer can be 
contacted. Each of those URL's must have all information needed for a client 
to be able to communicate with the printer. The name of this entry in the DA 
is arbitrary, but the first URL in the printer-uris-supported is reasonable. 

This solution suggests that IPP be changed to drop the 
"uri-security-supported' attribute from IPP v 1.0 and change 
'printer-uri-supported" to contain "service: URL"s. I expect that the 
support for security at this time is such that this is an easy 1.0 bug fix.

Bob Herriot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/19981106/1d26f1c8/attachment-0001.html

More information about the Ipp mailing list