Bill,
> On Jul. 25, 2018, at 6:50 PM, wamwagner at comcast.net wrote:
>> Michael,
> Thank you for the information. I don’t mean to overly push a point, but making job-reprint-password an operations attribute just seems wrong and may contribute to the misunderstanding of its purpose. Job-password is inherently an operation attribute, and the references you provide point out that it is not returned in a response. So it is not clear why we cannot specify job-reprint-password as a job attribute that is never returned. That is, I do not understand why security information can be specially handled for operation attributes but not for job attributes. Is it perhaps some coding implementation issue?
If you define an attribute to be a Job Description, Job Template, or Job Status attribute, you are declaring that the attribute is something that can be returned by the Get-Job-Attributes and Get-Jobs operations (per the semantics of those operations). But an operation attribute has to have explicitly defined semantics (like we have for requesting-user-name getting copied to job-originating-user-name) before it becomes exposed by those operations.
> And perhaps I was unclear on the remote reprint request subject, but my point was that if a user were to give reprint access to another user, he could provide the job ID or job UID as well as the password. If a remote reprint capability were desired, I suggest that an operation could be defined to use that information to access the appropriate job and allow remote reprint.
But again the semantics of the Resubmit-Job operation only allows the Job Owner, administrators, and operators to reprint just any job. We'd need to amend the semantics to allow other users to do it...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180725/682ad840/attachment.html>