> On Mar 15, 2019, at 7:53 AM, Michael Sweet via ipp <ipp at pwg.org> wrote:
>> 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))".
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 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.
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.
>> 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.
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!
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/2NGcCwp5B5I48lKVUq_Hjw?domain=pwg.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190315/2b19090e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190315/2b19090e/attachment.sig>