attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Mike,<div class=""><br class=""></div><div class="">I'm fine with all of these changes. Update to be posted soon. </div><div class=""><br class=""><div class="">
Smith<br class=""><br class=""><br class="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Oct 9, 2017, at 5:25 PM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Smith,<div class=""><br class=""></div><div class="">Some comments:</div><div class=""><br class=""></div><div class="">- 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...</div><div class="">- Section 1:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- Line 58: "This document DEFINES a new" (we are beyond proposing :)</div><div class="">- Line 60: "is semantically ANALOGOUS to ..." (not identical since the existing operation ignores the User)</div><div class="">- 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...</div></blockquote><div class="">- Section 3 and 3.1: I think we can drop the "for IPP Get-User-Printer-Attributes" from the section titles</div><div class="">- Section 3.1:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- Line 84: "applications, and so forth" (add comma before "and")</div><div class="">- Line 84: "method that is in-band of IPP" seems awkward. Maybe "method using IPP"?</div></blockquote>- Section 3.5:<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- General: Look at the current reg-template document for the standard list of design requirements</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- <a href="http://ftp.pwg.org/pub/pwg/general/wd/reg-template-20170825.docx" class="">http://ftp.pwg.org/pub/pwg/general/wd/reg-template-20170825.docx</a></div></blockquote></blockquote><div class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- Line 140: "1. Define an IPP operation to allow a Client to obtain supported Printer capabilities for a given User."</div><div class="">- Line 143: "2. Document interoperability requirements for Clients and Printers." (or something like that)</div><div class="">- Line 146: Not sure we actually do #3, and thought we had decided against it...</div><div class="">- 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?)</div><div class="">- Line 151: See current wording in the template</div><div class="">- Line 154: "could inform the creation of a high quality Client user experience"? Maybe "and provide guidance for Client user interfaces" instead?</div></blockquote>- Section 4:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- "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)</div></blockquote><div class=""><div class=""><div class="">- Section 4.1.1:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Line 172: The TLS requirement should be conditional for authentication methods that require a secure channel.</div><div class="">- Section 4.1.1.1:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Lines 185-190: "requesting-user-name" and "requesting-user-uri" are duplicated below on lines 191 and 192</div><div class="">- Section 6:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Line 245: Make conditional for authentication methods that require a secure channel.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class="">On Oct 5, 2017, at 10:54 AM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:<br class=""><br class="">Greetings,<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.pdf" class="">https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.pdf</a><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.odt" class="">https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-userop-20170817.odt</a><br class=""><br class="">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.<br class=""><br class="">Thanks for your assistance!<br class=""><br class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">ipp mailing list<br class="">ipp@pwg.org<br class="">https://www.pwg.org/mailman/listinfo/ipp<br class=""></blockquote><br class=""><div class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer<br class=""></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></body></html>