attachment

<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">OK, I have updated the pending registrations at:<div><br></div><div>&nbsp; &nbsp; <a href="http://www.pwg.org/ipp/ipp-registrations.xml">http://www.pwg.org/ipp/ipp-registrations.xml</a></div><div><br></div><div>with the proposed changes.</div><div><br></div><div><br><div><div>On Mar 18, 2014, at 4:15 PM, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>Hi Mike,<br><br>I like your revised proposal better.<br></div><br></div>For the future, we should always use the suffix "Fault" in IANA Printer MIB<br>and "-fault" in IPP when new alerts need it for clarity (so that the IPP and<br>

</div><div>Printer MIB equivalents for severity can be used).<br></div><div><br></div>The "Error" suffix in PWG 5100.9 in IANA Printer MIB was a mistake (now <br>5 years old, sadly), because the separate prtAlertSeverityLevel object must <br>

always distinguish between and "critical" and "warning" (there is no such <br>thing as "report" in the Printer MIB, which is an original RFC 1759 bug).<br><br></div><div>Cheers,<br></div><div>

- Ira<br><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">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 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&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<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>

<div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 3:23 PM, Michael Sweet <span dir="ltr">&lt;<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">Ira,<div><br></div><div>I'm not sure about adoption on these keywords (I've never seen them in the wild), but I'm not keen on changing already-registered values.</div><div><br>

</div><div>Upon further review/thought, it seems to me that the xxx-recoverable-storage-error keywords could all have the -error, -report, or -warning (as appropriate) suffixes, while the xxx-unrecoverable-storage-error keywords all seem to require user interaction and should stop the printer. &nbsp;So as an alternative to my original proposal we could:</div>

<div><br></div><div>- Register all xxx-recoverable-storage-error keywords as xxx-recoverable-storage and note that implementations must choose the correct suffix (-error, -report, -warning) as appropriate.</div><div>- Keep the xxx-unrecoverable-storage-error keywords and note that the printer must be in the stopped state when reporting them.</div>

<div><br></div><div>The advantage is that existing implementations are unaffected, the mapping from the MIBs to IPP remains "clean", and we set precedent for printer-state-reasnos keywords: when registering a keyword with an -error, -report, or -warning suffix, that is the only allowed suffix for the keyword (no -error-error, -error-warning, etc.)</div>

