IPP Mail Archive: Re: IPP> Re: SLP Printer Service Template

IPP Mail Archive: Re: IPP> Re: SLP Printer Service Template

Re: IPP> Re: SLP Printer Service Template

Erik Guttman (Erik.Guttman@Sun.COM)
Mon, 09 Nov 1998 11:22:02 +0100

I agree with Jim's comments. I want to add that although
the service: URL is used as a handle to a SLP service
registration, it is really a URL encoding of a service
access point. The URL is intended to convey the location
of a service. If there are distinct access protocols for
printing offered by a single device, the device should
register multiple URLs in my opinion. Each of these
registrations will have different attributes (though some
may be in common, like location, administrator, etc.)

I don't think there is a problem vis-a-vis multiple
entries in a directory. The truth is, these services
are distinct. A client which can use one protocol wants
to find a server to use. It doesn't care that the server
supports a bunch of other access protocols.

There is merit in the approach of registering a server once
if it represents a constellation of features, instead of
many URIs. In this case, the client would request the
service by listing its requirements in a service request:

(&(printer-uri-supported=http*)(security-uri-supported=daa))

This will return only services which support daa and http
access protocols, say:

service:printer://someserver

This doesn't give you the actual printer uri though!
Unfortunately, you then have to do an attribute request for

service URL: service:printer://someserver
attribute: printer-url-supported

This would return the entire http URL, for instance:

http://someserver/exact/path/goes/here

As Jim indicated, this would require two requests instead of one.

Erik