Michael,
Thank you for your response. Perhaps I misunderstand, but in regard to your first comment, “Security attributes are not exposed as Job Description/Status/Template attributes …”, do you mean expose via a Het-Jobs or Get-Job-Attributes request? But in regard to this request, RFC 8011 says in with regard to both opertions:
The IPP object ignores (does not respond with) any requested attribute or value which is not supported or which is restricted by the security policy in force, including whether the requesting user is the user that submitted the job (job originating user) or not (see section 8).
Are Job Description attributes exposed in some other way?
With respect to remote reprint request, if a user is provided with the password, could he not also be provided with the name and/or location of the job? Might a Get-Jobs operation be adequate?
Thanks,
Bill Wagner
From: Michael Sweet
Sent: Monday, July 23, 2018 7:27 PM
To: William A Wagner
Cc: Kennedy, Smith (Wireless & Standards Architec); PWG IPP WG Reflector
Subject: Re: [IPP] Another updated stable draft of IPP Reprint Passwordpostedfor review
Bill,
Some responses to your feedback are inline below...
On Jul. 23, 2018, at 2:53 PM, wamwagner at comcast.net wrote:
...
1. I would argue that this should be a Job Description attribute rather than an Operation attribute, because it stays with the Job and is really an attribute of the job rather than any IPP operation. I also suggest that this attribute should not in itself cause Job Save, since IPP already has the “job-save-disposition” (collection) Job Template attribute and there are other implementation dependent job retention factors. This would also preclude the automatic saving of copied jobs.
Security attributes are not exposed as Job Description/Status/Template attributes as that will expose the very credentials that would be required to reprint the job from the console.
As for not causing a Job Save, JPS2 already has an implicit/lightweight local save that happens when you use the proof-print Job Template attribute - the semantics of Proof Print are that "I am printing a draft/proof copy of this job and intend to print more copies if the proof copy is good." Similarly, specifying a "job-reprint-password" operation attribute specifies that you intend to print more copies of the job at a later time. Perhaps using "Job Save" is the sticking point here - perhaps just saying "Job Retention" is enough?
1. It may be desirable to make clear the distinction between Job Password, Document Password and Job Reprint Password in this specification. I would suggest a simple statement of the purpose of these three passwords.
a. document-password [PWG5100.13] is an operation attribute provided with a Print-Job, Print-URI, Send-Document, or Send-URI operation to allow access to the document content, typically to "unlock" a previously password-protected PDF or OpenXPS document. The value supplied is retained by the Printer as long as the corresponding Document is retained.
b. job-password [PWG5100.11] is an operation attribute optionally provided with a Print-Job, Print-URI, or Create-Job operation to cause a submitted job to be held in a 'pending-held' state until the password value is submitted to the printing device. The method in which the password is entered and validated at the Printer is implementation dependent. The job-password value is not saved with the Job.
c. job-reprint-password is [a Job Description or an operation attribute] optionally provided with a Print-Job, Print-URI, or Create-Job operation that (if accepted by the Printer), causes the submitted job-reprint-password to be saved with the retained Job. It does not affect the processing of the job in any other way. Although IPP does allow a retained job to be reprinted via Resubmit-Job, this capability is only available if the user performing this operation is the job owner or an operator or administrator of the Printer object. However, if outside of IPP, the Printer provides a user with the ability to reprint retained jobs, and the desired Job has been tagged with a job-reprint-password, the user must supply that password to get access to the job for reprint (or any other purpose?)
Just for reprint. And I like this as a summary of the differences between the three attributes.
4. As far as I can tell, reprinting a job is not a defined IPP operation nor is it clear to me why giving access to an IPP retained Job by some means other than IPP can restrict how that job is used. At any rate, from the discussion, the identified job (which is somehow selected by the user) is not itself affected in any way other than by being copied and, since "most operation attributes do not persist beyond the life of the operation" that new job is printed (whatever than might involve) following operation attributes defined by the user when he has, by whatever means outside of IPP, initiated "reprint" of a selected IPP job.
We have Restart-Job (deprecated), Reprint-Job (deprecated), and Resubmit-Job (the recommended replacement for the previous two). All of these have the typical "Job owner, operator, or administrator" for the access rights (policy), but when reprinting from the console there is often no way to do traditional authentication (thus the invention of PIN printing, etc.)
5. The original use case of allowing remote reprint was eliminated, although if the purpose of Job Reprint Password is solely to allow access to a retained IPP Job, (rather than to act as a Job Password for a reprinted Job), it would seem that remote reprint is a useful feature. Would it be that cumbersome to change an operation such as ResubmitJob to bestow job ownership (of the copied Job) to a user having the password?
We could definitely add that in, but how would a user that is not the job owner, an operator, or an administrator discover a job that could be reprinted?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180724/6bb5abf7/attachment.html>