Hi Smith,
Proof Print was defined (and implemented by many vendors) years before Job
Save.
And the semantics in 5100.11 of Job Save are just plain wrong.
I hope Mike will chime in here.
But I hope you can see that the job progress counters are totally screwed
up by
doing both Proof Print (w/ some options) and Final Print (with different
options) in
a single Job? There's just no advantage to breaking the Job state
lifecycle as you
proposed.
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:55 AM Kennedy, Smith (Wireless & Standards
Architect) <smith.kennedy at hp.com> wrote:
> 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> 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/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>> 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/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> 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/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>>> > 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/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>> > _______________________________________________
>>> > ipp mailing list
>>> > 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/d0703942/attachment.html>