attachment
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi there,<br class=""><br class="">I had a few bits of late feedback on the original RFC 2911, that seem to be still there in draft 07 of 2911bis.<br class=""><br class="">1. Section 4.1.3 paragraph 3 says:<div class=""><br class=""></div><div class=""><pre class="newpage" style="margin-top: 0px; margin-bottom: 0px; page-break-before: always;"><span style="font-size: 12px;" class=""> The attributes within a group MUST be unique; if an attribute with
the same name occurs more than once, the group is malformed. Clients
MUST NOT submit such malformed requests and Printers MUST NOT return
such malformed responses. If such a malformed request is submitted
to a Printer, the Printer MUST <font color="#ff2600" class="">either</font> (1) reject the request with the
'client-error-bad-request' status code (RECOMMENDED - see
<a href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-07#appendix-B.1.4.1" class="">Appendix B.1.4.1</a>) or <font color="#ff2600" class="">(2) process the request normally after selecting
only one of the attribute instances, depending on implementation.
Which attribute is selected when there are duplicate attributes
depends on implementation.</font> The IPP Printer MUST NOT use the values
from more than one such duplicate attribute instance.</span></pre><div class=""><br class=""></div>I really dislike that there was an "either" in this paragraph. I understand that the (2) was included to grandfather in some buggy IPP/1.0 implementations, but it seems like this second <br class=""><br class=""><br class="">2. In the last paragraph of section 4.1.3, it says:<br class=""><br class=""><div class=""><font face="Courier" style="font-size: 12px;" class=""> When an IPP object receives a</font></div><div class=""><font face="Courier" style="font-size: 12px;" class=""> request to perform an operation it does not support, <font color="#ff2600" class="">it returns the</font></font></div><div class=""><font face="Courier" style="font-size: 12px;" class=""><font color="#ff2600" class=""> 'server-error-operation-not-supported' status code</font> (see</font></div><div class=""><font face="Courier" style="font-size: 12px;" class=""> Appendix B.1.5.2). An IPP object is non-conformant if it does not</font></div><div class=""><font face="Courier" style="font-size: 12px;" class=""> support a REQUIRED operation.</font></div><div class=""><br class=""></div>I don't understand why there is not a normative statement in the red phrase above - "it MUST return the 'server-error-operation-not-supported' status code"? <div class=""><br class=""></div><div class=""><br class=""></div><div class="">3. As Mike pointed out to me at the end of today's IPP WG session, section 2.3.11 discusses the "design pattern" for job attribute definitions where to support a job template attribute "xxx" there are "xxx-supported" and "xxx-default" attributes also defined to support this. But 2.3.11 doesn't seem to discuss the "printer settings" attribute tuple consisting of "xxx-configured" and "xxx-supported". As we discussed, that should also be described, presumably in this same section.</div><div class=""><br class=""><br class=""><div class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> PWG Chair<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""><br class=""><br class=""></div><br class=""></div></div></body></html>