attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I've updated Section 4 like so - thoughts?<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><b class=""><font size="4" class="">4. Client Authentication Methods</font></b></div><div class=""><span style="font-size: 14px;" class="">Authentication is the process of establishing some level of trust that an entity is who or what they are claiming to be. A Printer uses the “authenticated identity” or the “most authenticated user” [RFC8011] to determine whether to allow the requesting Client access to capabilities such as operations, resources, and attributes. A Printer specifies its supported authentication methods via several IPP attributes. The “uri-authentication-supported” attribute [RFC8011] indicates the authentication method used for a corresponding URI in “printer-uri-supported” [RFC8011]. The “xri-authentication” member attribute of “printer-xri-supported” [RFC3380] specifies the same corresponding values, if the Printer implements the “printer-xri-supported” attribute. Each of the authentication method keywords currently registered for “uri-authentication-supported” is described in its own subsection below.</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><div class=""><strike class=""><span style="font-size: 14px;" class="">In cases where the Printer is not directly involved in the authentication process, such as </span><span style="font-size: 14px;" class="">when OAuth2 is used, or when the Printer depends on an external authentication service, </span><span style="font-size: 14px;" class="">the Printer might not be directly aware of the User's identity following authentication. In </span><span style="font-size: 14px;" class="">these cases, the Printer could still need to acquire the User's identity in order to accurately </span><span style="font-size: 14px;" class="">document the User's identity in the Job Object's Job Status attributes, or to support IPP </span><span style="font-size: 14px;" class="">operations such as Get-User-Printer-Attributes [IPPGUPA] that depend on the User's </span><span style="font-size: 14px;" class="">identity to provide meaningfully filtered operation responses.</span></strike></div><div style="font-size: 14px;" class=""><br class=""></div></div><div class=""><span style="font-size: 14px;" class="">When handing an IPP Job Creation request, the Printer will need to populate the Job's “job-originating-user-name” Job Status attribute. In cases where the Printer relies upon an external authentication service, it will need to acquire a meaningfully printable value from the authentication service.</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-size: 14px;" class="">The Printer or the Job might also need to store a token or identifier (UUID, JWT, etc.) that represents the User's authenticated identity or authentication session, in cases where the Printer depends on an external authorization service for print policy evaluation. This token is considered by IPP to be an internal implementation detail, and is not available to Clients via IPP, as discussed in [RFC8011] section 5.3.6.</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-size: 14px;" class="">One authentication system not described below is SAML (Security Assertion Markup Language)[SAMLCORE]. As of this writing, none of the standard SAML bindings to HTTP directly support IPP. SAML can indirectly support OAuth2 via a SAML / OAuth2 gateway. The bridge typically uses the SAML 2.0 assertion as an OAuth 2.0 Bearer token. Specific instructions for how to configure this depends on the SAML and OAuth2 system implementations, and is beyond the scope of this document.</span></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">
<div><br class=""><blockquote type="cite" class=""><div class="">On Mar 1, 2019, at 1:05 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <<a href="mailto:ipp@pwg.org" class="">ipp@pwg.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="protected-part"><div class="protected-title">Signed PGP part</div><div class="protected-content"><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for mentioning this detail, Bill! I am fine with adding that the purpose of authentication is to acquire a token to be used for access authorization. But after re-reading the definition of "job-originating-user-name" from RFC 8011, I'm not sure I agree that the value of the "job-originating-user-name" attribute itself is necessarily the token to be used. Notice the second paragraph, which talks about the Printer maintaining an "internal originating user ID of some form", which is "used for authorization checks" but isn't publicly visible:<div class=""><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Courier" class="">5.3.6. job-originating-user-name (name(MAX))</font></div><div class=""><font face="Courier" class=""> This REQUIRED attribute contains the name of the End User that</font></div><div class=""><font face="Courier" class=""> submitted the Print Job. The Printer sets this attribute to the most</font></div><div class=""><font face="Courier" class=""> authenticated printable name that it can obtain from the</font></div><div class=""><font face="Courier" class=""> authentication service over which the IPP operation was received.</font></div><div class=""><font face="Courier" class=""> Only if such a name is not available does the Printer use the value</font></div><div class=""><font face="Courier" class=""> supplied by the Client in the "requesting-user-name" operation</font></div><div class=""><font face="Courier" class=""> attribute of the Job Creation request (see Sections 5.4.2, 5.4.3,</font></div><div class=""><font face="Courier" class=""> and 9).</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class=""> Note: The Printer needs to keep an internal originating user ID of</font></div><div class=""><font face="Courier" class=""> some form, typically as a credential of a principal, with the Job.</font></div><div class=""><font face="Courier" class=""> Since such an internal attribute is implementation dependent and not</font></div><div class=""><font face="Courier" class=""> of interest to Clients, it is not specified as a Job attribute. This</font></div><div class=""><font face="Courier" class=""> originating user ID is used for authorization checks (if any) on all</font></div><div class=""><font face="Courier" class=""> subsequent operations.</font></div></div></blockquote><div class=""><br class=""></div><div class="">So the value of "job-originating-user-name" could be some printable name string, but that value isn't itself necessarily the token that would be used by the Printer's "backend" implementation to engage with a particular authentication service. And that token has no IPP Job Status attribute and is considered by IPP to be an internal implementation detail. </div><div class=""><div class=""><br class=""><div class="">
Smith<br class=""><br class=""><br class="">
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 1, 2019, at 12:21 PM, <a href="mailto:wamwagner@comcast.net" class="">wamwagner@comcast.net</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Both Michael and Smith make good points, and I think it is mainly a question of how far Smith wants to extend the scope of the document. From his earlier message, it appears that he has added more information on Authorization. However, his comment that the purpose of Authentication in a printer is primarily to support Authorization features is quite to the point. Indeed, the text might point out that the extended authentication mechanisms discussed relate to obtaining the value of the IPP attribute job-originating-user-name, which is used by the printer for authorization checks. That is,<span class="Apple-converted-space"> </span><span style="font-family: Consolas;" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> The Printer sets this attribute to the most<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> authenticated printable name that it can obtain from the<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> authentication service over which the IPP operation was received.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> Only if such a name is not available does the Printer use the value<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> supplied by the Client in the "requesting-user-name" operation<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: Consolas;" class=""> attribute of the Job Creation request.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Of course, from Michael’s point, discussion of printer-implemented authorization in this document is probably limited to restating what is in STD92: using the<span class="Apple-converted-space"> </span><span style="font-family: Consolas;" class="">most authenticated printable name for authorization and IPP responses to authentication failures.<span class="Apple-converted-space"> </span></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks,<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Bill Wagner<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; border: none; padding: 0in;" class=""><b class="">From:<span class="Apple-converted-space"> </span></b><a href="mailto:smith.kennedy@hp.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Kennedy, Smith (Wireless & Standards Architect)</a><br class=""><b class="">Sent:<span class="Apple-converted-space"> </span></b>Friday, March 1, 2019 10:49 AM<br class=""><b class="">To:<span class="Apple-converted-space"> </span></b><a href="mailto:msweet@msweet.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Michael Sweet</a><br class=""><b class="">Cc:<span class="Apple-converted-space"> </span></b><a href="mailto:wamwagner@comcast.net" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">William A Wagner</a>;<span class="Apple-converted-space"> </span><a href="mailto:Christopher.Rizzo@xerox.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Rizzo, Christopher</a>;<span class="Apple-converted-space"> </span><a href="mailto:RYardumian@ciis.canon.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Rick Yardumian</a>;<span class="Apple-converted-space"> </span><a href="mailto:ipp@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">PWG IPP Workgroup</a><br class=""><b class="">Subject:<span class="Apple-converted-space"> </span></b>Re: [IPP] WG Last Call: IPP Authentication Methods</div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">How about this:<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><blockquote style="margin-left: 30pt; margin-right: 0in;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 13.5pt;" class="">3.4. Out of Scope</span></b><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt;" class="">The following are considered out of scope for this document:</span><o:p class=""></o:p></div></div><div class=""><ol start="1" type="1" style="margin-bottom: 0in;" class=""><li class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt;" class="">Definition of new HTTP authentication methods</span><o:p class=""></o:p></li><li class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt;" class="">Definition of how specific authorization mechanisms are used by an IPP Printer. The Internet Printing Protocol/1.1 [STD92] defines authorization roles for end users, operators, and administrators, but does not define how a Printer or an authorization mechanism maps those roles to authenticated users.</span><o:p class=""></o:p></li></ol></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Feb 28, 2019, at 5:00 PM, Michael Sweet <<a href="mailto:msweet@msweet.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">msweet@msweet.org</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;">Bill,<br class=""><br class="">I think you make a good point.<br class=""><br class="">Smith,<br class=""><br class="">I think you can make a general statement about authorization, something along the lines of:<br class=""><br class="">"Specific authorization mechanisms are outside the scope of this document. The Internet Printing Protocol/1.1 [STD92] defines authorization roles for end users, operators, and administrators, but does not define how a Printer maps those roles to authenticated users."<br class=""><br class=""><br class="">> On Feb 28, 2019, at 5:50 PM, wamwagner--- via ipp <<a href="mailto:ipp@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">ipp@pwg.org</a>> wrote:<br class="">><span class="Apple-converted-space"> </span><br class="">> Smith,<br class="">><span class="Apple-converted-space"> </span><br class="">> Sorry, my confusion continues. Your new Authorization example may be valid, but it seems odd to me that someone would have an account in a printer but not have authority to print at all. Conditional authority, restricting use to certain times or restricting color, or quantity, etc. would be more realistic, but that is at the IPP level and does not appear to be addressed in this specification.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> The title is Authentication Methods, and although I may have missed it, I do not think that it does much with authorization (at least not by the printer), which would occur after successful Authentication. Perhaps the Authorization use case should be put in the out of scope section?<br class="">> Thanks, Bill W.<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> From: Rizzo, Christopher via ipp<br class="">> Sent: Thursday, February 28, 2019 4:12 PM<br class="">> To: Kennedy, Smith (Wireless & Standards Architect); Rick Yardumian<br class="">> Cc: PWG IPP WG Reflector<br class="">> Subject: Re: [IPP] WG Last Call: IPP Authentication Methods<br class="">><span class="Apple-converted-space"> </span><br class="">> This update looks good to me.<br class="">><span class="Apple-converted-space"> </span><br class="">> Thanks,<br class="">> Chris<br class="">><span class="Apple-converted-space"> </span><br class="">> Christopher Rizzo<br class="">> Xerox Corporation<br class="">> GDG/Discovery/Advance Technology<br class="">> 26600 SW Parkway Ave.<br class="">> Wilsonville, OR 97070-9251<br class="">> Phone: (585) 314-6936<br class="">><span class="Apple-converted-space"> </span><a href="mailto:Christopher.Rizzo@xerox.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Email: Christopher.Rizzo@xerox.com</a><br class="">><span class="Apple-converted-space"> </span><br class="">> "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."<br class="">> -Maurice Wilkes, Memoirs of a Computer Pioneer<br class="">><span class="Apple-converted-space"> </span><br class="">> From: "Kennedy, Smith (Wireless & Standards Architect)" <<a href="mailto:smith.kennedy@hp.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">smith.kennedy@hp.com</a>><br class="">> Date: Thursday, February 28, 2019 at 12:36 PM<br class="">> To: Christopher Rizzo <<a href="mailto:Christopher.Rizzo@xerox.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Christopher.Rizzo@xerox.com</a>>, Rick Yardumian <<a href="mailto:RYardumian@ciis.canon.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">RYardumian@ciis.canon.com</a>><br class="">> Cc: PWG Workgroup <<a href="mailto:ipp@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">ipp@pwg.org</a>><br class="">> Subject: Re: [IPP] WG Last Call: IPP Authentication Methods<br class="">><span class="Apple-converted-space"> </span><br class="">> Thanks for the feedback Chris! I also received this feedback from Canon's Rick Yardumian (CC'ed). In my LCRC draft, I've resolved this issue by rewriting 3.3.2 to more meaningfully describe an authorization failure.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> Here's the rewrite. Any objections or suggestions?<br class="">><span class="Apple-converted-space"> </span><br class="">> Harry is also visiting Andy's office and wants to print from his laptop. He uses his laptop to discover available printers, and selects one listed. The printer is configured to limit access to only authorized users.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> The printer challenges the laptop for authentication, and the laptop presents an authentication dialog to Harry. Harry has an account, and enters the account's username and password. The printer accepts these credentials, but that account is not authorized to access that printer. Harry's laptop shows a notification dialog expressing this to Harry. Harry clicks “OK” and looks for a pencil.<br class="">><span class="Apple-converted-space"> </span><br class="">> Smith<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> On Feb 28, 2019, at 12:33 PM, Rizzo, Christopher <<a href="mailto:Christopher.Rizzo@xerox.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Christopher.Rizzo@xerox.com</a>> wrote:<br class="">><span class="Apple-converted-space"> </span><br class="">> Just curious, but section 3.3 Exceptions of this document has sections 3.3.1 and 3.3.2 which are pretty much exact duplicates of each other, exception being Lisa vs. Harry. Was this intentional?<br class="">><span class="Apple-converted-space"> </span><br class="">> Thanks,<br class="">> Chris<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> Christopher Rizzo<br class="">> Xerox Corporation<br class="">><span class="Apple-converted-space"> </span><br class="">> GDG/Discovery/Advance Technology<br class="">><span class="Apple-converted-space"> </span><br class="">> 26600 SW Parkway Ave.<br class="">><span class="Apple-converted-space"> </span><br class="">> Wilsonville, OR 97070-9251<br class="">><span class="Apple-converted-space"> </span><br class="">> Phone: (585) 314-6936<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><a href="mailto:Christopher.Rizzo@xerox.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Email: Christopher.Rizzo@xerox.com</a><br class="">><span class="Apple-converted-space"> </span><br class="">> "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."<br class="">> -Maurice Wilkes, Memoirs of a Computer Pioneer<br class="">><span class="Apple-converted-space"> </span><br class="">> On 1/17/19, 4:00 PM, "ipp on behalf of Kennedy, Smith (Wireless & Standards Architect)" <<a href="mailto:ipp-bounces@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">ipp-bounces@pwg.org</a><span class="Apple-converted-space"> </span>on behalf of<span class="Apple-converted-space"> </span><a href="mailto:smith.kennedy@hp.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">smith.kennedy@hp.com</a>> wrote:<br class="">><span class="Apple-converted-space"> </span><br class="">> Greetings,<br class="">><span class="Apple-converted-space"> </span><br class="">> This message begins the IPP workgroup Last Call of the IPP Authentication Methods best practice draft, available at:<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><a href="https://protect-us.mimecast.com/s/QCrsCn5XpXTDmDQ0iJ1m_N?domain=ftp.pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117.odt</a><br class="">><span class="Apple-converted-space"> </span><a href="https://protect-us.mimecast.com/s/HISOCo2KqKhYvYJNTV4CIm?domain=ftp.pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117.pdf</a><br class="">><span class="Apple-converted-space"> </span><a href="https://protect-us.mimecast.com/s/GAoKCpYK0KioAoPrTGLYMd?domain=ftp.pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190117-rev.pdf</a><br class="">><span class="Apple-converted-space"> </span><br class="">> Please respond with any feedback or comments by doing a "reply all" to this message.<br class="">><span class="Apple-converted-space"> </span><br class="">> This last call will end on January 31, 2019 at 10pm PT.<br class="">><span class="Apple-converted-space"> </span><br class="">> Cheers,<br class="">> Smith<br class="">><span class="Apple-converted-space"> </span><br class="">> /**<br class="">> Smith Kennedy<br class="">> HP Inc.<br class="">> */<br class="">><span class="Apple-converted-space"> </span><br class="">> _______________________________________________<br class="">> ipp mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:ipp@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">ipp@pwg.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://protect-us.mimecast.com/s/tmYaCmZ6o6hlWlGwHGZ8k0?domain=pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://www.pwg.org/mailman/listinfo/ipp</a><br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> _______________________________________________<br class="">> ipp mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:ipp@pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">ipp@pwg.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://protect-us.mimecast.com/s/tmYaCmZ6o6hlWlGwHGZ8k0?domain=pwg.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://www.pwg.org/mailman/listinfo/ipp</a><br class=""><br class="">________________________<br class="">Michael Sweet</p></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></div></div>
</div></div><br class=""><iframe class="untrusted-content-test" scrolling="auto" width="200" height="20" style="border:none;display:block;overflow:auto;" data-src="data:text/html;charset=UTF-8;base64,PGlmcmFtZS1jb250ZW50Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPmlwcCBtYWlsaW5nIGxpc3Q8QlI+aXBwQHB3Zy5vcmc8QlI+aHR0cHM6Ly9wcm90ZWN0LXVzLm1pbWVjYXN0LmNvbS9zL3RtWWFDbVo2bzZobFdsR3dIR1o4azA/ZG9tYWluPXB3Zy5vcmc8QlI+PC9pZnJhbWUtY29udGVudD4=" sandbox="allow-scripts"></iframe></div></blockquote></div><br class=""></div></body></html>