Subject: [IPP] Request to IPP WG to review latest IPP Get-User-Printer-Attributes and reply with any objections

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 5 Oct 2017 14:54:06 +0000

Greetings,

To move IPP Get-User-Printer-Attributes forward, one of my action items from the last IPP WG conference call was to ask the IPP WG community to please look over the current "clean" draft of IPP Get-User-Printer-Attributes, and reply with concerns or objections, if any. The latest clean draft is here:

	https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.pdf
	https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.odt

We are still working on finalizing the IPP Registration process in a PWG policy document, but we don't need to wait for that to be completed while soliciting feedback.

Thanks for your assistance!

Smith

/**
   Smith Kennedy
   Wireless Architect - Client Software - IPG-PPS
   Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
   Chair, IEEE ISTO Printer Working Group
   HP Inc.
*/

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - 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: Michael Sweet <[email-masked]>
Date: Mon, 09 Oct 2017 19:25:49 -0400

Smith,

Some comments:

- At some point (probably the next draft) we should change the status to "Stable" since the definition is stable and we are largely just painting the bike shed at this point...
- Section 1:
- Line 58: "This document DEFINES a new" (we are beyond proposing :)
- Line 60: "is semantically ANALOGOUS to ..." (not identical since the existing operation ignores the User)
- Lines 61-63: I thought we had agreed that the Printer MAY (or can) respond with an authentication challenge, so Clients must be prepared to deal with that...  Also not sure you need to provide the play-by-play of when the Client will get the response...
- Section 3 and 3.1: I think we can drop the "for IPP Get-User-Printer-Attributes" from the section titles
- Section 3.1:
- Line 84: "applications, and so forth" (add comma before "and")
- Line 84: "method that is in-band of IPP" seems awkward. Maybe "method using IPP"?
- Section 3.5:
- General: Look at the current reg-template document for the standard list of design requirements
- http://ftp.pwg.org/pub/pwg/general/wd/reg-template-20170825.docx <http://ftp.pwg.org/pub/pwg/general/wd/reg-template-20170825.docx>
- Line 140: "1. Define an IPP operation to allow a Client to obtain supported Printer capabilities for a given User."
- Line 143: "2. Document interoperability requirements for Clients and Printers." (or something like that)
- Line 146: Not sure we actually do #3, and thought we had decided against it...
- Line 150: I think this should be unnecessary, but perhaps something to discuss at the next IPP WG concall (and maybe we add something to the templates?)
- Line 151: See current wording in the template
- Line 154: "could inform the creation of a high quality Client user experience"? Maybe "and provide guidance for Client user interfaces" instead?
- Section 4:
- "RFC 8011 (and its predecessors) do not specify that the Get-Printer-Attributes operation can be authenticated, and explicitly does not specify that the most authenticated user name has any effect on the semantics of the operation (unlike the various Job-related operations). Since changing the semantics of the existing Get-Printer-Attributes operation would break existing Clients and require a new IPP major version number, this document defines the semantically analogous operation Get-User-Printer-Attributes." (or something like that)
- Section 4.1.1:
	- Line 172: The TLS requirement should be conditional for authentication methods that require a secure channel.
- Section 4.1.1.1:
	- Lines 185-190: "requesting-user-name" and "requesting-user-uri" are duplicated below on lines 191 and 192
- Section 6:
	- Line 245: Make conditional for authentication methods that require a secure channel.

> On Oct 5, 2017, at 10:54 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 10 Oct 2017 20:34:58 +0000

Hi Mike,

I'm fine with all of these changes. Update to be posted soon. 

Smith

> On Oct 9, 2017, at 5:25 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
> Some comments:
> 
>> On Oct 5, 2017, at 10:54 AM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Greetings,
>> 
>> 	https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.pdf <https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.pdf>