attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi there,<div class=""><br class=""></div><div class="">In my Get-User-Printer-Attributes white paper (<a href="https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170404.pdf" class="">https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170404.pdf</a>) 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):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">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.</div></blockquote><div class=""><br class=""></div><div class="">The reasons I have heard thus far are:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Historical precedent from using Get-Printer-Attributes in many different IPP workflows guides us away from overloading its use for per-user print policy</li><li class="">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). <font color="#ff2600" class="">(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.)</font></li><li class="">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).</li><li class="">???</li></ol><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><div class="">Thoughts? Any other ambiguity that needs to be covered?</div></div><div class=""><br class=""></div><div class=""><div class="">
Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class="">
</div>
<br class=""></div></body></html>