Internet Printing Protocol/1.1: Encoding and Transport

IPP Printers SHOULD (rather than MUST) support Digest Authentication because low-end devices with limited ROM space may not need client authentication and forcing such devices to implement security to claim conformance would not make business sense and could stall adoption of the standard.

security

The target URI is encoded twice — once as the HTTP Request-URI and once as an IPP operation attribute — to maintain a consistent set of rules for mapping application/ipp to possibly many communication layers, even where URLs are not used as the addressing mechanism in the transport layer.

http

Clients MUST send requests with version-number '1.1' and SHOULD try alternate version numbers on receiving 'server-error-version-not-supported'. IPP objects MUST accept requests with version-number '1.1', and it is recommended they accept any request with major version '1'.

Security MUST NOT be compromised when a client supplies an 'http' or other non-secure URL scheme in the target printer-uri and job-uri operation attributes. The client's choice of URL scheme in the request must not cause the server to relax security enforcement.

security

When returning job-printer-uri or job-uri attributes, the server SHOULD return the same URL scheme the client supplied in the query request. If a server registers a non-secure ipp-URL with a directory service, it is recommended to also register an http-URL for interoperability with IPP/1.0 clients.

A client MUST supply the target URI of an operation both as an HTTP Request-URI and as an operation attribute within the application/ipp body. The operation attribute target URI MUST be an absolute URI; the HTTP layer URI may be relative or absolute.

http

A receiver MUST be able to process both (a) a begin-attribute-group-tag with zero following attribute fields and (b) an expected but missing begin-attribute-group-tag as equivalent empty attribute groups.

An HTTP server MUST support chunking for IPP requests, and an IPP client MUST support chunking for IPP responses per HTTP/1.1. The spec notes this may conflict with non-compliant HTTP/1.1 implementations that do not support chunking for POST methods or CGI scripts.

http

Each HTTP operation MUST use the POST method where the request-URI is the object target, and the Content-Type of the message-body in each request and response MUST be 'application/ipp'. A printer implementation MUST support HTTP over IANA Well Known Port 631.

http

For out-of-band value-tag fields (such as 'unsupported'), the value-length MUST be 0 and the value MUST be empty. For binary signed integer attribute types, the sender MUST encode the value in exactly four octets. For character-string types, the sender MUST encode without padding characters.

If an IPP status-code is returned, the HTTP Status-Code MUST be 200 (successful-ok). With any other HTTP Status-Code value, the HTTP response MUST NOT contain an IPP message-body, and thus no IPP status-code is returned.

http

The end-of-attributes-tag (0x03) MUST occur exactly once in an operation and MUST be the last delimiter-tag. If the operation has a document-content group, the document data MUST follow the end-of-attributes-tag.

The operation layer MUST contain a single IPP operation request or IPP operation response. Each request or response consists of a sequence of values and attribute groups, and MUST use the encoding described in sections 3.1 and 3.2.

When converting an ipp-URL for HTTP transport, a client MUST: (1) change the 'ipp' scheme to 'http', and (2) add explicit port 631 if no explicit port is present. The client MUST use the http-URL in the HTTP Request-Line and headers but MUST retain the ipp-URL in the application/ipp operation attribute.

http

Delimiter tags occupy values 0x00–0x0F: 0x00 reserved, 0x01 operation-attributes-tag, 0x02 job-attributes-tag, 0x03 end-of-attributes-tag, 0x04 printer-attributes-tag, 0x05 unsupported-attributes-tag, 0x06–0x0F reserved for future IETF standards-track delimiters. A Printer MUST treat delimiter-tag values differently from value-tag values.

Tag value 0x7F is reserved for extending the type space beyond 255 values: when this tag is present, the first 4 bytes of the value field are interpreted as the actual tag value. Values 0x00–0x37777777 are reserved for IETF standards track; 0x40000000–0x7FFFFFFF are reserved for vendor extensions.

