Hi Mike,
You are suggesting this new Get-User-Printer-Attributes operation
does NOT require authentication and authorization of the Client?
If that's right, what value does this operation offer over the classic
Get-Printer-Attributes (with perhaps an "ipp-features-supported"
tag that says it supports User-based filtering)?
My reading of original RFC 2911 was that *any* operation could do
filtering based on the requesting user (i.e., Get-Jobs).
Confused,
- 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/blueroofmusichttp://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 8:22 PM, Michael Sweet <msweet at apple.com> wrote:
> 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
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170115/d47df931/attachment.html>