Subject: [IPP] RFC: Relationship between job-retain-until-xxx and job-password

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 15 Mar 2019 09:53:03 -0400

All,

In reviewing the minutes from yesterday's concall, I saw the following summary of discussions regarding job-password and job-retain-until-xxx in the new IPP Enterprise Printing Extensions:

	• discussed job-retain-until and job-retain-until-time and job-retain-until-date
		• consensus was to keep job-retain-until (type2 keyword) and job-retain-until-date (dateTime)
			• Semantics for job-retain-until-time could be specified that the integer is the number of seconds, etc. once it has entered its terminal state (e.g. calculated as "date-time-at-completed" + "job-retain-until-time").
			• what to do about "job-password" Jobs that the Job isn't a Retained Job
	• "job-password" should be disallowed when "job-retain-until" or "job-retain-until-time" are specified
	• maybe the better recommendation for a "secure print" that doesn't get aged out is to use "job-print-password" and have it be "save-only"?
		• Should there be additional dispositions?

Some of my own thoughts:

1. I thought the consensus was to put job-retain-until-xxx in JOBEXT? They are defined in the current draft of JOBEXT...

2. My issue with just having job-retain-until-time (dateTime) is that there is no way (short of defining keyword/name values for job-retain-until) to say "by default, retain all jobs for a year".  For example, CUPS can be configured to retain jobs ("PreserveJobFiles") indefinitely, not at all, or for a specified number of seconds after completion.  There is no "retain until date/time" functionality because we've never needed it in CUPS, but I can see a potential need for legal documents/jobs that "expire" after a specific date and time.

  TL;DR: If we get rid of anything it should be "job-retain-until-time (dateTime)" and *not*
  "job-retain-until-interval (integer(0:MAX))".

3. As for job-password not being compatible with job-retain-until-xxx, why? "job-password" just holds the job until the User enters the password/code at the printer - the semantics of retaining a job don't kick in until the job reaches a terminating state, and PIN printing will likely have the same legal requirements WRT document retention as any other kind of printing.

