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.
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
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:
>> 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
> more about where this operation might be published.
> - 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:
>>>> On Jan 14, 2017, at 11:45 AM, Ira McDonald <blueroofmusic at gmail.com>
>>>> Hi Smith,
>>>> I agree with Mike that this operation should not be added to IPP System
>>>> 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
>>>>>-------------- next part --------------
An HTML attachment was scrubbed...