Greetings,
I've prepared a JPS2 v2, and I'm ready to publish it and move into a design discussion about a replacement for "job-save-disposition" and other aspects of JPS2, but before I do that I wanted to make one more pass at the state of the current JPS2 document, to make sure we need to dive into this effort.
It was asserted in the August 2018 F2F and in the minutes that since the definitions of 'save-only' and 'print-and-save' on pages 40-41 only discusses Document Data, and doesn't say anything about retaining the Job, that sending "save-disposition" = 'save-only' or 'print-and-save' will not cause the Printer to retain the Job, and therefore JPS2 failed to actually support the "Job Save and Reprint Feature" with any of the attributes defined within. I can understand why it might be read that way, but I also think we don't need to take such a narrow interpretation of 5100.11. From my reading, when a Printer processes a Job that has the "save-disposition" member of "job-save-disposition" specifying 'save-only' or 'print-and-save', if there are no errors, the Printer can save the Job's Document Data to the location specified in "save-info" member of "job-save-disposition" (as per pages 40-41), but it can ALSO put the completed Job in the Job Retention Phase as per the definition of a Saved Job on 5100.11 page 13, so that it becomes a Saved job suitable for a reprint using control panel selection or an IPP Resubmit Job operation.
If there is a Printer that implements "job-save-disposition" and saves the Document Data but does not Retain the Job then that could be viewed as unfortunate behavior, but will any clients care about this misbehavior? Do any IPP Everywhere™ implement this unfortunate behavior?
To be clear, I am not trying to be difficult or combative - I natively don't understand why we need to be reading it the way that we are. The specification seems vague enough that such an interpretation doesn't seem unreasonable to me. And it seems much less destructive (and less work) to take that interpretation than to start over or create a JPS2v2.
Why specifically is this an inappropriate reading of 5100.11?
Thanks for your patience and thoughts?
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.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180821/425542a0/attachment.p7s>