The 'ipp' URL scheme identifies IPP printer or job objects with implicit default port 631. It is intended as the value for the job attributes job-uri and job-printer-uri, the printer attribute printer-uri-supported, and the operation attributes job-uri and printer-uri. The 'ipp' scheme implies the same protocol semantics as 'http' except for the default port.

http

Value tags (0x10–0xFF) specify attribute value types. Out-of-band: 0x10 unsupported, 0x12 unknown, 0x13 no-value. Integer types: 0x21 integer, 0x22 boolean, 0x23 enum. OctetString types: 0x31 dateTime, 0x32 resolution, 0x33 rangeOfInteger, 0x35 textWithLanguage, 0x36 nameWithLanguage. Character-string types: 0x41 textWithoutLanguage, 0x42 nameWithoutLanguage, 0x44 keyword, 0x45 uri, 0x46 uriScheme, 0x47 charset, 0x48 naturalLanguage, 0x49 mimeMediaType.

Appendix B registers the MIME media type 'application/ipp' with IANA for encoding IPP operations. All IPP HTTP request and response message bodies MUST use Content-Type: application/ipp. Extensions to attribute syntaxes, attribute groups, and out-of-band values follow the 'type2' registration procedures defined in RFC 2911 section 6.

registry, http

IPP/1.1 uses the 'Upgrading to TLS Within HTTP/1.1' mechanism [RFC2817]. An initial IPP request never uses TLS; the client requests TLS via the HTTP 'Upgrade' header and the server agrees in the response. Security MUST NOT be compromised when a client supplies a lower version-number parameter.

security, tls, http

IPP clients MUST support Digest Authentication [RFC2617] with MD5 and MD5-sess. IPP Printers SHOULD support Digest Authentication with MD5 and MD5-sess. The Message Integrity feature need not be used.

security, http

IPP Printers SHOULD support TLS [RFC2246] for Server Authentication and Operation Privacy. If TLS is supported, the Printer MUST support TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. IPP clients supporting TLS MUST also support that cipher suite. All other cipher suites are OPTIONAL.

security, tls

An additional-value (for multi-valued attributes) is encoded as: value-tag (1 byte), name-length (2 bytes, value is 0x0000), value-length (2 bytes), and value. The zero name-length is the only mechanism for encoding multi-valued attributes and distinguishes additional-value from attribute-with-one-value.

An attribute-with-one-value is encoded as: value-tag (1 byte specifying attribute syntax), name-length (2-byte SIGNED-SHORT), name (u bytes), value-length (2-byte SIGNED-SHORT), and value (v bytes). A name-length of zero signals an additional-value for the preceding attribute rather than a new attribute.

An IPP request or response is encoded as: version-number (2 bytes), operation-id or status-code (2 bytes), request-id (4 bytes), zero or more attribute-groups (variable length), end-of-attributes-tag (1 byte, always required), and optional data. The end-of-attributes-tag is always present even when data is absent.

http

dateTime is encoded as an 11-octet OCTET-STRING per RFC 1903 DateAndTime. resolution is 9 octets: two SIGNED-INTEGERs (cross-feed direction, then feed direction) followed by a SIGNED-BYTE (units). rangeOfInteger is 8 octets: two SIGNED-INTEGERs (lower bound, then upper bound).

Every integer in IPP encoding MUST be encoded as a signed integer using two's-complement binary encoding in big-endian (network) order. Width is 1 octet (SIGNED-BYTE) for version-number and tags, 2 octets (SIGNED-SHORT) for operation-id, status-code, and length fields, and 4 octets (SIGNED-INTEGER) for value fields and request-id.

textWithLanguage and nameWithLanguage values are encoded as an OCTET-STRING of four sub-fields: (a) SIGNED-SHORT giving the octet count of the natural-language value, (b) the natural-language value, (c) SIGNED-SHORT giving the octet count of the text/name value, (d) the text/name value. Total length MUST equal 4 + field-a + field-c.

The version-number field is encoded as two SIGNED-BYTEs: major version-number first, then minor version-number. IPP/1.1 MUST have the ABNF %x01.01 (major=1, minor=1).