Smith,
Thanks for the feedback. Responses are inline below...
> On Jul. 18, 2018, at 8:56 AM, Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com> wrote:
>> 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?
Given that we are still on the same major version and the limited space available for TXT record keys, I'd argue that an "ippe" key is not yet necessary (maybe if we ever get to v2).
As for "ipp-features-supported", what features were you thinking of as valuable for filtering?
> Page 23, line 634: Add 'oauth' for OAuth2 authentication method
While we haven't yet added 'oauth' to CUPS, I agree this should be added.
> 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?
We aren't requiring TLS at all, just recommending that it be supported with the most recent version of TLS.
> 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.
IPP/1.1 has required HTTP Upgrade (RFC 2817) support if TLS is supported - this is stated in RFC 2910, RFC 7472, and RFC 8010, but we can certainly restate it here if you like.
> 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.
I think we should say "STD 92" everywhere.
> 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)
Let's discuss this further; I like the idea of having a section of recommended attributes but I'm not sure how we'd do it without making it sound like "future versions will require X."
> 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..."
OK.
> Page 40, lines 972-973: Should we be adding "ipp-everywhere-1.1"?
Let's talk about this, but my gut reaction is no since the requirements for 1.1 are the same as 1.0.
> Page 41, line 998-1000: Clarify that "address" here means an IP address or IPv4/IPv6 address to be more precise.
I think "IP address" is best since that is the scope.
> Page 43, various: Replace instances of "section 0" with the actual section that needs to be referenced.
Sometimes I hate Word.
> Page 43, lines 1057-1064: Would it be reasonable to add "Get-User-Printer-Attributes" to this?
Some issues with this:
- We can't add a requirement, even for conditionals
- I'm not aware of any Client that uses/supports Get-User-Printer-Attributes (yet)
- Paid Print probably needs the stuff from the IPP Transaction-Based Printing Extensions (5100.16) as well.
- I've talked with three different vendors that feel we need to revisit how accounting and managed printing work with IPP...
So rather than try to tweak the existing conditional requirements here I'd like to defer until we can devote some time to addressing accounting and managed printing solutions. Perhaps that will mean an update of 5100.16...
> How widely is this use case implemented?
There are a lot of solutions using the attributes, though typically under the "managed printing" banner and not as paid printing.
> 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.
I hesitate to do that as the current IPP Everywhere specification is already pretty lean/focused and splitting things up will run the risk of fragmentation and confusion. Color management is not an outlier given that color MFPs are by far the best selling printers on the market today - the question is just whether the capabilities are exposed via ICC or some vendor-specific technology, and I think the current IPP Everywhere specification allows implementors to choose what makes the best sense for a given product.
That said, I can see having a separate specification for managed printing (we almost have that right now with 5100.16) since the requirements and use cases are definitely a bit different.
> Page 46, line 1128: Add another "ipp-everywhere-1.1" keyword?
Let's see what our discussions yield.
>>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).
Oops, I missed the 720dpi ones but the link for the sample files on the IPP Everywhere landing page is working for me...
> 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).
I think this text is just describing the tests based on the conformance requirements in 5100.14, so maybe I should reword this as:
The DNS-SD tests verify that the Printer conforms to the DNS-SD requirements in IPP Everywhere v1.1 [PWG5100.14], specifically that the Printer:
- Advertises itself ...
- Provides all required TXT ...
- TLS stuff...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180718/07f1878a/attachment.html>