4. WRT "job-print-password", what if (and I haven't thought this completely through yet) we define another parallel attribute, "job-password-action (type2 keyword)" that defines the semantics of the "job-password" attribute, with the default being "hold-job" to preserve the 1.0 semantics. Something like:

job-password-action (type2 keyword)

This operation attribute specifies how a Job is processed when the "job-password" (section N.M.P) operation attribute is included in a Job Creation request.  Standard keyword values include:

- 'hold-job': The Job is placed in the 'pending-held' state and is released when the "job-password" value is entered at the Printer's console.
- 'process-and-retain': The Job is placed in the 'pending' state and it scheduled for processing without waiting for the User to enter the "job-password" value at the Printer's console.
- 'retain-only': The Job is placed in the 'completed' state as soon as all Documents are received by the Printer.

Once in a terminating state, the Job is retained according to the current value of its "job-retain-until-xxx" attributes.

5. Also WRT "job-print-password", if we adopt "job-print-action" then we can amend the semantics of "Resubmit-Job" to require the original "job-password" value to get both the desired reprint behavior *and* better support the security characteristics implied by "job-password".

Thoughts?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

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

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Fri, 15 Mar 2019 16:44:40 +0000

> On Mar 15, 2019, at 7:53 AM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> All,
> 

Yeah this was a typo. I meant to say this:

• consensus was to keep "job-retain-until" (type2 keyword) and "job-retain-until-time" (integer) and NOT implement "job-retain-until-date" (dateTime)

> 3. As for job-password not being compatible with job-retain-until-xxx, why? "job-password" just holds the job until the User enters the password/code at the printer - the semantics of retaining a j…

If the goal is to protect the Job, the "job-password" only prevents the first printing by holding it in the 'pending-held' state. If you also specify "job-retain-until" = 'indefinite', that will cause the Job to be available for reprinting by others. So the normative language we were talking about was to say that "job-password" and "job-retain-until" MUST NOT or SHOULD NOT both be specified, or that "job-retain-until" MUST be 'no-retain' etc. (the keywords in the JPS2v2 draft from Feb. 14 are broken).

However...your next comments may obviate all of this.

> Once in a terminating state, the Job is retained according to the current value of its "job-retain-until-xxx" attributes.

I like it! I'll update my EPE draft to specify that and we can discuss that first draft at our next IPP WG meeting.

> 
> 5. Also WRT "job-print-password", if we adopt "job-print-action"

(guessing you mean "job-password-action"...)

> then we can amend the semantics of "Resubmit-Job" to require the original "job-password" value to get both the desired reprint behavior *and* better support the security characteristics implied by "job-password".
> 
> Thoughts?

I like that too!
> https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/2NGcCwp5B5I48lKVUq_Hjw?domain=pwg.org>

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Fri, 15 Mar 2019 17:52:13 +0000

> On Mar 15, 2019, at 10:44 AM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
> 

OK, more questions:

1. Should "job-password-action" be an operation attribute, or a Job Template attribute?

2. We would want the semantic to be that if the "job-password-action" was 'retain-only' or 'process-and-retain' then the "job-password" value would become a "hidden Job Status attribute" so that the Printer would require the "job-password" to be entered before any reprints could occur.

3. I'm not clear on the semantic meaning of 'process-and-retain'?

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 15 Mar 2019 20:49:27 -0400

Smith,

> On Mar 15, 2019, at 1:52 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
>> ...

Good question.  Ordinarily we would make it a Job Template attribute, but I can see the argument for not exposing too many details of "job-password" usage and "job-password-encryption" is also an operation attribute.

Of course, the 'job-password-wait' keyword in "job-state-reasons" will expose the fact that a job is held for a password at the console, but we're stuck with that so an operator or user knows some action is required...

OK, I think I'm slightly more in favor of it being an operation attribute, if for any other reason that I think there will be less chance for an implementor to mess things up... :)

> 2. We would want the semantic to be that if the "job-password-action" was 'retain-only' or 'process-and-retain' then the "job-password" value would become a "hidden Job Status attribute" so that th…

I think we should require job-password for any action - yes, a new semantic for Resubmit-Job, but I think one we can get away with since the combination of job-password and Resubmit-Job was not fully specified... (unlike save-disposition and proof-print)

> 3. I'm not clear on the semantic meaning of 'process-and-retain'?

Print it (without password) and then retain for later reprint (using the password).

So basically:

- 'hold-job' is "hold the job until the password is entered, then print and retain"
- 'process-and-retain' is "print the job immediately and then retain"
- 'retain-only' is "do not print the job but retain the job for possible later printing"

Any subsequent reprints require the password.  I guess the question is whether the "job-retain-until" for the resubmitted job should be "none" or the copied job should also have the same job-password-xxx values? (I can see the latter actually being a benefit)

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Mon, 25 Mar 2019 14:30:30 +0000

> On Mar 15, 2019, at 6:49 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

In my first draft (to be posted soon) it will be an operation attribute.

> I think we should require job-password for any action - yes, a new semantic for Resubmit-Job, but I think one we can get away with since the combination of job-password and Resubmit-Job was not ful…

Oh, ok.

But the funny thing is that now I feel like we have come full circle. 😊 Originally I was concerned about the awkward semantics of "job-password" and "job-save-disposition". If we had proposed "job-password-action" as we are describing here, and updated the semantics of "job-password" so that in all cases the password is required for any action, then we could have left JPS2 as is and my use case would have been resolved. I suppose we'd still have contend with the ambiguous semantics of "job-save-disposition", though.

> Any subsequent reprints require the password.  I guess the question is whether the "job-retain-until" for the resubmitted job should be "none" or the copied job should also have the same job-passwo…

I'm a little worried about 'retain-only'. If the semantics of "job-password" are going to be updated / clarified to require that the password be required for any subsequent reprint (via Resubmit-Job or otherwise), then is 'retain-only' just for supporting something like "job-save-disposition" --> "save-disposition" = 'save-only'? But for 'save-only' the "processing" job state is saving it. So 'retain-only' sounds like it is bypassing processing and going straight from 'pending' to 'completed'.