Internet Printing Protocol/1.1: Encoding and Transport

Digest Authentication is SHOULD rather than MUST for IPP conformance because low-end devices with limited ROM space may not need client authentication. Forcing such devices to support security would not make business sense and would increase cost without proportional benefit.

http, security

The tag value 0x7f is reserved as an extension mechanism: when this tag appears, the first four bytes of the value field are interpreted as the actual tag value, enabling type definitions beyond the 255 values available with a single byte without breaking parsers unaware of this extension.

http

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

http

TLS support is SHOULD rather than MUST because previous versions of the specification did not require it, so backward compatibility prevents mandating it for IPP/1.1. Implementors are nonetheless strongly encouraged to include TLS support because printing often involves sensitive information and pervasive network monitoring is a real threat (RFC 7258).

http, security, tls

IPP objects SHOULD understand any valid request whose major version-number is greater than 0, and respond with the Client-supplied version-number if supported or the highest supported version-number otherwise. This design makes supporting multiple IPP versions straightforward.

http

When a Printer returns job-printer-uri or job-uri attributes, it SHOULD return the same URI scheme ('ipp' or 'ipps') that the Client supplied in the request target operation attributes, rather than the scheme used when the Job was originally created.

http

A Client MUST supply the target of the operation both as an operation attribute in the application/ipp body and as a URI at the HTTP layer. The target URI in the IPP operation attribute MUST be an absolute URI.

http

A receiver of a request MUST treat as equivalent empty attribute groups both: (a) a begin-attribute-group-tag with zero following attribute fields, and (b) a missing but expected begin-attribute-group-tag field.

http

An HTTP/1.1 server MUST support chunking for IPP requests, and an IPP Client MUST support chunking for IPP responses per HTTP/1.1.

http

Clients MUST send requests with the highest supported version-number and SHOULD retry with alternate version numbers if they receive 'server-error-version-not-supported'. IPP objects MUST accept requests with version-number '1.1' or reject them for reasons other than version unsupported.

http

Each HTTP operation MUST use the POST method; the Content-Type of the message body in each request and response MUST be 'application/ipp'. A Client MUST adhere to HTTP client rules and a Printer MUST adhere to HTTP origin server rules.

http

For binary signed integer attribute values the sender MUST encode in exactly four octets; for binary signed byte values (e.g., boolean) exactly one octet; for character strings without padding; and for out-of-band value-tags the value-length MUST be 0.

http

If an IPP status-code is returned, the HTTP status-code MUST be 200 (OK). With any other HTTP status-code, the HTTP response MUST NOT contain an IPP message body.

http

Printer implementations MUST support HTTP over IANA-assigned well-known port 631 (the IPP default port), though support for other ports is also allowed.

http

Security MUST NOT be compromised when a Client supplies a lower version-number parameter. For example, an IPP/2.0 Printer enforcing Digest Authentication MUST enforce it equally for version 1.1 requests.

http, security

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

http

The operation layer MUST contain a single IPP operation request or response, and an operation request or response MUST use the encoding described in the specification.

http

When converting an ipp-URI for the HTTP layer, the Client MUST change the 'ipp' scheme to 'http' (or 'ipps' to 'https') and add explicit port 631 if no port is specified. The ipp-URI or ipps-URI MUST be used for operation attributes within the application/ipp body.

http

Delimiter tags separate major protocol sections. Defined values: 0x00 (Reserved), 0x01 (operation-attributes-tag), 0x02 (job-attributes-tag), 0x03 (end-of-attributes-tag), 0x04 (printer-attributes-tag), 0x05 (unsupported-attributes-tag). Tags 0x06-0x0f are reserved for future group extensions.

http, registry

Integer types are encoded as big-endian two's-complement signed integers. SIGNED-BYTE (1 octet) is used for version-number and tag fields; SIGNED-SHORT (2 octets) for operation-id, status-code, and length fields; SIGNED-INTEGER (4 octets) for value fields and request-id.

http

