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/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 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://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.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/3b89d98e/attachment.html>