attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Mike and Daniel,<div><br></div><div>The IPP Implementor's Guide v2.0 sections 4.2 "Validate User Access to Printer" and 4.3 "Get Printer Options" covers this, though as Mike pointed out there are some details here that would need to be more fully covered to make it clear that if the client has authenticated in any way when validating access, it should use that same authenticating identity when getting printer information and print job options.</div><div><br></div><div>I'm trying to get another draft out today (I know, promises, promises) and I've added a new sub-bullet to 4.2 to further discuss this.</div><div><br></div><div>Daniel, thanks for bringing this issue up!</div><div><br><div>
Smith<br><br><br>
</div>
<br><div><div>On 2013-10-01, at 5:28 AM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>></div><div> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Daniel,<div><br></div><div><br></div><div><div>The recommended practice for Clients is to send an empty Validate-Job request (just printer-uri and requesting-user-name) to verify the selection of the Printer by the User - this verifies access to the Printer and allows the Printer to require authentication. If authenticated, subsequent requests to the Printer will include the negotiated HTTP credentials, per RFC 2616/2617.</div><div><br></div><div>When the Client next sends a Get-Printer-Attributes request with the existing credentials, the Printer MAY return a filtered list of Job Template attributes and values that the Client/User is authorized to use - the printer-get-attributes-supported attribute tells the Client which attributes are used for filtering the returned values. The presence of "requesting-user-name" indicates that the Printer will use the most-authenticated user name, per the usual RFC 2911 usage of requesting-user-name for requests.</div><div><br></div><div>I would be happy to add a paragraph specifically about this to the Transaction-Based Printing Extensions specification - it would be an excellent editorial comment as part of your vote for the PWG Formal Vote of the spec that was recently approved by the Steering Committee,</div><div><br></div><div>We should also make the consequences of the HTTP security model clear in Smith's IPP Implementers Guide 2.0 document as well - a User Agent re-uses the Authentication header in subsequent requests to the same origin for the duration of the User Agent's "session", e.g., the life of a web browser process, the life of a print job submission, etc.</div><div><br></div></div><div><br></div><div><br></div><div>On Oct 1, 2013, at 1:14 AM, Manchala, Daniel <<a href="mailto:Daniel.Manchala@xerox.com">Daniel.Manchala@xerox.com</a>> wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:ArialMT;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1"><p class="MsoNormal">Current day printer driver user interfaces esp. those for mobile clients need a UI that displays only those capabilities that a user has before submitting a job (or grey out those features that are not available to certain users who do
not have the authorization / privileges / rights to use those features). We discussed the merits of using Validate-Job.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">The problem with Validate-Job as we discussed in one of our earlier IPP meetings is this (using a scenario):
<span style="color:#1F497D"> If there is a request for simplex printing in the Validate-Job request it means the user interface already allowed the user to select simplex printing. The desired scenario is that the UI only present the user (at the client interface)
with the capabilities they have. So I don't know that Validate-Job is useable to check for user capabilities (that the client uses first to determine capabilities).<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">Using the current definition of Validate-Job, one needs to perform job programming and validate it by sending a set of attributes regarding how the user wants their job to be programmed or processed. This is
not helpful for an UI (esp. mobile clients) that want to display to the user only those capabilities that the user is authorized to use (which is a sub set of all the Printer capabilities or a super set of a guest user whose capabilities are returned by a
Get-Printer-Attributes request).<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal">The request is to add a new operation “Get-User-Capabilities” wherein one submits user’s credentials along with the operation request so that the operation response contains a “job-authorization-uri” which in turn can be used to obtain
those capabilities of the Printer that the user has authorization to use or the operation response just contains the user’s capabilities for the Printer.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">In the former case, we need to m<span style="color:#1F497D">ake the following one small change to the IPP Transaction Based Printing spec.<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">Section 6.1.2 “job-authorization-uri (uri)” states:<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;font-family:"ArialMT","sans-serif"">The "job-authorization-uri" operation attribute specifies an implementation-specific URI representing an authorization or reservation code for
a print job creation request. It is returned by the Validate-Job operation (section 7.2) and supplied in the Create-Job, Print-Job, and Print-URI operations (section 7.1).<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">This should be extended as:<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">The “job-authorization-uri” would be returned by the new “Get-User-Capabilities” operation request. The authorization or reservation code represented by the “job-authorization-uri” could be used by Get-Printer-Attributes
request to return the authenticated user capabilities. <o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">The reason to make this change is because the unauthorized Get-Printer-Attributes returns a limited set of capabilities (e.g., the set of capabilities of a guest user) on a system that has authentication enabled.<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">If it is not acceptable to extend the semantics of “job-authorization-uri”, could we create a “user-authorization-uri” that could be used to get the user’s capabilities?<o:p></o:p></span></p><div><span style="color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">Daniel.<br>
<br>
<o:p></o:p></span></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a><br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></div>_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/ipp<br></blockquote></div><br></div></body></html>