Hi Mike,
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:
>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf>
Page 11, line 311: "Bonjour Printing Specification version 1.2 [BONJOUR]" should be "1.2.1"
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.
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?
Page 23, line 634: Add 'oauth' for OAuth2 authentication method
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?
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.
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.
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"
"pdf-k-octets-supported", and "pdf-versions-supported" (all defined after IPP Everywhere™ 1.0 and so cannot be required for backward compatibility reasons)
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..."
Page 40, lines 972-973: Should we be adding "ipp-everywhere-1.1"?
Page 41, line 998-1000: Clarify that "address" here means an IP address or IPv4/IPv6 address to be more precise.
Page 43, various: Replace instances of "section 0" with the actual section that needs to be referenced.
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.
Page 46, line 1128: Add another "ipp-everywhere-1.1" keyword?
>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf>
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).
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).
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.
*/
> On Jul 4, 2018, at 1:22 AM, Michael Sweet <msweet at apple.com> wrote:
>> All,
>> I have posted updated prototype drafts of the IPP Everywhere v1.1 and IPP Everywhere Printer Self-Certification Manual v1.1 documents to:
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704.docx>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704.pdf>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve11-20180704-rev.pdf>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704.docx>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704.pdf>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert11-20180704-rev.pdf>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180718/993623f1/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/20180718/993623f1/attachment.p7s>