attachment

<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>You are suggesting this new Get-User-Printer-Attributes operation<br></div>does NOT require authentication and authorization of the Client?<br><br></div>If that's right, what value does this operation offer over the classic<br></div>Get-Printer-Attributes (with perhaps an "ipp-features-supported"<br></div>tag that says it supports User-based filtering)?<br><br></div>My reading of original RFC 2911 was that *any* operation could do<br></div>filtering based on the requesting user (i.e., Get-Jobs).<br><br></div>Confused,<br></div>- Ira<br><br><div><div><br><div><div><br></div></div></div></div></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 8:22 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>
<br>
The point of the operation is for a Client UI to be able to show the attributes and values the user is allowed to select, which necessarily includes things like "media-col-database".  The user may be identified through requesting-user-name, authenticated user name, source IP, client certificate, etc., with the details of any filtering being an implementation detail.<br>
<br>
Defining "Get-User-Supported-Values" as analogous to "Get-Printer-Attributes" except that the operation filters the attributes and values based on the (most authenticated) user identity keeps things relatively simple and avoids future "oh shit" moments when we realize we added too many restrictions.  And for conformance we'll want to require Client and Printer support for authentication but not require a Printer to use authentication, i.e., an allowed configuration is to just rely on the requesting-user-name, source IP, etc.<br>
<br>
Ideally, a Printer should not advertise the new operation unless it will be performing some sort of filtering - that allows for simple client-side optimizations when printer capabilities are not limited by user or other Client metadata.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Jan 15, 2017, at 10:36 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike and Smith,<br>
><br>
> I suggest that the parameters and attributes of such an operation<br>
><br>
> are exactly the same as Get-Printer-Attributes, except that the User<br>
> identity MUST be authenticated and MUST be authorized (via some<br>
> out-of-band manner) to perform the new operation.<br>
><br>
> It might be appropriate to abandon the "limit" and friends and also<br>
> to say that you can't read "media-col-database" with this operation.<br>
> It might also be appropriate to abandon "requested-attributes" and<br>
> just return all the simple attributes and "xxx-supported" attributes.<br>
><br>
> Smith - please think about the use case(s) and propose by email<br>
> some more details for discussion as a next step.<br>
><br>
> Cheers,<br>
> - Ira<br>
><br>
><br>
> 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 href="http://sites.google.com/site/blueroofmusic" rel="noreferrer" target="_blank">http://sites.google.com/site/<wbr>blueroofmusic</a><br>
> <a href="http://sites.google.com/site/highnorthinc" rel="noreferrer" target="_blank">http://sites.google.com/site/<wbr>highnorthinc</a><br>
> mailto: <a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><br>
> Jan-April: 579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094">734-944-0094</a><br>
> May-Dec: PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434">906-494-2434</a><br>
><br>
><br>
> On Sun, Jan 15, 2017 at 9:08 AM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> wrote:<br>
> Ira,<br>
><br>
> The registration policy for operations is Expert Review, so a full specification is not technically required. That said, we (the designated experts) and the IPP workgroup can require sufficient clarity in the definition of the operation before such a registration is approved, or to require a spec of the scope of the registration is (in the opinion of the WG or designated experts) too broad for a simple registration.<br>
><br>
> In the case of this operation, we simply (IMHO) do not have enough information to decide.<br>
><br>
><br>
> Sent from my iPad<br>
><br>
> On Jan 14, 2017, at 3:51 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
>> Hi Mike,<br>
>><br>
>> Thanks for those clarifications.<br>
>><br>
>> I suggest the proposed new operation be named "Get-User-Printer-Attributes"<br>
>> to show the authenticated User dependence and the otherwise similarity to<br>
>> the classic "Get-Printer-Attributes" operation.<br>
>><br>
>> I agree that a brief whitepaper is appropriate.<br>
>><br>
>> I have strong reservations about adding a new operation (as opposed to some<br>
>> attributes) simply via IPP WG approval for IANA registration.  We should talk<br>
>> more about where this operation might be published.<br>
>><br>
>> Cheers,<br>
>> - Ira<br>
>><br>
>><br>
>><br>
>> 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 href="http://sites.google.com/site/blueroofmusic" rel="noreferrer" target="_blank">http://sites.google.com/site/<wbr>blueroofmusic</a><br>
>> <a href="http://sites.google.com/site/highnorthinc" rel="noreferrer" target="_blank">http://sites.google.com/site/<wbr>highnorthinc</a><br>
>> mailto: <a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><br>
>> Jan-April: 579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094">734-944-0094</a><br>
>> May-Dec: PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434">906-494-2434</a><br>
>><br>
>><br>
>> On Sat, Jan 14, 2017 at 1:45 PM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> wrote:<br>
>> Ira,<br>
>><br>
>>> On Jan 14, 2017, at 11:45 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Smith,<br>
>>><br>
>>> I agree with Mike that this operation should not be added to IPP System<br>
>>> Service.<br>
>>><br>
>>> I question the need for this operation.<br>
>>><br>
>>> An IPP job service implementation can filter a Get-Printer-Attributes<br>
>>> response already based on authenticated user identity.<br>
>><br>
>> From a practical perspective, Get-Printer-Attributes is never authenticated because clients do not support that usage. So no, we can't just use Get-Printer-Attributes...<br>
>><br>
>> Right now clients need to use Validate-Job (which *is* authenticated for printers that do authentication of print jobs) in order to validate the choices a user has made.<br>
>><br>
>>> What new functionality would this putative operation add to IPP?<br>
>><br>
>> It would be defined as an authenticated version of Get-Printer-Attributes that explicitly filters the values based on the authenticated identity of the requestor.<br>
>><br>
>> ______________________________<wbr>___________________________<br>
>> Michael Sweet, Senior Printing System Engineer<br>
>><br>
>><br>
><br>
<br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div>