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

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Tue, 21 Aug 2018 22:12:44 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Aug 2018 20:22:59 -0400

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
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
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) <[email-masked]> 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.
>

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Aug 2018 20:24:27 -0400

Hi Smith,

Sorry for addressing you as "Guerney" - I had a reply to a TCG note in
progress
at the same time.

Cheers,
- Ira

On Tue, Aug 21, 2018 at 8:22 PM Ira McDonald <[email-masked]>
wrote:

>> 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

---

From: Michael Sweet <[email-masked]>
Date: Tue, 21 Aug 2018 20:44:13 -0400

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 <[email-masked]> wrote:
> 
> Hi Guerney,
> 
> My two cents.
> 
> And I still like "put a stake in the heart of job-save-disposition".  I think
> On Tue, Aug 21, 2018 at 6:13 PM Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Ira McDonald <[email-masked]>
Date: Tue, 21 Aug 2018 21:28:52 -0400

Hi,

I second what Mike said about "proof-print", "job-retain-xxx", etc.

Never mind, of course, "output-device" is name syntax.  We have always
avoided special semantics for values of name syntax, because that's mixing
keywords w/ names (without saying it explicitly in the attribute
definition).
Forget the weak NULL idea.

Cheers,
- Ira

On Tue, Aug 21, 2018 at 8:44 PM Michael Sweet <[email-masked]> 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...
>
>

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Wed, 22 Aug 2018 11:38:43 +0000

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 <[email-masked]> wrote:
> 
> Smith,
> 
> > 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>
> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 22 Aug 2018 10:31:51 -0400

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

On Wed, Aug 22, 2018 at 7:38 AM Kennedy, Smith (Wireless & Standards
Architect) <[email-masked]> 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
>
>
>
> Printer advertises its support for this. But I'll stay on the record as not
> being 100% happy about it...
>
>
> <https://protect-us.mimecast.com/s/yHxRCADo5oTN864lhYxs0K?domain=sites.google.com>
> <https://protect-us.mimecast.com/s/8GZtCBBp5pu7y6jRCWvxxJ?domain=sites.google.com>
> <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
> <https://protect-us.mimecast.com/s/TP-hCDkr5rf5yvqJtkfP_C?domain=pwg.org>
>

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Wed, 22 Aug 2018 15:24:13 +0000

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

> On Aug 22, 2018, at 8:31 AM, Ira McDonald <[email-masked]> 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
> 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: [email-masked] <mailto:[email-masked]>
> On Wed, Aug 22, 2018 at 7:38 AM Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>    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> 
> 
>> On Aug 21, 2018, at 6:44 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Smith,
>> 
>> > On Aug 21, 2018, at 8:22 PM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > Hi Guerney,
>> > 
>> > My two cents.
>> > 
>> > 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: [email-masked] <mailto:[email-masked]>
>> > On Tue, Aug 21, 2018 at 6:13 PM Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> > Greetings,
>> > 
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/pF1mCJ6AmAhqkvoDuphaKc?domain=pwg.org>
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/pF1mCJ6AmAhqkvoDuphaKc?domain=pwg.org>
>>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 22 Aug 2018 11:35:26 -0400

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

