> On Oct 9, 2017, at 11:20 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> 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.
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 sound optimal. But if you are saying that this is the right status code to use, I'm all for using that.
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...
Michael Sweet, Senior Printing System Engineer