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/blueroofmusichttp://sites.google.com/site/highnorthinc
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> 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> 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/aUvICzp5G5IMXZzAh4OqZ_?domain=sites.google.com>
>http://sites.google.com/site/highnorthinc> <https://protect-us.mimecast.com/s/ObVUCADo5oTNxX5zU8w8Ar?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 Wed, Aug 22, 2018 at 7:38 AM Kennedy, Smith (Wireless & Standards
> Architect) <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/fMzZCBBp5pu7xrNOINBRzW?domain=ftp.pwg.org>
>>>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.docx>> <https://protect-us.mimecast.com/s/F1GdCDkr5rf57zZkcZDycD?domain=ftp.pwg.org>
>>>>>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.pdf>> <https://protect-us.mimecast.com/s/VeqcCERv5vs3w2jNhZqFs_?domain=ftp.pwg.org>
>>>>>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.docx>> <https://protect-us.mimecast.com/s/vRoyCG6xjxh1rR9Qs0H32r?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> 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/aUvICzp5G5IMXZzAh4OqZ_?domain=sites.google.com>
>> > http://sites.google.com/site/highnorthinc>> <https://protect-us.mimecast.com/s/ObVUCADo5oTNxX5zU8w8Ar?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/pF1mCJ6AmAhqkvoDuphaKc?domain=pwg.org>
>> > _______________________________________________
>> > ipp mailing list
>> > ipp at pwg.org>> > https://www.pwg.org/mailman/listinfo/ipp>> <https://protect-us.mimecast.com/s/pF1mCJ6AmAhqkvoDuphaKc?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/c6b0c5f8/attachment.html>