Subject: [IPP] Updated draft of IPP Presets now available for review

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 9 Oct 2017 21:05:04 +0000

Greetings,

I posted an updated draft of IPP Presets to the PWG FTP site for review. It is available here:

   http://ftp.pwg.org/pub/pwg/ipp/wd/tb-ipp-preset-20171009.pdf
   http://ftp.pwg.org/pub/pwg/ipp/wd/tb-ipp-preset-20171009.odt
   http://ftp.pwg.org/pub/pwg/ipp/wd/tb-ipp-preset-20171009-rev.pdf
   http://ftp.pwg.org/pub/pwg/ipp/wd/tb-ipp-preset-20171009-rev.odt

Changes include:

• Added the “job-presets-storage-available” attribute definition and semantics
• Added additional Client considerations and Printer behavior for error conditions when the submitted Preset contains unsupported values or lacks resources to store the Preset it received

Cheers,
Smith

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

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

---

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Oct 2017 18:52:32 -0400

Smith,

> On Oct 9, 2017, at 5:05 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

That is not the way to advertise making these attributes settable.

RFC 3380 defines the Set-Printer-Attributes operation, its semantics, and the one attribute you use to determine which Printer attributes can be written - namely "printer-settable-attributes-supported".

If the "job-presets-supported" and/or "job-triggers-supported" attributes are settable using Set-Printer-Attributes, they must be listed in the "printer-settable-attributes-supported" attribute.  Any limits to the sizes of the attributes are handled at request time through the "client-error-request-entity-too-large" status code - see section 4.1.3 of RFC 3380.

>    Chair, IEEE ISTO Printer Working Group

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Oct 2017 18:58:49 -0400

Apologies, after re-reading my response this sounds a bit harsh, which was not my intent.  My point is just that we don't need to add another attribute - we already have one for this purpose... :)

> On Oct 9, 2017, at 6:52 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 10 Oct 2017 03:20:19 +0000

No worries! But I'm not sure I get your feedback. 

Are you suggesting that it would be better to eliminate the "job-presets-storage-available" and instead have the Printer indicate that it is not capable of accepting an additional Preset via Set-Printer-Attributes by withdrawing "job-presets-supported" from "printer-settable-attributes-supported" attribute? That seems like an "implicit" mechanism, but if we document it properly I guess it would work fine.

Or are you suggesting that a Client should just try it and if the Printer provides the "client-error-request-entity-too-large" status code, then it will know that it was rejected? That doesn't sound optimal. But if you are saying that this is the right status code to use, I'm all for using that.

Smith

> On Oct 9, 2017, at 4:58 PM, Michael Sweet <[email-masked]> wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Oct 2017 23:39:28 -0400

Smith,

> On Oct 9, 2017, at 11:20 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 

No, what I'm suggesting is that the Printer tells the Client when a set of presets can (or can't) be stored in its response to the Set-Printer-Attributes request.  The Client doesn't ask the printer to add another preset, it tells the printer to use a specific set of presets, which the Client has often created/manipulated from the existing Printer-supplied values.

IOW, when adding a preset the Client queries the current presets with Get-Printer-Attributes, adds the new preset to the returned value(s), and then stores the result with Set-Printer-Attributes.  Similarly, the Client can remove or update presets with the same Get/local-modify/Set sequence.

> Or are you suggesting that a Client should just try it and if the Printer provides the "client-error-request-entity-too-large" status code, then it will know that it was rejected? That doesn't soun…

It isn't optimal, but it *is* the right status code to use and it how Set-Printer-Attributes was designed to be used.

Right now (at least), there is no way for the Printer to communicate how much storage space it has for attributes, and I'm not sure how that would work in general - what attributes are in "writable" memory, and what attributes are in "read-only" memory? And are the attributes stored in IPP message encoding or some other intermediate format with different sizing?

Perhaps we could simply have a requirement for a minimum number of values that must be supported, or add a "max-job-presets-supported (integer(1:MAX))" attribute that tells the Client the maximum number of presets that can be stored (independent of the size of each collection).  There is precedent for such an attribute, if not specifically for this purpose...