IPP Mail Archive: IPP> Text for IPPv2 Conformance

IPP> Text for IPPv2 Conformance

From: Michael R Sweet (msweet@apple.com)
Date: Mon Jul 21 2008 - 18:37:35 EDT

  • Next message: William A Wagner: "IPP> Minutes -IPPv2 Conference Call Monday (7/21) @ 4:00 PM EDT (1:00 PM PDT)"

    Here is some suggested text for section 6 of the IPPv2 spec:

         6 CONFORMANCE

         6.1 IPP CONFORMANCE

         The current IPP specification [RFC2911] requires that IPP
         attributes received, that are not supported or not understood,
         are to be processed according to the defined procedures, and
         an appropriate status code returned. Many implementations
         historically have not conformed to this requirement, causing
         communications problems and failed printing.

         To claim compliance with any of the IPPv2 versions, an
         implementation MUST correctly process attributes, values, or
         groups that are not supported per RFC 2911, sections 3.1.7,
         3.1.8, 3.2.1.2, 3.3.5.1, 3.3.7.1, 4.1.2.3, and 13.1.2.2,
         including collection attributes as defined in RFC 3382,
         section 7.

         For example, implementations MUST support reading the IPP
         noValue tag as a valid value for an attribute that normally
         would be encoded as an enum, integer, name, or keyword value
         tag. Similarly, implementations MUST correctly process (or
         ignore) collection values as defined by RFC 3382, even if
         the implementation does not support the media-col attribute
         itself.

         6.2 HTTP CONFORMANCE

         The current IPP specification [RFC2911] requires transport
         over HTTP/1.1 as defined in RFC 2616. Many implementations
         historically have not used a HTTP/1.1 transport or provided
         complete HTTP/1.1 support.

         To claim compliance with any of the IPPv2 versions, an
         implementation MUST support the complete HTTP/1.1 protocol
         as defined in RFC 2616, including chunking as defined in
         section 3.6.1 and the Expect header as defined in section
         5.3.

         In addition, implementations supporting TLS encryption MUST
         support the HTTP Upgrade protocol as defined in RFC 2817.

    -- 
    ______________________________________________________________________
    Michael R Sweet                        Senior Printing System Engineer
    


    This archive was generated by hypermail 2.1.4 : Mon Jul 21 2008 - 18:37:41 EDT