Subject: [IPP] Updated IPP Everywhere v1.1 drafts posted

From: Michael Sweet <[email-masked]>
Date: Wed, 04 Jul 2018 03:22:19 -0400

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Wed, 18 Jul 2018 12:56:05 +0000

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 <[email-masked]> wrote:
> 
> All,
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 18 Jul 2018 10:35:37 -0400

Smith,

Thanks for the feedback.  Responses are inline below...

> On Jul. 18, 2018, at 8:56 AM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Hi Mike,
> 

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 retroact…

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…

I think we should say "STD 92" everywhere.

> "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.

> 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 poi…

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 w…

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...

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Thu, 19 Jul 2018 22:31:40 +0000

> On Jul 18, 2018, at 8:35 AM, Michael Sweet <[email-masked]> wrote:
> 
>> 

Basically sub-filtering at discovery time for a particular generation of IPP Everywhere™.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 19 Jul 2018 20:04:52 -0400

> On Jul 19, 2018, at 6:31 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> 
> 
>> On Jul 18, 2018, at 8:35 AM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 

... in order to do what?

Unless there is a compelling need (and I'm not aware of any IPP protocol-level features that would qualify), I really can't support it.  We have keys for specific kinds of printer features, PDL support, etc., but at the protocol level we are entirely generic so that any client can send print jobs to any printer.

And even for those printer features the only printing UI I am aware of that shipped support for filtering was my old ESP Print Pro software and the original Qt print dialog - both are long gone now...

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Fri, 20 Jul 2018 00:51:32 +0000

> On Jul 19, 2018, at 6:04 PM, Michael Sweet <[email-masked]> wrote:
> 
> 
> 
>> On Jul 19, 2018, at 6:31 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

Ummmm.....not sure.

> And even for those printer features the only printing UI I am aware of that shipped support for filtering was my old ESP Print Pro software and the original Qt print dialog - both are long gone now…

Upon more reflection, I don't see any substantive value and so I withdraw the feedback / comment / change request.