IPP uses two URI schemes: 'ipp' (RFC 3510) mapping to HTTP on port 631, and 'ipps' (RFC 7472) mapping to HTTPS on port 631. Clients and Printers MUST support ipp-URI values in job-uri, job-printer-uri, printer-uri-supported, and related operation attributes.

http

Out-of-band value-tag values indicate special attribute states: 0x10 (unsupported), 0x12 (unknown), 0x13 (no-value). For these out-of-band tags the value-length MUST be 0 and the value empty.

http

Value tags specify the type of each attribute value. Integer tags: 0x21 (integer), 0x22 (boolean), 0x23 (enum). OctetString tags include 0x31 (dateTime), 0x32 (resolution), 0x33 (rangeOfInteger), 0x34 (begCollection), 0x37 (endCollection). Character-string tags include 0x41 (textWithoutLanguage), 0x44 (keyword), 0x45 (uri), 0x47 (charset), 0x4a (memberAttrName).

http, registry

The IPP IANA registry (IANA-IPP) contains the 'Attribute Group Tags' registry (delimiter tags 0x00-0x0f), the 'Out-of-Band Attribute Value Tags' registry (0x10, 0x12, 0x13), and the 'Attribute Syntaxes' registry (integer, octetString, and character-string value-tags). Unassigned values in each range are reserved for future standards.

http, registry

This document updates the 'application/ipp' MIME media type registration. The type is 'application', subtype 'ipp', with no required or optional parameters. Encoding always contains binary data; charset and natural-language context are self-contained within IPP requests/responses.

http, registry

Because IPP Printers typically use self-signed X.509 certificates, IPP Clients SHOULD support Trust On First Use (RFC 7435) in addition to traditional X.509 certificate validation.

http, security, tls, pkix

IPP Clients and Printers SHOULD support Digest Authentication (RFC 7616). Implementations that do support Digest Authentication MUST support SHA2-256 and SHOULD support MD5 for backwards compatibility only; MD5 has been deprecated by RFC 7616.

http, security

IPP Clients and Printers SHOULD support TLS for Server Authentication and Operation Privacy. Basic Authentication MAY be supported only over secure channels (HTTPS); IPP Clients and Printers SHOULD NOT support Basic Authentication over insecure channels.

http, security, tls

The Printer MUST enforce its security and privacy policies based on the owner of the IPP object and the URI scheme and/or credentials supplied by the Client in the current request.

http, security

A collection attribute begins with value-tag 0x34 (begCollection), name-length, name, and value-length 0x0000, followed by member-attribute fields, and terminates with end-value-tag 0x37 (endCollection) with both name-length and value-length set to 0x0000.

http

A member-attribute within a collection is encoded as: value-tag 0x4a (memberAttrName), name-length 0x0000, value-length (w bytes), value containing the member attribute name, followed by member-value-tag, name-length 0x0000, member-value-length, and member-value.

http

An additional-value (for multi-valued attributes) is encoded as: value-tag (1 byte), name-length set to 0x0000 (2 bytes), value-length (2 bytes), and value (variable bytes). A name-length of 0 distinguishes additional-values from attribute-with-one-value fields.

http

An attribute-with-one-value is encoded as: value-tag (1 byte), name-length (2 bytes, SIGNED-SHORT), name (variable bytes), value-length (2 bytes, SIGNED-SHORT), and value (variable bytes). The value-tag specifies the attribute syntax (e.g., 0x44 for keyword).

http

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-group fields (variable), end-of-attributes-tag (1 byte), and optional data (variable bytes).

http

Attribute value encodings by syntax type: textWithLanguage and nameWithLanguage are OCTET-STRINGs with two SIGNED-SHORT length prefixes and embedded natural-language and text values. The resolution type is 9 octets: two SIGNED-INTEGERs (cross-feed and feed direction) followed by a SIGNED-BYTE (units). rangeOfInteger is 8 octets: two SIGNED-INTEGERs for lower and upper bound.

http