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