"Herriot, Robert" wrote:
>> I prefer solution #2 because it avoids adding a new and rather strange
> operation. Instead it adds some new attributes and fits in with the
> existing infrastructure. Solution #2 is:
> ...
> To resolve the ISSUE in the above solution, I suggest that we add a
> printer attribute "authentication-supported", which we would also add
> to the printer template for SLP. This attribute would specify how a
> printer authenticates a client -- a service that is incomplete in IPP.
> The values of this attribute would be parallel to
> "printer-uri-supported" and "uri-security-supported", and would > include:
> ...
I think ignoring the "requesting-user-name" attribute is a bad idea
under any circumstances. HTTP authentication is separate from the
IPP request, and in many cases the HTTP username may be different
from the actual requesting user (i.e. a group username/password to
get access to the printer, with the IPP requesting user name used
for accounting).
The best option might be to add a "authentication-required"
attribute that defines what kind of authentication is required for
each URI in "printer-uri-supported". The values would be "None",
"Basic", and "Digest" (at a minimum), and for Digest authentication
the IPP client could then request the current printer state to
initiate the challenge before the job is sent (there are issues if
the printer has a time-based nonce...)
(FWIW, our current implementation uses the HTTP username value if
the "requesting-user-name" value is not specified, but is otherwise
ignored for purposes of printer accounting)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com