[IPP] Preparing to post JPS2v2 First Draft, but want to poke at current JPS2 one more time

[IPP] Preparing to post JPS2v2 First Draft, but want to poke at current JPS2 one more time

Kennedy, Smith (Wireless & Standards Architect) smith.kennedy at hp.com
Wed Aug 22 11:38:43 UTC 2018


OK, I am fine with starting from scratch to solve the Job Save and Reprint Feature and the Password Protected Job feature so that they can be at least orthogonal to one another, to allow password protected saved jobs to be clearly supported. First draft posted, announcement soon:

   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.pdf> 
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.docx <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.docx> 
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.pdf> 
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.docx <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.docx> 

And while we have the lid open, I think we might want to re-examine proof print, because some of proof print seems to step on job save and reprint. IMHO a proof print should print 1 copy and then enter 'processing-stopped' until it has been re-approved for processing, at which time it prints and becomes 'completed'. Once in that state, if the User / Client wants to specify 'print-and-save', then the new solution for the Job Save and Reprint feature can be applied if supported by the printer.

Smith



> On Aug 21, 2018, at 6:44 PM, Michael Sweet <msweet at apple.com> wrote:
> 
> Smith,
> 
> The issue with "job-save-disposition" is that it does not specify the intent to retain the Job, just to save it to a specified location. Given what you (HP) want to be able to do, namely to support retention and re-printing of a job, it seemed clear from our discussions that job-save-disposition did not match up, and in fact the way that job-save-disposition is currently specified has technical implementation problems that are not easily resolved (thus the call to update JPS2 and deprecate it...)
> 
> The related "proof-print" attribute *does* specify that the Job should be retained (at least for one reprint) and in general seems to have much better defined semantics. But it doesn't address how to have a persistent password for the Job and basically makes the assumption that the first print is a test run. Which is how we got to adding "job-retain-until[-time]" and "job-[re]print-password[-encryption]" attributes...
> 
> 
> Ira,
> 
> The "output-device" comment was mine - since output-device uses the name syntax, we don't have a clear path to defining a semantic meaning for a particular name, even if it is an empty string or a specific name like "none". *If* we decide that we want a way to specify "process this Job but don't send it to an output device" in the Job Ticket, we should proceed carefully and clearly document a) how a Client specifies this and b) how a Printer advertises its support for this. But I'll stay on the record as not being 100% happy about it...
> 
> 
> > On Aug 21, 2018, at 8:22 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> > 
> > Hi Guerney,
> > 
> > My two cents.
> > 
> > I'm sure Mike can respond more articulately.
> > 
> > But the literal reading of 'print-save' and 'save-only' is *just* some form
> > of the *processed* raw Document data (definitely NOT the Document
> > object w/ metadata). That's unacceptable and useless IMO.
> > 
> > Although the IPP F2F minutes record that you think that "output-device"
> > of NULL is a hack, it seems sound and reasonable to me.
> > 
> > And I still like "put a stake in the heart of job-save-disposition". I think
> > JPS2 has serious issues of ambiguity.
> > 
> > Cheers,
> > - Ira
> > 
> > Ira McDonald (Musician / Software Architect)
> > Co-Chair - TCG Trusted Mobility Solutions WG
> > Chair - Linux Foundation Open Printing WG
> > Secretary - IEEE-ISTO Printer Working Group
> > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> > IETF Designated Expert - IPP & Printer MIB
> > Blue Roof Music / High North Inc
> > http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/yHxRCADo5oTN864lhYxs0K?domain=sites.google.com>
> > http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/8GZtCBBp5pu7y6jRCWvxxJ?domain=sites.google.com>
> > mailto: blueroofmusic at gmail.com
> > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
> > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
> > 
> > 
> > 
> > On Tue, Aug 21, 2018 at 6:13 PM Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com> wrote:
> > 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.
> > */
> > 
> > 
> > 
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180822/72ba2c98/attachment.html>
-------------- 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/20180822/72ba2c98/attachment.p7s>


More information about the ipp mailing list