attachment-0001
Hi Pete et al,<br><br>Right - if the all Printers in the chain are in the same security domain<br>and are capable of actually impersonating the original Job owner then<br>this works.<br><br>If the Job submitter (a given Printer) is *not* the Job Owner in some cases,<br>
then this tends to break the access control stuff around cancel. <br><br>That is, the intervening Job submitter Printer has to sneak around and use <br>Admin privilege to cancel a job that *it* in fact submitted - this produces some <br>
very hard to trace and correlate accounting logs across the multiple Printers,<br>I think, but what the heck...<br><br>I'm glad Mike's happy with the changes - whatever the result was???<br><br>Cheers,<br>- Ira<br>
<br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music/High North Inc<br><a style="color:rgb(51, 51, 255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a style="color:rgb(102, 0, 204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div>
</div><div></div><div></div><div></div><br>
<br><br><div class="gmail_quote">On Wed, Nov 16, 2011 at 2:29 PM, Zehler, Peter <span dir="ltr"><<a href="mailto:Peter.Zehler@xerox.com">Peter.Zehler@xerox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Ira,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I work for Xerox and we build production and enterprise systems. It is within those products that the inconsistency within the rfc3998 was at issue. I am not proposing anything for cloud printing. Although in at least some Cloud Print environments this job forwarding semantics does not apply anyway. The job is never forwarded. The job remains in the cloud and the printer updates the job status there. I see no need to restrict developers from creating insecure unaccountable products. The market will decide. <u></u><u></u></span></p>
<div class="im"><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Pete<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:navy">Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br><br></span><span style="font-size:10.0pt;color:navy">Xerox Research Center Webster<br>
</span><span style="font-size:10.0pt;color:navy">Email: <a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Voice: <a href="tel:%28585%29%20265-8755" value="+15852658755" target="_blank">(585) 265-8755</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">FAX: <a href="tel:%28585%29%20265-7441" value="+15852657441" target="_blank">(585) 265-7441</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Xerox Corp.</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">M/S 128-25E</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Webster NY, 14580-9701</span><span style="font-size:11.0pt;color:#1F497D"> </span><span style="color:#1F497D"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p></div><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Ira McDonald [mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, November 16, 2011 1:58 PM<br><b>To:</b> Zehler, Peter; Ira McDonald<br><b>Cc:</b> Michael Sweet; <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a></span></p><div><div class="h5"><br><b>Subject:</b> Re: [IPP] Proposed errata for rfc3998<u></u><u></u></div>
</div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Hi Pete,<br><br>That proxy via the same directory service in the same security domain<br>under a TLS tunnel is one thing.<br><br>
But how do you propose that it could possibly apply in the case that<br>one or more Cloud providers and and an entirely different target domain<br>all participate to print the original client's job - letting that original client<br>
directly cancel jobs on those downstream printers is going to cause real<br>headaches of accounting and security.<br><br>Cheers,<br>- Ira<br><br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>
Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br><a href="http://sites.google.com/site/blueroofmusic" target="_blank"><span style="color:#3333FF">http://sites.google.com/site/blueroofmusic</span></a><br><a href="http://sites.google.com/site/highnorthinc" target="_blank"><span style="color:#6600CC">http://sites.google.com/site/highnorthinc</span></a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>
Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><u></u><u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt"><br><br><u></u><u></u></p><div>
<p class="MsoNormal">On Wed, Nov 16, 2011 at 1:38 PM, Zehler, Peter <<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Ira,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Well I guess we just have broken systems here that use the same backend directory service. And does that mean schemes such as OAUTH are broken as well? I’m not advocating doing strong downstream or passing client secrets along. All that is required in a fan out environment is the child trust the parent. If it is a secure system it certainly won’t depend on the “requesting-user-name” and it will have a special administrative role assigned to the parent printer. The initial printer can authenticate the client. If access is permitted at the target printer then the target printer has to tie into the same authorization domain as the initial printer.</span><u></u><u></u></p>
<div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Pete</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:navy">Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br><br></span><span style="font-size:10.0pt;color:navy">Xerox Research Center Webster<br>Email: <a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Voice: <a href="tel:%28585%29%20265-8755" target="_blank">(585) 265-8755</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">FAX: <a href="tel:%28585%29%20265-7441" target="_blank">(585) 265-7441</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Xerox Corp.</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">M/S 128-25E</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Webster NY, 14580-9701</span><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
</div><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Ira McDonald [mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>] <br><b>Sent:</b> Wednesday, November 16, 2011 1:08 PM</span><u></u><u></u></p>
<div><p class="MsoNormal"><br><b>To:</b> Michael Sweet; Ira McDonald<u></u><u></u></p></div><p class="MsoNormal"><b>Cc:</b> Zehler, Peter; <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><u></u><u></u></p><div>
<div><p class="MsoNormal"><br><b>Subject:</b> Re: [IPP] Proposed errata for rfc3998<u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Hi,<br><br>OK - I'm mostly with Mike here.<br>
<br>Also, I'm pretty strongly *not* with Bill and Pete - the forwarding Printers<br>OWN the downstream Jobs and have the Job submission and access<br>control and upstream notification receipt rights.<br><br>The original Job owner (on the cellphone) queries the *original* Job at<br>
the first Printer (the Cloud Print Service, typically) to see the rolled-up<br>and summarized results of the downstream Job processing.<br><br>Letting the original Job submitter cancel Jobs on way downstream Printers<br>is a severe security violation that breaks any possible scheme of access<br>
control.<br><br>Where would the authentication credentials come when the downstream<br>Jobs were created by the intervening Printers.<br><br>Because I assure you that the Printers *cannot* have the private key of the <br>
original Job owner and cannot keep doing strong downstream authentication <br>in so-called proxy operations (and the assumption that simple username and<br>password can just be sent forward out-of-band is hopelessly broken).<br>
<br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music/High North Inc<br><a href="http://sites.google.com/site/blueroofmusic" target="_blank"><span style="color:#3333FF">http://sites.google.com/site/blueroofmusic</span></a><br>
<a href="http://sites.google.com/site/highnorthinc" target="_blank"><span style="color:#6600CC">http://sites.google.com/site/highnorthinc</span></a><br>mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" target="_blank">734-944-0094</a><br>Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" target="_blank">906-494-2434</a><u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Nov 16, 2011 at 12:55 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<u></u><u></u></p>
<div><p class="MsoNormal">Pete,<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">My point about forwarding is that the mechanism for authenticating the original-requesting-user-name and job-originating-user-name values over IPP is undefined. How/why do the child printers implicitly trust everything that is sent to them from the parent printer?<u></u><u></u></p>
</div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">But again, the current wording makes original-requesting-user-name and job-originating-user-name distinctly different: original-requesting-user-name is the value that was supplied by the client while job-originating-user-name is the most authenticated name. Your proposed change would effectively make them the same, in which case we should:<u></u><u></u></p>
</div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">1. Remove forwarding of job-originating-user-name entirely,<u></u><u></u></p></div><div><p class="MsoNormal">2. Delete original-requesting-user-name entirely, or<u></u><u></u></p>
</div><div><p class="MsoNormal">3. Make original-requesting-user-name exclusively an operation attribute and use it to pass the forwarded job-originating-user-name value in the fan-out case (this would, IMHO, be the sanest approach).<u></u><u></u></p>
</div><div><div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><p class="MsoNormal">On Nov 16, 2011, at 9:23 AM, Zehler, Peter wrote:<u></u><u></u></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Mike,</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div><div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">The semantics are limited to Job forwarding systems of printers (i.e. IPP Fan out and fan in). On the first system the Job’s “original-job-requesting-user-name” and “job-originating-user-name” are populated with the same value. Per rfc2911 that value is the most authenticated printable name that it can obtain from the authentication service over which the IPP operation was received. Only if such is not available, does the Printer object use the value supplied by the client in the "requesting-user-name". On the next hop is where things diverge. The upstream printer uses its own identity in the “requesting-user-name” operational attribute. It also passes along the “original-requesting-user-name” as an operational attribute. The downstream printer uses the “requesting-user-name”, or the identity obtained from a trusted protocol layer, to insure the request is from a configured upstream printer. The downstream printer then copies over the “original-job-requesting-user-name” operational attribute to the job object AND to the job object’s “job-originating-user-name”. In other words the child job is owned by the initial submitting user throughout the chain and not by the immediate parent (i.e. IPP Printers).</span><u></u><u></u></p>
</div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Pete</span><u></u><u></u></p></div><div><p class="MsoNormal">
<span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:navy">Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br>
<br></span><span style="font-size:10.0pt;color:navy">Xerox Research Center Webster<br>Email: <a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Voice: <a href="tel:%28585%29%20265-8755" target="_blank">(585) 265-8755</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">FAX: <a href="tel:%28585%29%20265-7441" target="_blank">(585) 265-7441</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Xerox Corp.</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">M/S 128-25E</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Webster NY, 14580-9701</span><u></u><u></u></p></div></div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;border-width:initial;border-color:initial">
<div><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Michael Sweet [mailto:<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>] <br><b>Sent:</b> Wednesday, November 16, 2011 10:47 AM<br>
<b>To:</b> Zehler, Peter<br><b>Cc:</b> <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br><b>Subject:</b> Re: [IPP] Proposed errata for rfc3998</span><u></u><u></u></p></div></div></div><div><p class="MsoNormal">
<u></u><u></u></p></div><div><p class="MsoNormal">Pete,<u></u><u></u></p></div><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">If we make this change, then what is the difference between original-requesting-user-name and job-originating-user-name?<u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">Section 10.8.4 (re)defines job-originating-user-name as the authenticated original user and whose value is supposed to be forwarded by each client unchanged... (something I am not 100% happy with since there is no provision for it in an IPP job submission)<u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">Seems like the original intent was for original-requesting-user-name to be the unauthenticated value.<u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">(and now I go off to add some text for this to JPS3 for job-originating-user-uri...)<u></u><u></u></p></div></div><div>
<div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><p class="MsoNormal">On Nov 16, 2011, at 3:17 AM, Zehler, Peter wrote:<u></u><u></u></p></div></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">
<u></u><u></u></p></div><div><div><div><p class="MsoNormal"><span style="color:#1F497D">Please substitute “</span><span style="color:black">section 10.8.3 of rfc3998” for “section 10.8.8 of rfc3998” below.</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
</div></div><div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:navy">Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br>
<br></span><span style="font-size:10.0pt;color:navy">Xerox Research Center Webster<br>Email: <a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Voice: <a href="tel:%28585%29%20265-8755" target="_blank">(585) 265-8755</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">FAX: <a href="tel:%28585%29%20265-7441" target="_blank">(585) 265-7441</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Xerox Corp.</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">M/S 128-25E</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Webster NY, 14580-9701</span><u></u><u></u></p></div></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div>
</div><div><div style="border:none;border-top:solid windowtext 3.0pt;padding:3.0pt 0in 0in 0in;border-width:initial;border-color:initial;border-width:initial;border-color:initial"><div><div><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:ipp-bounces@pwg.org" target="_blank">ipp-bounces@pwg.org</a> <a href="mailto:[mailto:ipp-bounces@pwg.org]" target="_blank">[mailto:ipp-bounces@pwg.org]</a> <b>On Behalf Of </b>Zehler, Peter<br>
<b>Sent:</b> Wednesday, November 16, 2011 6:13 AM<br><b>To:</b> <a href="mailto:IPP@pwg.org" target="_blank">IPP@pwg.org</a><br><b>Subject:</b> [IPP] Proposed errata for rfc3998</span><u></u><u></u></p></div></div></div></div>
<div><div><p class="MsoNormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="color:black">All,</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal">
<span style="color:black"> </span><u></u><u></u></p></div></div><pre><span style="font-size:12.0pt;color:black">Section 10.8.2 covering “original-requesting-user-name” is a bit misleading. The issue is that the Job owner is not always the same as the “requesting-user-name”. When forwarding jobs from one printer to another the “original-requesting-user-name” is the most authenticated printable name that can be obtained. As stated in section 10.8.8 of rfc3998: “The "job-originating-user-name" Job Description attribute (see [RFC2911], section 4.3.6) remains as the authenticated original user”. This is inconsistent with section 10.8.2 as currently written. Below is my proposed change to section 10.8.2.</span><u></u><u></u></pre>
<div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black">Original:</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black">10.8.2. original-requesting-user-name (name(MAX)) Operation and Job</span><u></u><u></u></p></div>
</div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> Description Attribute</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> </span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> The operation attribute containing the user name of the original</span><u></u><u></u></p></div></div>
<div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> user; i.e., corresponding to the "requesting-user-name" operation</span><u></u><u></u></p></div></div>
<div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> attribute (see [RFC2911], section 3.2.1.1) that the original client</span><u></u><u></u></p></div></div><div>
<div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> supplied to the first Printer object. The Printer copies the</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal">
<span style="font-size:10.0pt;font-family:"Courier New";color:black"> "original-requesting-user-name" operation attribute to the</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> corresponding Job Description attribute.</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt">Corrected:</span><u></u><u></u></p></div></div>
<div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black">10.8.2. original-requesting-user-name (name(MAX)) Operation and Job</span><u></u><u></u></p></div></div><div><div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> Description Attribute</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> </span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> The operation attribute containing the user name of the original</span><u></u><u></u></p></div></div>
<div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> user; i.e., corresponding to the <span style="background:yellow">"job-originating-user-name" Job</span></span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black;background:yellow"> attribute (see [RFC2911], section 4.3.6)</span><span style="font-size:10.0pt;font-family:"Courier New";color:black"> that identifies the <span style="background:yellow">Job</span></span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black;background:yellow"> owner on</span><span style="font-size:10.0pt;font-family:"Courier New";color:black"> the first Printer object. The Printer copies the</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> "original-requesting-user-name" operation attribute to the</span><u></u><u></u></p></div>
</div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> corresponding Job Description attribute.</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal">
<span style="font-size:11.0pt"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:navy">Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br>
<br></span><span style="font-size:10.0pt;color:navy">Xerox Research Center Webster<br>Email: </span><span style="font-size:11.0pt"><a href="mailto:Peter.Zehler@Xerox.com" target="_blank"><span style="font-size:10.0pt">Peter.Zehler@Xerox.com</span></a><span style="color:#1F497D"><br>
</span></span><span style="font-size:10.0pt;color:navy">Voice: <a href="tel:%28585%29%20265-8755" target="_blank">(585) 265-8755</a></span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">FAX: <a href="tel:%28585%29%20265-7441" target="_blank">(585) 265-7441</a></span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">Xerox Corp.</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;color:#1F497D"><br></span><span style="font-size:10.0pt;color:navy">M/S 128-25E</span><span style="font-size:11.0pt;color:#1F497D"><br>
</span><span style="font-size:10.0pt;color:navy">Webster NY, 14580-9701</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal">
<br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is <br>believed to be clean.<u></u><u></u></p></div></div>
<div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Geneva","serif""><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is <br>
believed to be clean. _______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a></span><u></u><u></u></p>
</div></div></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Monaco","serif";color:black">________________________________________________________________________</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Monaco","serif";color:black">Michael Sweet, Senior Printing System Engineer, PWG Chair</span><u></u><u></u></p></div>
</div><div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Monaco","serif";color:black"> </span><u></u><u></u></p></div></div></div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Geneva","serif";color:black"> </span><u></u><u></u></p>
</div></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p></div></div><div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></blockquote></div><p class="MsoNormal"> <u></u><u></u></p>
<div><div><div><div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Monaco","serif";color:black">________________________________________________________________________</span><u></u><u></u></p>
</div><div><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Monaco","serif";color:black">Michael Sweet, Senior Printing System Engineer, PWG Chair</span><u></u><u></u></p></div></div></div>
</div></div><p class="MsoNormal"> <u></u><u></u></p></div><p class="MsoNormal"><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is <br>
believed to be clean. <u></u><u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><u></u><u></u></p></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></div><p class="MsoNormal">
<u></u> <u></u></p></div></div></div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px;" id="avg_ls_inline_popup"></div>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.