Subject: [IPP] IPP Enterprise Printing Extensions v2.0 next draft - question on the F2F minutes

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 20 May 2020 04:44:57 +0000

Hi Mike,

In the minutes from the last F2F (https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20200506.pdf <https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20200506.pdf>) covering the review of IPP Enterprise Printing Extensions v2.0, it says this toward the bottom of page 4:

⁃  Decouple job-state from Job Release:

⁃  job-state-reasons provides the Release state information

⁃  While 1.0 says job-password holds a job, subsequent

implementation experience shows that processing a job is also a valid implementation semantic - any job-state is OK for job-password

⁃  Also valid for a Printer to hold a job that has a release action

I'm wondering what this means and how this might affect the document. Are you saying that I need to change the language for "job-password" to soften it so that it isn't a hard requirement for the Job to be in the 'pending-held' state initially? I'm trying to not break backward compatibility so I'm not sure what to do with this.

Thanks for any help,

Smith

/**
    Smith Kennedy
    HP Inc.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 20 May 2020 08:33:18 -0400

Smith,

So the gist of this is that Clients are looking at the job-state-reasons attribute for 'job-password-wait' when the Job isn't completed, and so for EPX 2.0 we should modify the semantics of job-password to be that output is withheld until the End User enters the job-password value at the printer.  One possible implementation is to put the Job in the 'pending-held' state and delay processing until the password is entered.  Another is to let the Job start processing and then end up in the 'processing-stopped' state until the password is entered.  In these cases the Client will see 'job-password-wait' until the password is entered, and then Job will proceed to a terminating state ('completed', 'canceled', or 'aborted') after processing/output is done, as appropriate.

In the case of Release Printing, there is a third possibility where the Job is processed and put in a terminating state (either 'completed' or 'aborted') with the 'job-password-wait' keyword still present.  Since the Job has reached a terminating state, the state-reasons MUST NOT change once the password is entered for releasing the Job at a particular output device, but Clients stop monitoring Jobs at this point anyways and move on to the next Job in their local queues.

(The Release Printing variation isn't pretty, and maybe we should make the semantic that 'job-password-wait' is only added for Physical Devices?)

> On May 20, 2020, at 12:44 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]> wrote:
> 
> Hi Mike,
> 
> In the minutes from the last F2F (https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20200506.pdf) covering the review of IPP Enterprise Printing Extensions v2.0, it says this toward the bottom of page 4:
> 
> 	• ⁃  Decouple job-state from Job Release:
> 
> 		• ⁃  job-state-reasons provides the Release state information
> 
> 		• ⁃  While 1.0 says job-password holds a job, subsequent
> 
> 		• ⁃  Also valid for a Printer to hold a job that has a release action 
> 

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 20 May 2020 14:57:49 +0000

Hi Mike,

Sorry, but there are a few rants below. 😊

> On May 20, 2020, at 6:33 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

It seems the best choice is to remove any mention of Job State as it pertains to Job Password, and focus on "job-state-reasons" keywords to be the primary indicator. But that is suggesting to me that IPP job state is broken. More on this below.

> In the case of Release Printing, there is a third possibility where the Job is processed and put in a terminating state (either 'completed' or 'aborted') with the 'job-password-wait' keyword still…

I'm increasingly troubled by this. This has to be brought back to a simpler place than where we are today.

I think Clients stop monitoring a Release Job at this point because the Printer has caused the Job to reach the terminal state. And printers have caused a Job that should have stayed in 'pending-held' or 'processing-stopped' to reach its terminal state because some Clients block sending new Jobs until the previously sent Job has reached its terminal state, and so the Printer let the Client get away with its bad behavior by lying and moving it to a terminal state when it in fact hadn't reached a terminal state. I think this needs to be fixed. And it shouldn't require a bunch of special cases, because that increases the risk of weirdness.

I'm going to work on slides illustrating a bunch of Client / Printer topologies, and I hope we can evaluate job state and other indicators, and come up with clear messages about what the Printer reports and how a well-implemented Client ought to behave.

> (The Release Printing variation isn't pretty, and maybe we should make the semantic that 'job-password-wait' is only added for Physical Devices?)

Two points on this:

1. From our earlier discussion I had said that the Printer will put the Job in the 'pending-held' state when the Printer is a Physical Device. I tried to intentionally leave vague what a Logical Device would do. But this dialog has me in a place where I think we need to look through the several use cases and clearly agree on and document a Job's state and how a Client should or should not act in response to this. We had also discussed how the Client's blocking behavior should depend on whether the Printer (Logical or Physical) supports spooling, as indicated by "job-spooling-supported", so we should include that factor in the discussion as well. I think any Printer that supports Job Release MUST also support "job-spooling-supported" = 'spooling' and/or 'automatic'.

2. My current thinking is that the existing "job-password" / "job-password-encryption" semantic (either how it was specified in 5100.11-2010 or how it exists in the real world, which seems to be pretty different) would remain as-is. If "job-release-wait" = 'job-password', the new Job Release semantics defined for all three Release Action types would apply. That would allow legacy implementations to be as weird as they already seem to be, but try to bring us back to some semblance of consistency and predictability without this band-aid upon band-aid to tolerate the other side's disappointing misbehavior.

> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> ________________________
> Michael Sweet
> 
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 20 May 2020 18:11:24 -0400

Smith,

> On May 20, 2020, at 10:57 AM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
>> ...

In defense of the old CUPS behavior (which has since been changed to recognize the "job-password-wait" keyword and move on to the next job), most printers don't support spooling (or re-printing whole jobs) so CUPS has to hold onto the local job until it knows the destination has printed it completely.

The issue we've historically run into has been in the enterprise, where software updates seem to lag the real world by 5-10 years (I kid you not!)  For example, until recently RHEL was shipping an 8-year-old version of CUPS because their customers wanted it that way...

Anyways, I'm not at Apple anymore and I am not supporting CUPS anymore, so I'm open to locking things down into a predictable and sane direction.  If somebody does a naive Client that only despools one job at a time, no matter what, then the user experience will be sub-optimal.

> 1. From our earlier discussion I had said that the Printer will put the Job in the 'pending-held' state when the Printer is a Physical Device. I tried to intentionally leave vague what a Logical De…

I think that makes sense.

> 2. My current thinking is that the existing "job-password" / "job-password-encryption" semantic (either how it was specified in 5100.11-2010 or how it exists in the real world, which seems to be pr…

Let's definitely walk through all of the different scenarios so that we are left in a sane place.

________________________
Michael Sweet