As per my action item from the June 29, 2017 IPP WG minutes (http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20170629.pdf <http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20170629.pdf>), I am finally providing a use case illustrating what I think IPP is lacking but should support:
Wilma has created a document that she wants to be saved on the department MFD, but wants only those that have the document's password to be able to print it. She chooses to add a password to the job and also chooses to save the job in the print dialog, and clicks on "Print" to submit the job to the printer. The Printer receives the Job, where its processing consists of the Job being saved for reprint later. The password persists with the saved Job. Wilma then sends out an email to her teammates informing them that the document has been saved on the MFD.
Fred needs a copy of the document, so he goes to the MFD, chooses the job, and is prompted for the saved job's password. Once Fred has entered it successfully into the MFD's control panel, the MFD prints a copy of the saved Job for him.
Provide a method for persisting a job password with a saved job. This is currently unsupported because the semantics of the current "job-password" attribute are such that the Job is kept in "pending-held" state until the password has been provided to the Printer, but the semantics of IPP saved jobs are such that the processing of a saved job results in it being saved. If the processing is being delayed until the password is provided, and then is abandoned (because it is an operation attribute of a Job Creation operation), a gap exists. The existing "document-password" attribute could be provided but its semantics are inappropriate and it only applies to certain document formats.
We can discuss at a later IPP WG meeting (not in this week's vF2F). Let me know if the WG needs more details before proceeding. But this use case is clearly not well supported by 5100.11 (JPS2).
Wireless Architect - Client Software - IPG-PPS
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
Chair, IEEE ISTO Printer Working Group
> On Jun 25, 2017, at 5:54 PM, Michael Sweet <msweet at apple.com> wrote:
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4241 bytes
Desc: not available