Hi there,
In my Get-User-Printer-Attributes white paper (https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170404.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170404.pdf>) I wanted to clearly articulate the reason why Get-Printer-Attributes is not sufficient by itself to convey per-user printing options (print policy). The existing section 4 isn't sufficiently detailed IMHO - here's what I have thus far (with some additions since I posted the above draft):
The existing Get-Printer-Attributes operation itself has the correct semantics, but the expectation of all legacy Clients is that the Printer will not respond to a Get-Printer-Attributes operation with an HTTP challenge. Adding additional operation attributes to the Get-Printer-Attributes operation to cause the Printer to respond with an authentication challenge could be done but would require updating core IPP specifications, which is procedurally not desirable. If the Printer were to filter its response or respond with an authentication challenge if “requesting-user-name” were included in the operation request, that would be a change to existing behavior precedent. A new operation with the appropriate semantics was decided to be the most efficient way to add this facility to the IPP ecosystem.
The reasons I have heard thus far are:
Historical precedent from using Get-Printer-Attributes in many different IPP workflows guides us away from overloading its use for per-user print policy
The Printer cannot change or "filter" the set of "Printer Attributes" it includes in its Get-Printer-Attributes response based on the "requesting-user-name" operation attribute optionally supplied by the Client in the Get-Printer-Attributes operation because this would violate the expectations of the definition of Get-Printer-Attributes in RFC 2911 / RFC 8011 (section 4.2.5). (In particular, it isn't clear to me whether "requesting-user-name" could legitimately cause the Printer to change the values it returns in Get-Printer-Attributes. Reading sections 4.2.5, 5.4.2, and 9.1 in RFC 8011 didn't paint a clear picture.)
Adding a new optional operation attribute for Get-Printer-Attributes might be functionally equivalent in some cases to creating a new Get-User-Printer-Attributes operation, but using a new operation will help us avoid changing or updating core specifications (e.g. RFC 8011).
???
Thoughts? Any other ambiguity that needs to be covered?
Smith
/**
Smith Kennedy
Wireless Architect - Client Software - IPG-PPS
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
Chair, IEEE ISTO Printer Working Group
HP Inc.
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170412/0bfbffa9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170412/0bfbffa9/attachment.p7s>