[IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow available for review

[IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow available for review

[IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow available for review

Ira McDonald blueroofmusic at gmail.com
Tue Nov 7 16:29:47 UTC 2017


Hi,

+1 to Mike's comment.  Make it declarative ("is") rather than normative.
If filtering wasn't performed, then this new operation would be useless.

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 Tue, Nov 7, 2017 at 10:21 AM, Michael Sweet <msweet at apple.com> wrote:

> Smith,
>
> I don't see how we can validate conformance for this MUST, particularly
> when the default (open) policy will return the same attributes and values
> as Get-Printer-Attributes.  I suggest we simply declare the intended
> behavior:
>
>     "... the response is filtered based on the most authenticated user."
>
>
> On Nov 6, 2017, at 11:56 PM, Kennedy, Smith (Wireless Architect) <
> smith.kennedy at hp.com> wrote:
>
> Ah, good catch. I suggest we replace "can" with "shall" in that first
> paragraph:
>
> *4  Get-User-Printer-Attributes Operation*
> The Get-User-Printer-Attributes operation is semantically analogous to the
> Get-Printer-Attributes operation [RFC8011] but the response MUST be
> filtered based on the most authenticated user. The authenticated user (see
> section 9.3 of [RFC8011]) performing this operation MUST be either a User
> permitted to create Print Jobs or an Operator or Administrator of the
> Printer.  Otherwise, the Printer MUST reject the operation and return
> 'client-error-forbidden', 'client-error-not-authenticated', or
> 'client-error-not-authorized' as appropriate.
>
> The Client MUST be prepared to handle an HTTP authentication challenge in
> response to a Get-User-Printer-Attributes operation request. If the Client
> initiates the Get-User-Printer-Attributes operation over a non-TLS
> connection, the Client MUST be prepared to receive an HTTP 426 response to
> upgrade the connection to TLS [RFC2817]. See [RFC8010] and [RFC8011] for
> authentication methods that require a secure channel.
>
> A Printer MUST support all the same operation attributes for a
> Get-User-Printer-Attributes operation that it supports with a
> Get-Printer-Attributes operation, including those a Client can use to
> request a filtered response: “document-format” [RFC8011]; “first-index”
> [PWG5100.13]; “limit” [PWG5100.13]; and any of the attributes named by
> “printer-get-attributes-supported” [PWG5100.13].
>
>
>
>
>
> On Nov 6, 2017, at 9:16 PM, wamwagner at comcast.net wrote:
>
> Looks good…except I am trying to remember why we weasleword and say that
> the response “can” be filtered, whereas we use standard compliance terms
> elsewhere. I vaguely recall this being discussed, but the implication is
> that a printer could  respond without filtering. If that were the intent, I
> expect that we would use ‘MAY’.
> Thanks, Bill Wagner
>
> *From: *Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com>
> *Sent: *Monday, November 6, 2017 6:26 PM
> *To: *Michael Sweet <msweet at apple.com>
> *Cc: *William A Wagner <wamwagner at comcast.net>; PWG IPP WG Reflector
> <ipp at pwg.org>
> *Subject: *Re: [IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow
> available for review
>
> How about this for an update to section 4:
>
>
> *4  Get-User-Printer-Attributes Operation*
> The Get-User-Printer-Attributes operation is semantically analogous to the
> Get-Printer-Attributes operation [RFC8011] but the response can be filtered
> based on the most authenticated user. The authenticated user (see section
> 9.3 of [RFC8011]) performing this operation MUST be either a User permitted
> to create Print Jobs or an Operator or Administrator of the Printer.
> Otherwise, the Printer MUST reject the operation and return
> 'client-error-forbidden', 'client-error-not-authenticated', or
> 'client-error-not-authorized' as appropriate.
>
> The Client MUST be prepared to handle an HTTP authentication challenge in
> response to a Get-User-Printer-Attributes operation request. If the Client
> initiates the Get-User-Printer-Attributes operation over a non-TLS
> connection, the Client MUST be prepared to receive an HTTP 426 response to
> upgrade the connection to TLS [RFC2817]. See [RFC8010] and [RFC8011] for
> authentication methods that require a secure channel.
>
> A Printer MUST support all the same operation attributes for a
> Get-User-Printer-Attributes operation that it supports with a
> Get-Printer-Attributes operation, including those used by a Client to
> request a filtered response: “document-format” [RFC8011]; “first-index”
> [PWG5100.13]; “limit” [PWG5100.13]; and any of the attributes named by
> “printer-get-attributes-supported” [PWG5100.13].
>
>
>
>
> Smith
>
>
>
> On Nov 6, 2017, at 2:49 PM, Michael Sweet <msweet at apple.com> wrote:
>
> Smith/Bill,
>
> Perhaps we can use something in section 4 like the following:
>
>
> Access Rights: The authenticated user (see section 9.3 of [RFC8011])
> performing this operation must be either a User permitted to create Print
> Jobs or an Operator or Administrator of the Printer.  Otherwise, the
> Printer MUST reject the operation and return 'client-error-forbidden',
> 'client-error-not-authenticated', or 'client-error-not-authorized' as
> appropriate.
>
>
> That mirrors the wording from other operations defined in RFC 8011 and
> other places and makes it clear that the operation is provided for Users
> that want to print.
>
> Thoughts?
>
> (As for the format debate, I always have used the PDF versions for review
> because Word does not preserve the layout of text - local fonts and margins
> for your last used printer will mess things up every time...)
>
>
>
> On Nov 6, 2017, at 4:08 PM, wamwagner at comcast.net wrote:
>
> Hi Smith,
> A few comments:
>
>    1. Although the standard compliance terms are used, (MUST, SHOULD,
>    etc.) Section 2 does not include the  standard reference defining these
>    terms.
>    2. Section 4 line 150 (in the non-redline pdf): “… Attributes
>    operation [RFC8011] but can be authenticated …” suggests that the operation
>    is authenticated, which I don’t think is a typical way of indicating that
>    the operation may prompt a sequence to authenticate the user. Prehaps
>    rewording to “  … Attributes operation [RFC8011] except that the response
>    can be filtered based on the most authenticated user and to effect this,
>    the operation can prompt a sequence to authenticate the user.” Or something
>    like that.
>
>
> On a more general topic, for whatever reason, the PWG has typically
> provided drafts in MS Word and PDF formats. The ‘odt’ format is not
> compatible with , at least, my version of MS Word to the extent that
> opening it in MS Word produces a incorrectly displayed document subject to
> extensive editorial comments. The Process states “ Internal working
> versions of PWG documents should be available in an agreed upon, widely
> available word processing format, to provide for collaboration between
> document editors and contributors. For example, Microsoft WORD and HTML are
> common
> revisable formats in use, today. “ For those not familiar with your use of
>  Open Office,  perhaps it would be better to include a note in your draft
> announcements that the .odt extension files should be viewed with Apache
> Open Office, not MS Word.
>
> Thanks, Bill Wagner
>
>
>
> *From: *Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com>
> *Sent: *Saturday, November 4, 2017 12:44 AM
> *To: *PWG IPP WG Reflector <ipp at pwg.org>
> *Subject: *[IPP] Updated stable draft of IPP Get-User-Printer-Attributes
> isnow available for review
>
> Greetings,
>
> An updated stable draft of IPP Get-User-Printer-Attributes is now
> available for review:
>
> https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103.pdf
> https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103.odt
> https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103-rev.pdf
> https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103-rev.odt
>
> Changes are minor:
> * Fixed a broken bookmark cross reference in section 3.1
> * Fixed a few instances of passive voice
> * Some other editorial fixes
>
> Cheers,
> Smith
>
> /**
>     Smith Kennedy
>     Wireless & Standards Architect - IPG-PPS
>     Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC
> Forum / USB-IF
>     Chair, IEEE ISTO Printer Working Group
>     HP Inc.
> */
>
>
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171107/841c477f/attachment.html>


More information about the ipp mailing list