attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mike,<div class=""><br class=""></div><div class="">Sorry for not reviewing them sooner. I have the following feedback on these two documents, which we can review in a future IPP WG meeting:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf</a><br class=""></blockquote><br class=""></div><div class=""><div class="">Page 11, line 311: "Bonjour Printing Specification version 1.2 [BONJOUR]" should be "1.2.1"</div></div><div class=""><div class=""><br class=""></div><div class="">Page 19, line 574: "Bonjour Printing Specification version 1.2 [BONJOUR]" should be "1.2.1". Other instances say simply "Bonjour Printing Specification [BONJOUR]" and those seem to be OK.</div></div><div class=""><br class=""></div><div class="">Page 22, Table 3: Should we be defining a new "ippe" key that specifies the version of IPP Everywhere™ supported? Or one that duplicates "ipp-features-supported" since that attribute's value contains arguably valuable values for filtering?</div><div class=""><br class=""></div><div class="">Page 23, line 634: Add 'oauth' for OAuth2 authentication method</div><div class=""><br class=""></div><div class="">Page 26, lines 709-710: I could be wrong but won't requiring TLS 1.3 for IPP Everywhere™ 1.1 cause backward compatibility issues? Maybe require 1.2 and recommend 1.3?</div><div class=""><br class=""></div><div class="">Page 26, lines 709-710: the IPP Everywhere Self Certification spec has been testing for support of HTTP Upgrade to TLS [RFC2817] throughout the 1.0 certification program, so I think we can retroactively add that here to make it clear it is a requirement.</div><div class=""><br class=""></div><div class="">Page 27, Tables 4 and 5: Guessing we should not be replacing all the instances of RFC 8011 with STD92 because we want to point the reader to the specific RFC defining these? But STD92 replaced the reference to RFC 8011 in the references, so maybe all of these should be changed too.</div><div class=""><br class=""></div><div class="">Page 27, Table 5: Do we want to add a table that lists the "RECOMMENDED" attributes that we expect might go into a later revision of IPP Everywhere, and state that intention? I had wondered about mentioning "job-password-repertoire" etc. and we cannot make that REQUIRED for backward compatibility. Others I might add would be "jpeg-features-supported", "jpeg-k-octets-supported", "jpeg-x-dimension-supported", "jpeg-y-dimension-supported", "pdf-features-supported"</div><div class="">"pdf-k-octets-supported", and "pdf-versions-supported" (all defined after IPP Everywhere™ 1.0 and so cannot be required for backward compatibility reasons)</div><div class=""><br class=""></div><div class="">Page 37, line 938: "Color Printers MUST support documents conforming to the JPEG..." --> "Color Printers MUST and monochrome Printers SHOULD support documents conforming to the JPEG..."</div><div class=""><br class=""></div><div class=""><div class="">Page 40, lines 972-973: Should we be adding "ipp-everywhere-1.1"?</div></div><div class=""><br class=""></div><div class="">Page 41, line 998-1000: Clarify that "address" here means an IP address or IPv4/IPv6 address to be more precise.</div><div class=""><br class=""></div><div class="">Page 43, various: Replace instances of "section 0" with the actual section that needs to be referenced.</div><div class=""><br class=""></div><div class="">Page 43, lines 1057-1064: Would it be reasonable to add "Get-User-Printer-Attributes" to this? How widely is this use case implemented? I also wonder if we shouldn't refactor the IPP Everywhere™ specification so that it becomes a "core specification" and defines how optional "IPP Everywhere™ features" are defined? We could then move the optional features such as ICC-based color management and Paid Print out to their own "IPP Everywhere™ feature document" and have a separate add-on certification for that feature? I mentioned before how I'm concerned think, now that IPP Everywhere™ is getting traction in the marketplace, we might want to re-consider how we define the core vs. optional features.</div><div class=""><br class=""></div><div class="">Page 46, line 1128: Add another "ipp-everywhere-1.1" keyword?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf</a><br class=""></blockquote><br class=""></div><div class="">Page 15-16, lines 339-364: References to the PWG Raster sample files and URLs were mostly deleted - the only ones left are 720dpi. And that points to the old URLs and broken files - they should point to the ones recently generated (20180607).</div><div class=""><br class=""></div><div class="">Page 17, line 375: "support HTTP Upgrade to TLS" --> "support HTTP Upgrade to TLS [RFC2817]". Or should this document rather be citing the conformance requirements from PWG 5100.14? That way that will avoid inconsistency between the two documents (as had occurred with 1.0 and RFC 2817 requirement).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">
<div dir="auto" style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless & Standards Architect - 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=""></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Jul 4, 2018, at 1:22 AM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">All,<br class=""><br class="">I have posted updated prototype drafts of the IPP Everywhere v1.1 and IPP Everywhere Printer Self-Certification Manual v1.1 documents to:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704.docx" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704.docx</a><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704.pdf<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704.docx<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704.pdf<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf<br class=""><br class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer<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=""></div></div></blockquote></div><br class=""></div></body></html>