Subject: [IPP] Proposed Finishings 2.0 change: require "finishings-col-database" to not be returned by default - must be explicitly requested

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 1 Feb 2016 21:25:13 +0000

Hi there,

At HP Inc. we have observed a phenomenon with the "finishings-col-database" similar to the "media-col-database": it can be quite large, and including it in with the rest of the job template attributes for each Get-Printer-Attributes response can have a negative impact on response times.  Would it be reasonable or acceptable to make it so that "finishings-col-database" was withheld from Get-Printer-Attributes responses unless it was explicitly named in the "requested-attributes" attribute included in the IPP request?  The "finishings-col-ready" could be included by default, but no the full database.

We can discuss this in person next week but I wanted to front load the topic.  I wasn't prepared to mention it in today's slide review and didn't want it to belabor the slide review process.

Thanks for your thoughts,

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    PWG Chair
    HP Inc.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 01 Feb 2016 18:43:52 -0500

Smith,

I've added this to the list of issues in Finishings 2.0.

I'd have my concerns about having this be a MUST NOT since it might break existing Clients, but perhaps we could do something like:

Printers SHOULD NOT return the "finishings-col-database" attribute in response to a Get-Printer-Attributes request unless the Client supplies the "requested-attributes" operation attribute with the value 'finishings-col-database'. Clients SHOULD supply the "requested-attributes" operation attribute whenever they require the current "finishings-col-database" value.

But we need to do a little research on this and make sure we don't break anything... :/

> On Feb 1, 2016, at 4:25 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Hi there,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 2 Feb 2016 03:04:35 +0000

Agreed - I share your concern about breaking backward compatibility.  And thanks for adding it to the agenda.

Smith

> On 2016-02-01, at 4:43 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Feb 1, 2016, at 4:25 PM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi there,
>> 
>> [email-masked] <mailto:[email-masked]>