Ira,
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.
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.
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.
> On Jan 15, 2017, at 10:36 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Mike and Smith,
>> I suggest that the parameters and attributes of such an operation
>> are exactly the same as Get-Printer-Attributes, except that the User
> identity MUST be authenticated and MUST be authorized (via some
> out-of-band manner) to perform the new operation.
>> It might be appropriate to abandon the "limit" and friends and also
> to say that you can't read "media-col-database" with this operation.
> It might also be appropriate to abandon "requested-attributes" and
> just return all the simple attributes and "xxx-supported" attributes.
>> Smith - please think about the use case(s) and propose by email
> some more details for discussion as a next step.
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto: blueroofmusic at gmail.com> Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Sun, Jan 15, 2017 at 9:08 AM, Michael Sweet <msweet at apple.com> wrote:
> Ira,
>> 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.
>> In the case of this operation, we simply (IMHO) do not have enough information to decide.
>>> Sent from my iPad
>> On Jan 14, 2017, at 3:51 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>>> Hi Mike,
>>>> Thanks for those clarifications.
>>>> I suggest the proposed new operation be named "Get-User-Printer-Attributes"
>> to show the authenticated User dependence and the otherwise similarity to
>> the classic "Get-Printer-Attributes" operation.
>>>> I agree that a brief whitepaper is appropriate.
>>>> I have strong reservations about adding a new operation (as opposed to some
>> attributes) simply via IPP WG approval for IANA registration. We should talk
>> more about where this operation might be published.
>>>> Cheers,
>> - Ira
>>>>>>>> Ira McDonald (Musician / Software Architect)
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music / High North Inc
>>http://sites.google.com/site/blueroofmusic>>http://sites.google.com/site/highnorthinc>> mailto: blueroofmusic at gmail.com>> Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
>> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>>>> On Sat, Jan 14, 2017 at 1:45 PM, Michael Sweet <msweet at apple.com> wrote:
>> Ira,
>>>>> On Jan 14, 2017, at 11:45 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>>>>>> Hi Smith,
>>>>>> I agree with Mike that this operation should not be added to IPP System
>>> Service.
>>>>>> I question the need for this operation.
>>>>>> An IPP job service implementation can filter a Get-Printer-Attributes
>>> response already based on authenticated user identity.
>>>> 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...
>>>> 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.
>>>>> What new functionality would this putative operation add to IPP?
>>>> 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.
>>>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer
>>>>>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer