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 <mailto: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) <mailto:smith.kennedy at hp.com>
>> Sent: Monday, November 6, 2017 6:26 PM
>> To: Michael Sweet <mailto:msweet at apple.com>
>> Cc: William A Wagner <mailto:wamwagner at comcast.net>; PWG IPP WG Reflector <mailto: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 <mailto: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 <mailto:wamwagner at comcast.net> wrote:
>>>> Hi Smith,
>> A few comments:
>> Although the standard compliance terms are used, (MUST, SHOULD, etc.) Section 2 does not include the standard reference defining these terms.
>> 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) <mailto:smith.kennedy at hp.com>
>> Sent: Saturday, November 4, 2017 12:44 AM
>> To: PWG IPP WG Reflector <mailto: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.pdf>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103.odt <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.pdf>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippgupa-20171103-rev.odt <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 <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>>>> _________________________________________________________
>> 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/20171107/cb508068/attachment.html>