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?&nbsp; 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>&nbsp;</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&nbsp; 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.)&nbsp; Coming out of the MFD work, an SM Device is &#8220;</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.&#8221;&nbsp; Further,&nbsp; an SM&nbsp; System is &#8220;The object handling interaction that needs to be with the MFD as an entity rather than a specific Service&#8221;.&nbsp; </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;It can therefore be argued that the System elements refer&nbsp; 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 &#8220;Printer&#8221; entity&nbsp; and, as far as I can tell, the concept of System does not yet exist&#8230;there are just Services. I&nbsp; suspect that in IPP, the System Control Service will refer to the &#8220;Printer&#8221;, notwithstanding that rather nebulous definition of Printer as &#8220;Listener for incoming IPP session requests and receiver of incoming IPP operation requests that represents one or more Physical Devices or a Logical Device. &#8220; (but would appreciate being corrected if that is wrong).&nbsp; An IPP Physical Device is &#8220;a hardware implementation of a endpoint device, e.g., a marking engine, a fax modem, etc.&#8221;, 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&nbsp; IPP Physical Device is what should be identified but cannot be accessed, I recognize and agree with&nbsp; Mike&#8217;s contention that IPP Identify should be a Service operation since the User requesting Identify is communicating with an Imaging&nbsp; Service and the Service usually knows what IPP Device it is using (although, in a case such as &nbsp;a Print Service using multiple marking engines, perhaps not). &nbsp;Perhaps this carries over to the SM, so that Identify operations to a Service&nbsp; cause an identification of the endpoint subunit used by that Service (although it most cases, the Identify will be of the MFD). &nbsp;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>&nbsp;</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> &lt;ipp@pwg.org&gt;<br><b>Subject:</b> Re: [IPP] RFC: Identify-Printer mini-extension<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Does limiting the duration obviate the need for the additions, then? &nbsp;If the duration is brief, why provide a cancel option?<o:p></o:p></p><div><p class=MsoNormal><o:p>&nbsp;</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>&nbsp;</o:p></p><div><div><p class=MsoNormal>On 2013-12-10, at 10:17 AM, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>&gt; 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 &quot;identify duration&quot;<o:p></o:p></p></div><p class=MsoNormal>at all.&nbsp; 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>&nbsp;-&nbsp; Ira<o:p></o:p></p><div><p class=MsoNormal><o:p>&nbsp;</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 &amp; 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; 734-944-0094<br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; 906-494-2434<o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>On Tue, Dec 10, 2013 at 12:07 PM, Kennedy, Smith (Wireless Architect) &lt;<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>&gt; wrote:<o:p></o:p></p><div><p class=MsoNormal>I agree with Mike on this. &nbsp;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>&nbsp;</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. &nbsp;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>&nbsp;</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>&nbsp;</o:p></p><div><div><p class=MsoNormal>On 2013-12-10, at 9:36 AM, Michael Sweet &lt;<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>&gt; 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>&nbsp;</o:p></p><div><div><p class=MsoNormal>On Dec 10, 2013, at 8:51 AM, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt; 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>&nbsp;</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. &nbsp;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&nbsp;<br>conflicting Identify-Xxx operations (or cancels)?<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><p class=MsoNormal>AFAIK, coordination of subunits between services is implementation-defined behavior. &nbsp;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>&nbsp;</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>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal><o:p>&nbsp;</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>&nbsp;</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 &amp; 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; <a href="tel:734-944-0094" target="_blank">734-944-0094</a><br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; <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>&nbsp;</o:p></p><div><p class=MsoNormal>On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner &lt;<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>&gt; 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'>&nbsp;</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> &lt;<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>&gt;<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'>&nbsp;<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.&nbsp; The &quot;identify action duration&quot; 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?&nbsp; 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'>&nbsp;<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 &amp; 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; <a href="tel:734-944-0094" target="_blank">734-944-0094</a><br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; <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'>&nbsp;<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) &lt;<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>IMHO, these look fine. &nbsp;I wonder if the &#8220;identify action duration&#8221; needs to be covered by something? &nbsp;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 &lt;<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>&gt; wrote:<br><br>&gt; All,<br>&gt;<br>&gt; During our last Cloud Imaging Model WG meeting, we discussed having the ability to explicitly cancel a previous Identify-Printer operation. &nbsp;The consensus during that meeting was to add a new &quot;identify-actions&quot; keyword ('cancel') that would cancel any active identification mechanism.<br>&gt;<br>&gt; In addition, a new &quot;printer-state-reasons&quot; 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 &quot;printer-state-reasons&quot; attribute...<br>&gt;<br>&gt; The official registration would look like this:<br>&gt;<br>&gt; &nbsp;Attributes (attribute syntax)<br>&gt; &nbsp; &nbsp;Keyword Attribute Value &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Reference<br>&gt; &nbsp; &nbsp;----------------------- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ---------<br>&gt; &nbsp;identify-actions (1setOf type2 keyword) &nbsp; &nbsp; &nbsp; &nbsp; [PWG5100.13]<br>&gt; &nbsp; &nbsp;cancel<br>&gt;<br>&gt; &nbsp;printer-state-reasons (1setOf type2 keyword) &nbsp; &nbsp;[RFC2911]<br>&gt; &nbsp; &nbsp;identify-printer-active<br>&gt;<br>&gt; Thoughts?<br>&gt;<br>&gt; (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>&gt;<br>&gt; _______________________________________________________________<br>&gt; Michael Sweet, Senior Printing System Engineer, PWG Chair<br>&gt;<br>&gt; _______________________________________________<br>&gt; ipp mailing list<br>&gt; <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>&gt; <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'>&nbsp;<o:p></o:p></p></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</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>&nbsp;</o:p></p><div><div><p class=MsoNormal>_______________________________________________________________<br>Michael Sweet, Senior Printing&nbsp;System Engineer, PWG Chair<o:p></o:p></p></div></div><p class=MsoNormal><o:p>&nbsp;</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>&nbsp;</o:p></p></div></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>