Smith,
Another reason for not overloading the existing Get-Printer-Attributes operation is that IPP doesn't support having one operation with multiple semantics or access policies. For example, that's why we have "Cancel-Jobs" for operators and administrators and "Cancel-My-Jobs" for users. Similarly, the System service has "Get-Printers" for users and "Get-System-Attributes" for operators and administrators.
> On Apr 12, 2017, at 2:31 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> Hi there,
>> In my Get-User-Printer-Attributes white paper (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.
> */
>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer