Smith,
Thanks for this, comments inline…
> On Feb 10, 2016, at 11:54 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> Hi there,
>> I had a few bits of late feedback on the original RFC 2911, that seem to be still there in draft 07 of 2911bis.
>> 1. Section 4.1.3 paragraph 3 says:
>> 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
> either
> (1) reject the request with the
> 'client-error-bad-request' status code (RECOMMENDED - see
>> Appendix B.1.4.1) or
> (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.
> The IPP Printer MUST NOT use the values
> from more than one such duplicate attribute instance.
>>> 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
I like the idea of dropping the option of ignoring this error, but then there is also a processing overhead associated with this that might cause performance/memory issues - we test for this in ipptool but not in cupsd or ippserver, for example, because doing the duplicate attribute checks are (at best) an O(n log n) problem with potentially unbounded memory usage. This problem is exacerbated by the fact that an implementation is supposed to enforce having attributes-charset and attributes-natural-language at the beginning, preventing storage of attribute groups in sorted arrays that would eliminate the parallel storage penalty…
> 2. In the last paragraph of section 4.1.3, it says:
>> When an IPP object receives a
> request to perform an operation it does not support, it returns the
> 'server-error-operation-not-supported' status code (see
> Appendix B.1.5.2). An IPP object is non-conformant if it does not
> support a REQUIRED operation.
>> 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”?
Agreed, this should be a MUST.
> 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.
I’ll work something up…
>>> Smith
>> /**
> Smith Kennedy
> Wireless Architect - Client Software - IPG-PPS
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
> PWG Chair
> HP Inc.
> */
>>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
___________________________________________
Michael Sweet, Senior Printing System Engineer