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

["Kennedy, Smith (Wireless & IPP Standards) via ipp" <[e-mail]>]

Hi Mike,

Sorry, but there are a few rants below. 😊

> On May 20, 2020, at 6:33 AM, Michael Sweet <[e-mail]> wrote:
> 
> 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.

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

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.

> 
> 
> > On May 20, 2020, at 12:44 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[e-mail]> wrote:
> >
> > 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
> > [e-mail]
> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> ________________________
> Michael Sweet
> 
> 

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