> On Jun 23, 2017, at 6:15 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> Hi there,
>> Consider a scenario where a Printer receives a Create-Job operation with the following attributes:
>> What would one expect the printer to do:
>> 1. Hold the Job in 'pending-held' state until the matching password was provided, then retain the Job as a Saved Job
> 2. Process the Job to retain the Job as a Saved Job per the definition in 5100.11 section 2.2, but then whenever it might be reprinted via user selection on the control panel, the user is prompted for the password
The result should be 1 or a new 3:
3. Treat job-password and job-password-encryption as constrained against job-save-disposition (i.e. the two are incompatible), and either return client-error-conflicting-attributes or successful-ok-ignored-or-substituted-attributes with one or the other in the unsupported attributes group of the response.
The problem with #2 is that you are saving private information (job-password[-encryption]) with the processed job data, which could be a security issue (information disclosure). Plus the saved job is not necessarily stored on the printer...
> If the expectation is #1 then there seems to be no way currently in standard IPP to create a password protected Saved Job, which I believe to be a valid use case that IPP needs to support. This could be supported using my (pending) IPP Document Encryption whitepaper, but wondered if it was already supported.
What you want is probably the semantic equivalent of document-password in the job-save-disposition ("save-password"), not job-password, however there are issues since we normally send passwords as operation attributes that are not made available as part of the Job or Document objects...
Michael Sweet, Senior Printing System Engineer