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

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

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

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Thu Feb 11 07:54:13 UTC 2016


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.
*/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20160211/676dfa83/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20160211/676dfa83/attachment.p7s>


More information about the ipp mailing list