On Wed, Aug 22, 2018 at 11:24 AM Kennedy, Smith (Wireless & Standards
Architect) <[email-masked]> 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
> <https://protect-us.mimecast.com/s/aUvICzp5G5IMXZzAh4OqZ_?domain=sites.google.com>
> <https://protect-us.mimecast.com/s/ObVUCADo5oTNxX5zU8w8Ar?domain=sites.google.com>
>> 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://protect-us.mimecast.com/s/fMzZCBBp5pu7xrNOINBRzW?domain=ftp.pwg.org>
>>
>> <https://protect-us.mimecast.com/s/F1GdCDkr5rf57zZkcZDycD?domain=ftp.pwg.org>
>>
>>
>> <https://protect-us.mimecast.com/s/VeqcCERv5vs3w2jNhZqFs_?domain=ftp.pwg.org>
>>
>>
>> <https://protect-us.mimecast.com/s/vRoyCG6xjxh1rR9Qs0H32r?domain=ftp.pwg.org>
>>
>>
>> <https://protect-us.mimecast.com/s/aUvICzp5G5IMXZzAh4OqZ_?domain=sites.google.com>
>> <https://protect-us.mimecast.com/s/ObVUCADo5oTNxX5zU8w8Ar?domain=sites.google.com>
>> > 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
>> <https://protect-us.mimecast.com/s/pF1mCJ6AmAhqkvoDuphaKc?domain=pwg.org>
>> <https://protect-us.mimecast.com/s/pF1mCJ6AmAhqkvoDuphaKc?domain=pwg.org>
>>

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Wed, 22 Aug 2018 15:55:36 +0000

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 <[email-masked]> wrote:
> 
> Hi Smith,
> 
> At least in higher-end systems, proof print is done on plain paper, single-sided (for proofreading)
> 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>
> On Wed, Aug 22, 2018 at 11:24 AM Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ira,
> 
>> On Aug 22, 2018, at 8:31 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Smith,
>> 
>> 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>
>>    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> 
>> 
>>> > 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>
>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 22 Aug 2018 12:00:34 -0400

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

On Wed, Aug 22, 2018 at 11:55 AM Kennedy, Smith (Wireless & Standards
Architect) <[email-masked]> 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
>
>
>
> <https://protect-us.mimecast.com/s/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
> <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
>> <https://protect-us.mimecast.com/s/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
>> <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
>>> <https://protect-us.mimecast.com/s/7lpaCDkr5rf5NPmPtAE5y2?domain=ftp.pwg.org>
>>>
>>>
>>> <https://protect-us.mimecast.com/s/oIo-CERv5vs3VPGPSPAHfF?domain=ftp.pwg.org>
>>>
>>>
>>> <https://protect-us.mimecast.com/s/TSB5CG6xjxh1KglgikotvK?domain=ftp.pwg.org>
>>>
>>>
>>> <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
>>>
>>>
>>>
>>> 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
>>> <https://protect-us.mimecast.com/s/pjwCCADo5oTNLYoYHGB-j6?domain=sites.google.com>
>>> <https://protect-us.mimecast.com/s/WXcACBBp5pu7pomoH6mjvm?domain=sites.google.com>
>>> <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>> <https://protect-us.mimecast.com/s/FMcJCKrBnBF2zJwJhoLuxg?domain=pwg.org>
>>>

---

From: Paul Tykodi <[email-masked]>
Date: Wed, 22 Aug 2018 12:15:13 -0400

Hi Smith,

As Ira has outlined, in high volume production environments, my experience has been that proof-print is a specific type of job that is typically run just once.

It is a sanity check for things like color profile selections, keeping all content within the printable area of the selected media type, etc.

This type of job is frequently sent to an IPP 2.1/2.2 supporting device.

Once the sanity check output is reviewed and approved, the production job (Example: 100,000 impressions) is approved for release to some very high end (frequently roll-fed) press. The job ticket for the production job is developed independently from the proof-print job so the disconnect you observed in the PWG standard models real-world behavior at the high end of print production facilities.

Hope this observation might help a little ...

Best Regards,

/Paul

Sent from my iPhone

> On Aug 22, 2018, at 11:55 AM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Hi Ira,
> 
>>> On Wed, Aug 22, 2018 at 11:24 AM Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
>>> Hi Ira,
>>> 
>>>>> On Wed, Aug 22, 2018 at 7:38 AM Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Wed, 22 Aug 2018 16:27:03 +0000

Hi Ira,

> On Aug 22, 2018, at 10:00 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Smith,
> 
> Proof Print was defined (and implemented by many vendors) years before Job Save.

HP defined them both around the same time (18-30 years ago). Our implementation of Proof Print was simpler: print 1 copy; if approved, print the rest with the same job choices with possibly different media selection. The "proof-print" attribute seems to support this, but the "two Job solution" doesn't.

> And the semantics in 5100.11 of Job Save are just plain wrong.

