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

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

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

________________________
Michael Sweet



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