attachment

<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>Smith plans to bring a whitepaper and/or slides on this new operation<br></div>(tentatively to be named Get-User-Printer-Attributes for clarity) to the <br>PWG F2F meeting in February.<br></div><br></div>On reflection, I suggest that perhaps we *should* add this operation<br></div>to IPP System Service to enhance IPP Client interworking with IPP <br>Printers (job services).<br><br></div><div>Mike has convinced me that the operation should look just like the<br></div><div>existing Get-Printer-Attributes operation (input/output attributes),<br></div><div>but allow the Printer (if so configured) to authenticate the Client's<br></div><div>requesting user identity and always require filtering of the response<br></div><div>based on the most authenticated requesting user identity.<br><br></div><div>Cheers,<br></div><div>- Ira<br></div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094<br>May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Jan 15, 2017 at 10:49 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ira,<br>
<span class=""><br>
> On Jan 15, 2017, at 8:45 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
</span><span class="">> You are suggesting this new Get-User-Printer-Attributes operation<br>
> does NOT require authentication and authorization of the Client?<br>
<br>
</span>No, I am suggesting that this new operation *may* not require Client authentication, depending on the configuration of the Printer, just as Cancel-Job, Cancel-All-Jobs, Cancel-My-Jobs, Create-Job, Get-Job-Attributes, Get-Jobs, Print-Job, Print-URI, Send-Document, Send-URI, and Validate-Job do.<br>
<br>
FWIW, Get-Printer-Attributes is basically the only operation in IPP/1.1 (RFC 2911/8011) that does not say anything about authentication, the most authenticated identity, authorization rights, or filtering of attributes or values based on the most authenticated identity.  And that makes it impossible to add authentication requirements without breaking a lot of (read: all) Clients.<br>
<span class=""><br>
> If that's right, what value does this operation offer over the classic<br>
> Get-Printer-Attributes (with perhaps an "ipp-features-supported"<br>
> tag that says it supports User-based filtering)?<br>
<br>
</span>It makes it consistent with the Job operations.<br>
<span class=""><br>
> My reading of original RFC 2911 was that *any* operation could do<br>
> filtering based on the requesting user (i.e., Get-Jobs).<br>
<br>
</span>No, there is discussion of authentication and the most authenticated user/identity, but specific requirements and filtering are discussed in the description of each operation.  In particular, Get-Jobs and Get-Job-Attributes talk about filtering based on security policy, while Get-Printer-Attributes only talks about filtering based on document format (and basically says everyone gets to see the same information).<br>
<br>
This is arguably a bug in the original IPP specs, but there is nothing we can do to fix Get-Printer-Attributes now.<br>
(but there are advantages to having a public/guest "get" operation for discovering what a Printer will require, e.g., "uri-authentication-supported" values...)<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div>