No arguments there! To be clear, I'm talking about the abstract notion of "Job Save", not equating "Job Save" with "job-save-disposition". 

My point was that if Job Save was properly and appropriately implemented in IPP, it is conceivable that the same primitives 

> I hope Mike will chime in here.

I think maybe we ought to just wait until we have another IPP WG call or can all be on the phone.

> 
> 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.

I am not quite sure what you mean by "job progress counters", but I do understand how the other Job Description and Job Status attributes could contain potentially incorrect information if there are radically different choices made for the Proof Print and Final Print. 

> http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/hhgqCwp5B5IGJrAxcV6L3q?domain=sites.google.com>
> http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/PTXuCxk5D5f1nN9vTvCZLS?domain=sites.google.com>
> On Wed, Aug 22, 2018 at 11:55 AM Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ira,
> 
>> On Aug 22, 2018, at 9:35 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Smith,
>> 
>> http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/hhgqCwp5B5IGJrAxcV6L3q?domain=sites.google.com>
>> http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/PTXuCxk5D5f1nN9vTvCZLS?domain=sites.google.com>
>>> http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/hhgqCwp5B5IGJrAxcV6L3q?domain=sites.google.com>
>>> http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/PTXuCxk5D5f1nN9vTvCZLS?domain=sites.google.com>
>>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.pdf <https://protect-us.mimecast.com/s/g_NiCyP5E5urqV0ocQ7mmu?domain=ftp.pwg.org> 
>>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821.docx <https://protect-us.mimecast.com/s/rF3TCzp5G5IMQVxqhKbfXn?domain=ftp.pwg.org> 
>>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.pdf <https://protect-us.mimecast.com/s/cuHgCADo5oTNLqnOFQPUcw?domain=ftp.pwg.org> 
>>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext20-20180821-rev.docx <https://protect-us.mimecast.com/s/sgePCBBp5pu7p2MKh1Xsr0?domain=ftp.pwg.org> 
>>> 
>>>> > http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/hhgqCwp5B5IGJrAxcV6L3q?domain=sites.google.com>
>>>> > http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/PTXuCxk5D5f1nN9vTvCZLS?domain=sites.google.com>
>>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/zqbACDkr5rf5NGnAsRy-6M?domain=pwg.org>
>>>> > https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/zqbACDkr5rf5NGnAsRy-6M?domain=pwg.org>
>>>>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 Aug 2018 08:59:15 -0400

Smith,

> On Aug 22, 2018, at 11:24 AM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Hi Ira,
> 

Well, the job state would go from 'completed' (where Clients assume that the receipt values are stable) to 'pending'.  Also, "proof-print" is a collection attribute that specifies additional attributes for the Job Ticket as a proofing job that override the corresponding Job Template attributes.  Finally, there is no definition of a "approve via console" use case or semantics in JPS2, so right now the only way to approve the proof job is to send a Resubmit-Job operation.

> (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?)

No, but it is probably a good idea to add one.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 Aug 2018 09:09:48 -0400

Smith,

> 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 fle…

The current JPS2 definition does not prevent support for "sides" and other attributes (there is a proof-print-supported attribute listing the supported member attributes), but it also doesn't say anything about supporting other Job Template attributes.  IMHO we should address this in v2.0 - it is important to support common work flows in IPP so that we have interoperability and consistent semantics, otherwise we just end up with vendor-specific solutions and software that doesn't work well... :/

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 Aug 2018 09:14:54 -0400

Smith,

> On Aug 22, 2018, at 12:27 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
>> ...

We can continue discussions here until the next concall in order to prioritize things and maybe come up with a short list of changes.

> I am not quite sure what you mean by "job progress counters", but I do understand how the other Job Description and Job Status attributes could contain potentially incorrect information if there ar…

The counters - job-pages-completed[-col], job-media-sheets-completed[-col], job-impressions-completed[-col] - and the xxx-actual attributes recording which values were used for the various Job Template attributes.  These are supposed to be stable once the Job reaches a terminating state.