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