Subject: [IPP] Updated stable draft of IPP Get-User-Printer-Attributes is now available for review

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Sat, 4 Nov 2017 04:44:34 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: <[email-masked]>
Date: Mon, 6 Nov 2017 16:08:05 -0500

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)
Sent: Saturday, November 4, 2017 12:44 AM
To: PWG IPP WG Reflector
Subject: [IPP] Updated stable draft of IPP Get-User-Printer-Attributes isnow available for review

Greetings,

Changes are minor:

Cheers,
Smith

/**
    Smith Kennedy

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Nov 2017 16:49:36 -0500

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, [email-masked] 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.
>  
> From: Kennedy, Smith (Wireless Architect) <mailto:[email-masked]>
> To: PWG IPP WG Reflector <mailto:[email-masked]>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 6 Nov 2017 23:26:21 +0000

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 <[email-masked]> wrote:
> 
> Smith/Bill,
> 
>> On Nov 6, 2017, at 4:08 PM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> Hi Smith,
>> A few comments:
>> 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:
>> [email-masked] <mailto:[email-masked]>
>> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

---

From: <[email-masked]>
Date: Mon, 6 Nov 2017 23:16:15 -0500

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)
Sent: Monday, November 6, 2017 6:26 PM
To: Michael Sweet
Cc: William A Wagner; PWG IPP WG Reflector
Subject: Re: [IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow available for review

Smith

Smith/Bill,

Thoughts?

Hi Smith,
A few comments:

Thanks, Bill Wagner

 
Greetings,

 
Changes are minor:
 
Cheers,
Smith
 
/**
    Smith Kennedy

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 7 Nov 2017 04:56:58 +0000

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.

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, [email-masked] wrote:
> 
> To: Michael Sweet <mailto:[email-masked]>
> Cc: William A Wagner <mailto:[email-masked]>; PWG IPP WG Reflector <mailto:[email-masked]>
> On Nov 6, 2017, at 2:49 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Smith/Bill,
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 07 Nov 2017 10:21:54 -0500

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) <[email-masked]> wrote:
> 
>> On Nov 6, 2017, at 9:16 PM, [email-masked] <mailto:[email-masked]> wrote:
>>

---

From: Ira McDonald <[email-masked]>
Date: Tue, 7 Nov 2017 11:29:47 -0500

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: [email-masked]
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 <[email-masked]> 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:
>
> *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].
>
>
>
>
>
> 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) <[email-masked]>
> *Sent: *Monday, November 6, 2017 6:26 PM
> *To: *Michael Sweet <[email-masked]>
> *Cc: *William A Wagner <[email-masked]>; PWG IPP WG Reflector
> <[email-masked]>
> *Subject: *Re: [IPP] Updated stable draft of IPP Get-User-Printer-Attributesisnow
> available for review
>
> *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
>
>
>
> 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...)
>
>
>
>    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) <[email-masked]>
> *Sent: *Saturday, November 4, 2017 12:44 AM
> *To: *PWG IPP WG Reflector <[email-masked]>
> *Subject: *[IPP] Updated stable draft of IPP Get-User-Printer-Attributes
> isnow available for review
>
> Greetings,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 7 Nov 2017 19:45:39 +0000

Sounds good. I'll make that change. I plan on posting a new draft later today for both Presets and GUPA to include the absent section 2 subsections.

Smith

> On Nov 7, 2017, at 9:29 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Tue, Nov 7, 2017 at 10:21 AM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> Smith,
> 
>> On Nov 6, 2017, at 11:56 PM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>>