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

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

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

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Tue Oct 10 20:34:58 UTC 2017


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 <msweet at apple.com> wrote:
> 
> 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) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> 
>> 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.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
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171010/dc14f2dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171010/dc14f2dd/attachment.p7s>


More information about the ipp mailing list