> On Mar 15, 2019, at 6:49 PM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>>> On Mar 15, 2019, at 1:52 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <ipp at pwg.org> wrote:
>>> ...
>>> 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.
>>>> OK, more questions:
>>>> 1. Should "job-password-action" be an operation attribute, or a Job Template attribute?
>> 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... :)
In my first draft (to be posted soon) it will be an operation 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.
>> 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)
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.
>>> 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)
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'.
-------------- 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/20190325/0f89c739/attachment.sig>