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

[Michael Sweet via ipp <[e-mail]>]

Smith,

> On May 20, 2020, at 10:57 AM, Kennedy, Smith (Wireless & IPP Standards) <[e-mail]> wrote:
>> ...
>> 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.
> 
> 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. 

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.

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

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

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

________________________
Michael Sweet



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