<div><br></div><div>(I'm not super happy about the resulting registered names, but once you add a suffix the xxx-recoverable-storage-bla name sort of makes sense...)</div><div><div class="h5"><div><br></div><div><br>
<div>
<div>On Mar 17, 2014, at 4:53 PM, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt; wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>
<div>
<div><div><div><div><div><div><div>Hi Mike,<br><br></div>See my related reply about PWG 5107.3.<br><br></div>I suggest changing the IPP printer-state-reasons from "-error" to "-fault".<br>

<br></div>WARNING - all of the PWG 5100.9 extensions *were* registered in the<br></div>IANA Printer MIB and SMIv2 rules prevent our changing the names of<br></div>already assigned enumeration values, so the possible fix is different <br>



from my suggested one for PWG 5107.3.<br></div><br></div>WARNING - vendors (printer and management systems) who have used<br></div>the previously assigned PWG 5107.3 or PWG 5100.9 names and values<br></div>in the Printer MIB will have breakage if we change these "Error" suffixes<br>



</div>in the IANA Printer MIB.<br><br></div>I'll put this topic on the next IPP WG agenda for 31 March.<br><br></div>Cheers,<br></div>- Ira<br><br><div>&nbsp;<br></div></div><div class="gmail_extra"><br clear="all">

<div><div dir="ltr">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 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br>

<br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>

<div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 2:07 PM, Michael Sweet <span dir="ltr">&lt;<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



All,<br>
<br>
It was recently pointed out to me that PWG 5100.9 defines several "printer-state-reasons" keywords with the suffix "-error":<br>
<br>
&nbsp; &nbsp; subunit-recoverable-storage-error<br>
&nbsp; &nbsp; subunit-unrecoverable-storage-error<br>
&nbsp; &nbsp; bander-recoverable-storage-error<br>
&nbsp; &nbsp; bander-unrecoverable-storage-error<br>
&nbsp; &nbsp; binder-recoverable-storage-error<br>
&nbsp; &nbsp; binder-unrecoverable-storage-error<br>
&nbsp; &nbsp; die-cutter-recoverable-storage-error<br>
&nbsp; &nbsp; die-cutter-unrecoverable-storage-error<br>
&nbsp; &nbsp; folder-recoverable-storage-error<br>
&nbsp; &nbsp; folder-unrecoverable-storage-error<br>
&nbsp; &nbsp; imprinter-recoverable-storage-error<br>
&nbsp; &nbsp; imprinter-unrecoverable-storage-error<br>
&nbsp; &nbsp; inserter-recoverable-storage-error<br>
&nbsp; &nbsp; inserter-unrecoverable-storage-error<br>
&nbsp; &nbsp; make-envelope-recoverable-storage-error<br>
&nbsp; &nbsp; make-envelope-unrecoverable-storage-error<br>
&nbsp; &nbsp; perforater-recoverable-storage-error<br>
&nbsp; &nbsp; perforater-unrecoverable-storage-error<br>
&nbsp; &nbsp; puncher-recoverable-storage-error<br>
&nbsp; &nbsp; puncher-unrecoverable-storage-error<br>
&nbsp; &nbsp; separation-cutter-recoverable-storage-error<br>
&nbsp; &nbsp; separation-cutter-unrecoverable-storage-error<br>
&nbsp; &nbsp; sheet-rotator-recoverable-storage-error<br>
&nbsp; &nbsp; sheet-rotator-unrecoverable-storage-error<br>
&nbsp; &nbsp; slitter-recoverable-storage-error<br>
&nbsp; &nbsp; slitter-unrecoverable-storage-error<br>
&nbsp; &nbsp; stacker-recoverable-storage-error<br>
&nbsp; &nbsp; stacker-unrecoverable-storage-error<br>
&nbsp; &nbsp; stapler-recoverable-storage-error<br>
&nbsp; &nbsp; stapler-unrecoverable-storage-error<br>
&nbsp; &nbsp; stitcher-recoverable-storage-error<br>
&nbsp; &nbsp; stitcher-unrecoverable-storage-error<br>
&nbsp; &nbsp; trimmer-recoverable-storage-error<br>
&nbsp; &nbsp; trimmer-unrecoverable-storage-error<br>
&nbsp; &nbsp; wrapper-recoverable-storage-error<br>
&nbsp; &nbsp; wrapper-unrecoverable-storage-error<br>
<br>
However, RFC 2911 reserves this suffix for indicating the severity of the reason:<br>
<br>
&nbsp; &nbsp;4.4.12 printer-state-reasons (1setOf type2 keyword)<br>
<br>
&nbsp; &nbsp;This REQUIRED Printer attribute supplies additional detail about the<br>
&nbsp; &nbsp;device's state. &nbsp;Some of the these value definitions indicate<br>
&nbsp; &nbsp;conformance requirements; the rest are OPTIONAL.<br>
<br>
&nbsp; &nbsp;Each keyword value MAY have a suffix to indicate its level of<br>
&nbsp; &nbsp;severity. &nbsp;The three levels are: report (least severe), warning, and<br>
&nbsp; &nbsp;error (most severe).<br>
<br>
&nbsp; &nbsp; &nbsp; - '-report': &nbsp;This suffix indicates that the reason is a "report".<br>
&nbsp; &nbsp; &nbsp; &nbsp; An implementation may choose to omit some or all reports. Some<br>
&nbsp; &nbsp; &nbsp; &nbsp; reports specify finer granularity about the printer state;<br>
&nbsp; &nbsp; &nbsp; &nbsp; others serve as a precursor to a warning. A report MUST contain<br>
&nbsp; &nbsp; &nbsp; &nbsp; nothing that could affect the printed output.<br>
&nbsp; &nbsp; &nbsp; - '-warning': This suffix indicates that the reason is a<br>
&nbsp; &nbsp; &nbsp; &nbsp; "warning". &nbsp;An implementation may choose to omit some or all<br>
&nbsp; &nbsp; &nbsp; &nbsp; warnings. Warnings serve as a precursor to an error. A warning<br>
&nbsp; &nbsp; &nbsp; &nbsp; MUST contain nothing that prevents a job from completing, though<br>
&nbsp; &nbsp; &nbsp; &nbsp; in some cases the output may be of lower quality.<br>
&nbsp; &nbsp; &nbsp; - '-error': This suffix indicates that the reason is an "error".<br>
&nbsp; &nbsp; &nbsp; &nbsp; An implementation MUST include all errors. If this attribute<br>
&nbsp; &nbsp; &nbsp; &nbsp; contains one or more errors, printer MUST be in the stopped<br>
&nbsp; &nbsp; &nbsp; &nbsp; state.<br>
<br>
&nbsp; &nbsp;If the implementation does not add any one of the three suffixes, all<br>
&nbsp; &nbsp;parties MUST assume that the reason is an "error".<br>
<br>
Since an IPP Printer MAY report any of the above keywords when the Printer is not in the stopped state, I propose we add an informative note to table 5-2 saying something like the following:<br>
<br>
&nbsp; &nbsp; Note 1: Section 4.4.12 [RFC2911] requires that the Printer is in the<br>
&nbsp; &nbsp; stopped state when reporting "printer-state-reasons" values ending<br>
&nbsp; &nbsp; with "-error". Printers MUST append a suffix of "-report" or<br>
&nbsp; &nbsp; "warning" to this keyword when the Printer is not in the stopped<br>
&nbsp; &nbsp; state.<br>
<br>
I'm not sure if we want to clarify that the "job-state-reasons" attribute only contains the registered values without added suffixes.<br>
<br>
_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<br>
<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><br>
<br></blockquote></div><br></div>
</blockquote></div><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><div style="word-wrap:break-word">

_________________________________________________________<br>Michael Sweet, Senior Printing System&nbsp;Engineer, PWG Chair</div></span></span>
</div>
<br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System&nbsp;Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>