Hi Ira,
My main concerns are that the "job-password" provided will prevent the Job from being stored when it is received, and that once the password is entered at the Printer, that password won't persist. That doesn't seem to match my expectations as to what the user would want. In the use case I'm thinking about, the Job is sent to be stored and is provided with a password, with the user expecting that it will be stored right away, and that each re-print of that saved job will require that job's password to be entered.
It seems we could solve this using a combination of "document-password" if the "save-document-format"='application/pdf', or possibly using my pending "IPP Document Encryption" system. I would have thought that this combination would have been considered already since both "job-password" and "job-save-disposition" are defined in the same PWG candidate standard. Language such as :
If a job creation operation is received that includes both "job-password" and "job-save-disposition" where its "save-disposition" member is 'save-only', in this case the Job will NOT be placed in 'pending-held' state but will proceed to "processing" for becoming a "saved job", and the "job-password" will be expected upon each reprint.
From HP's perspective, the reprinting of saved jobs is not performed via IPP Client operations such as the deprecated Restart-Job or Reprocess-Job operation, but by user interactions at the Printer itself, for instance using a physical printer's control panel or web interface, or a print server's management interface.
Smith
/**
Smith Kennedy
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
HP Inc.
*/
> On Jun 24, 2017, at 8:14 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith,
>> This is an interesting question.
>> Since both Restart-Job and Reprocess-Job are deprecated, I note that,
> with Resubmit-Job (which creates a *new* job from the saved/retained
> job), I would assume that an entirely new job-password would be sent.
>> That is, I don't believe it's appropriate or reasonable for the saved job
> to retain the old one-time-use job-password for the new job created by
> the Resubmit-Job operation.
>> Mike - WDYT?
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Fri, Jun 23, 2017 at 6:15 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
> Hi there,
>> Consider a scenario where a Printer receives a Create-Job operation with the following attributes:
>> job-password="12345678"
> job-password-encryption='none'
> job-save-disposition=
> {
> save-disposition='save-only'
> save-info=
> {
> save-location="whatever"
> save-document-format=application/pdf
> }
> }
>> 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
>> 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.
>> Thoughts?
>> Smith
>> /**
> Smith Kennedy
> 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
> HP Inc.
> */
>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170625/984e6f94/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170625/984e6f94/attachment.p7s>