attachment
<div dir="ltr"><div>Hi Guerney,</div><div><br></div><div>My two cents.</div><div><br></div><div>I'm sure Mike can respond more articulately.</div><div><br></div><div>But the literal reading of 'print-save' and 'save-only' is *just* some form<br></div><div>of the *processed* raw Document data (definitely NOT the Document</div><div>object w/ metadata). That's unacceptable and useless IMO.</div><div><br></div><div>Although the IPP F2F minutes record that you think that "output-device"</div><div>of NULL is a hack, it seems sound and reasonable to me.</div><div><br></div><div>And I still like "put a stake in the heart of job-save-disposition". I think</div><div>JPS2 has serious issues of ambiguity.</div><div><br></div><div>Cheers,</div><div>- Ira<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place Saline, MI 48176 734-944-0094<br>May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 21, 2018 at 6:13 PM Kennedy, Smith (Wireless & Standards Architect) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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? <br>
<br>
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.<br>
<br>
Why specifically is this an inappropriate reading of 5100.11? <br>
<br>
Thanks for your patience and thoughts?<br>
<br>
Smith<br>
<br>
/**<br>
Smith Kennedy<br>
Wireless & Standards Architect - IPG-PPS<br>
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF<br>
Chair, IEEE ISTO Printer Working Group<br>
HP Inc.<br>
*/<br>
<br>
<br>
<br>
_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</blockquote></div>