attachment
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
p.IEEEStdsParagraph, li.IEEEStdsParagraph, div.IEEEStdsParagraph
{mso-style-name:"IEEEStds Paragraph";
margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
text-align:justify;
font-size:12.0pt;
font-family:"Arial","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>How brief is the Identify signal? It will probably be both implementation and identify type dependent. A 10-second flash of a message on a screen on a printer would probably be useless unless the observer were already looking at the screen. But a 10- second beep might be more than enough. Ideally, the implementation would allow local cancel, so the person for whom the identify was intended could shut it off. But I think that allowing for remote cancel is desirable, if not mandatory.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The idea of illustrations for Identify is interesting. Consideration of the identify capability requires going from the conceptual to the physical, and points out an inconsistency between the IPP model and (at least my conception of ) the Semantic Model (which has hung up Cloud work.) Coming out of the MFD work, an SM Device is “</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>An abstract object representing a hardware component that implements one or more Imaging Services.” Further, an SM System is “The object handling interaction that needs to be with the MFD as an entity rather than a specific Service”. </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> It can therefore be argued that the System elements refer to the Device. And is must be the physical device that is identified. </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>IPP evolves from a “Printer” entity and, as far as I can tell, the concept of System does not yet exist…there are just Services. I suspect that in IPP, the System Control Service will refer to the “Printer”, notwithstanding that rather nebulous definition of Printer as “Listener for incoming IPP session requests and receiver of incoming IPP operation requests that represents one or more Physical Devices or a Logical Device. “ (but would appreciate being corrected if that is wrong). An IPP Physical Device is “a hardware implementation of a endpoint device, e.g., a marking engine, a fax modem, etc.”, that appears to correspond to a subunit in the Semantic Model, and cannot be addressed by a Client. <o:p></o:p></span></p><p class=IEEEStdsParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Because the IPP Physical Device is what should be identified but cannot be accessed, I recognize and agree with Mike’s contention that IPP Identify should be a Service operation since the User requesting Identify is communicating with an Imaging Service and the Service usually knows what IPP Device it is using (although, in a case such as a Print Service using multiple marking engines, perhaps not). Perhaps this carries over to the SM, so that Identify operations to a Service cause an identification of the endpoint subunit used by that Service (although it most cases, the Identify will be of the MFD). Going from the Abstract to the Physical has some problems.<o:p></o:p></span></p><p class=IEEEStdsParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thanks,<o:p></o:p></span></p><p class=IEEEStdsParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] <b>On Behalf Of </b>Kennedy, Smith (Wireless Architect)<br><b>Sent:</b> Tuesday, December 10, 2013 12:31 PM<br><b>To:</b> Ira McDonald; Michael Sweet<br><b>Cc:</b> <ipp@pwg.org><br><b>Subject:</b> Re: [IPP] RFC: Identify-Printer mini-extension<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Does limiting the duration obviate the need for the additions, then? If the duration is brief, why provide a cancel option?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>Smith<br><br><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On 2013-12-10, at 10:17 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div><div><div><div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>I was wrong.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>I agree with Mike and Smith that it's a service-level operation.<o:p></o:p></p></div><p class=MsoNormal>I also agree with Mike that we should not add "identify duration"<o:p></o:p></p></div><p class=MsoNormal>at all. The identity action should be brief (seconds, not minutes).<o:p></o:p></p></div><p class=MsoNormal>Otherwise, it becomes an annoyance for a shared workgroup<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>printer in the modern (barbarian) cubicles style of office.<o:p></o:p></p></div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><p class=MsoNormal> - Ira<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<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 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Dec 10, 2013 at 12:07 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>I agree with Mike on this. If I am a client and communicating with / using IPP Printers hosted on an IPP print server, I would want the Identify-Printer to map to the IPP Printer, which may or may not be implemented as a sub-system of the physical hardware of the print server (as represented by the System Control Service).<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>From that cloud discussion the other day, and this topic, I really feel like we need to have pictures, so that people can discuss topics from unambiguous scenarios. Trying to verbally describe the topology of a graph of edges and vertices can be awfully error prone.<o:p></o:p></p></div><div><p class=MsoNormal><span class=hoenzb><span style='color:#888888'><o:p> </o:p></span></span></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><span style='color:#888888'>Smith<br><br></span><o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On 2013-12-10, at 9:36 AM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><p class=MsoNormal>Ira,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Dec 10, 2013, at 8:51 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Bill,<o:p></o:p></p></div><p class=MsoNormal>I agree with you - that's what I was realizing when I wrote my previous note.<o:p></o:p></p></div><p class=MsoNormal>Identify-Xxx is a device-level operation.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I disagree, Identify-Xxx is a service-level operation that causes the identification of any physical device(s) associated with that service. We don't provide device interfaces, just service interfaces...<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><p class=MsoNormal>BTW - what about conflicts between two different services that receive <br>conflicting Identify-Xxx operations (or cancels)?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>AFAIK, coordination of subunits between services is implementation-defined behavior. If one service is using the buzzer then another service has to wait (or error-out) to use it.<o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>IMHO, cancel should only apply to the identification done by that service, not to all services.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>- Ira<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<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><o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Ira,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I suggest that what is being identified is the physical device, and that the System Control Service is the proper recipient. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill Wagner</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:ipp-bounces@pwg.org" target="_blank">ipp-bounces@pwg.org</a> [mailto:<a href="mailto:ipp-bounces@pwg.org" target="_blank">ipp-bounces@pwg.org</a>] <b>On Behalf Of </b>Ira McDonald<br><b>Sent:</b> Monday, December 09, 2013 5:37 PM<br><b>To:</b> Kennedy, Smith (Wireless Architect)<br><b>Cc:</b> <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>><br><b>Subject:</b> Re: [IPP] RFC: Identify-Printer mini-extension</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Hi Smith,<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Tricky. The "identify action duration" would be a new attribute (which<br>would require a revision of JPS3 spec - yuck).<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Mike's right that IPPSIX is the wrong place to do this - the conformance<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>shouldn't have anything to do with IPPSIX.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I also don't think that System Control Service should get into this business<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>- or maybe I'm crazy and that actually is the *right* place? Should SCS,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>rather than an individual service, be the target of this device-level operation?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Someday, we need a lightweight IPP registration for whole new attributes<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(in an existing attribute group), I suspect.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>- Ira<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<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><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Dec 9, 2013 at 5:28 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>IMHO, these look fine. I wonder if the “identify action duration” needs to be covered by something? Does the System Control Service need to concern itself with this domain?<br><span style='color:#888888'><br>Smith</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br><br><br>On 2013-12-09, at 12:53 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<br><br>> All,<br>><br>> During our last Cloud Imaging Model WG meeting, we discussed having the ability to explicitly cancel a previous Identify-Printer operation. The consensus during that meeting was to add a new "identify-actions" keyword ('cancel') that would cancel any active identification mechanism.<br>><br>> In addition, a new "printer-state-reasons" keyword ('identifying-printer' was proposed, although given the existing 'identify-printer-requested' value I like adding 'identify-printer-active' instead) would be added to allow a Client to discover whether a printer is currently identifying itself using an action other than 'cancel', which by definition stops any active identification and removes the new keyword from the "printer-state-reasons" attribute...<br>><br>> The official registration would look like this:<br>><br>> Attributes (attribute syntax)<br>> Keyword Attribute Value Reference<br>> ----------------------- ---------<br>> identify-actions (1setOf type2 keyword) [PWG5100.13]<br>> cancel<br>><br>> printer-state-reasons (1setOf type2 keyword) [RFC2911]<br>> identify-printer-active<br>><br>> Thoughts?<br>><br>> (I considered adding this to IPPSIX, but since this has application outside of shared infrastructure/cloud deployments I think we should register it separately...)<br>><br>> _______________________________________________________________<br>> Michael Sweet, Senior Printing System Engineer, PWG Chair<br>><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><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;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><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>_______________________________________________<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><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>_______________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>_______________________________________________<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><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>