Hi Ira,
The "proof-print" attribute as defined in the current 5100.11 only allows a Client to request different media and a number of copies, but not other job template attributes. But if this level of flexibility was the intent from the start, why have a "proof-print" attribute at all? Why not just do it as a saved job with a 'print-and-save'? I don't understand why the Proof Print and Job Save and Reprint features were exposed via IPP with unrelated attributes when the features are so similar. This is why I thought we would want to reexamine proof-print as well as job-save-disposition.
Smith
> On Aug 22, 2018, at 9:35 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith,
>> At least in higher-end systems, proof print is done on plain paper, single-sided (for proofreading)
> and final copies on different media, double-sided, different finishing, etc.
>> That can't be specified in a single Job submission.
>> 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/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
>http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
> mailto: blueroofmusic at gmail.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 Wed, Aug 22, 2018 at 11:24 AM Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
> Hi Ira,
>> My perception of a "proof print job feature" is that the user selects the choices for the final run, chooses "proof print", and then the Printer will print one copy, review it, and then print the rest if you approve of the output. Why is achieving this using one Job bad for the audit trail? Doesn't pushing the final run to a second Job cause audit trail problems of their own?
>> (BTW, if a Job is copied using Resubmit-Job, does the newly created Job have a Job Status attribute pointing back to the Job ID of the Job from which it was created?)
>> 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.
> */
>>>>> On Aug 22, 2018, at 8:31 AM, Ira McDonald <blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>> wrote:
>>>> Hi Smith,
>>>> I disagree about your suggestion for a strange job state lifecycle for "proof-print".
>> All jobs should complete when they have finished producing output. Leaving that
>> original job in in 'processing-stopped' state is reinventing the audit trail problems
>> of the deprecated Restart-Job operation from RFC 2911, for no visible benefit.
>>>> The person who did the original "proof-print" (a document author) may well NOT
>> be the person who makes the final fifty copies (an admin or project leader).
>>>> 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/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
>>http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
>> mailto: blueroofmusic at gmail.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 Wed, Aug 22, 2018 at 7:38 AM Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> 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://protect-us.mimecast.com/s/7lpaCDkr5rf5NPmPtAE5y2?domain=ftp.pwg.org>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.docx <https://protect-us.mimecast.com/s/oIo-CERv5vs3VPGPSPAHfF?domain=ftp.pwg.org>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.pdf <https://protect-us.mimecast.com/s/TSB5CG6xjxh1KglgikotvK?domain=ftp.pwg.org>
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.docx <https://protect-us.mimecast.com/s/bbIJCJ6AmAhq3XzXfOPmtN?domain=ftp.pwg.org>
>>>> 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 <mailto: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 <mailto: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/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
>>> > http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
>>> > mailto: blueroofmusic at gmail.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 <mailto: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 <mailto:ipp at pwg.org>
>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>> > _______________________________________________
>>> > ipp mailing list
>>> > ipp at pwg.org <mailto:ipp at pwg.org>
>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?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/7d3c59f4/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/7d3c59f4/attachment.p7s>