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

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

Michael Sweet msweet at apple.com
Fri Mar 15 13:53:03 UTC 2019


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



More information about the ipp mailing list