Subject: [IPP] A couple of late bits of feedback on 2911bis

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 11 Feb 2016 07:54:13 +0000

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 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-07#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 

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"?  

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.

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Thu, 11 Feb 2016 08:49:20 -0800

Smith,

Thanks for this, comments inline…

> On Feb 10, 2016, at 11:54 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Hi there,
> 
>  to a Printer, the Printer MUST 
> either
> (1) reject the request with the
> Appendix B.1.4.1) or 
> (2) process the request normally after selecting

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…

> 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…

I’ll work something up…

>   Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF

___________________________________________
Michael Sweet, Senior Printing System Engineer