Internet Printing Protocol/1.1: IPP URL Scheme
updates
- rfc-2910 — Internet Printing Protocol/1.1: Encoding and Transport
Extracted elements (20)
During development, consideration was given to adding standard IPP URL parameters for client authentication and security mechanisms, but based on strong IETF IPP Working Group consensus, no parameters were added for reasons of backwards compatibility with the many then-shipping IPP/1.1 implementations.
The IPP URL scheme is based on the ABNF for the HTTP URL scheme defined in RFC 2616, which is derived from URI Generic Syntax (RFC 2396) and updated for IPv6 by RFC 2732. An IPP URL is transformed into an HTTP URL according to rules in section 5 of RFC 2910.
IPP Printers SHOULD only generate IPP Job URLs (e.g., in the 'job-uri' attribute in a 'Print-Job' response) by appending exactly one path component to the corresponding IPP Printer URL, for interoperability. The transform from an IPP Job URL to the corresponding IPP Printer URL is otherwise unspecified.
All IPP URLs MUST be used to specify network print services which support the 'application/ipp' MIME media type for IPP protocol requests and responses.
All IPP URLs which do NOT explicitly specify a port MUST be resolved to IANA-assigned well-known port 631.
IPP Clients MUST only convert IPP URLs to their corresponding HTTP URL forms according to the rules in section 5 of RFC 2910.
IPP Clients MUST only send IPP protocol connections to the port specified in each given IPP URL (if present) or otherwise to IANA-assigned well-known port 631.
IPP Clients MUST only send IPP URLs used as protocol elements in outgoing IPP protocol request messages that conform to the ABNF specified in section 4.5 of this document.
IPP Printers MUST listen for incoming IPP protocol connections on IANA-assigned well-known port 631, unless explicitly configured by system administrators or site policies.
IPP Printers SHOULD NOT listen for incoming IPP protocol connections on any other port, unless explicitly configured by system administrators or site policies.
IPP Printers SHOULD NOT use literal IPv6 or IPv4 addresses in configured or locally generated IPP URLs.
IPP URLs MUST use RFC 2396 encoding, as do their equivalent HTTP URLs. Characters other than those in the 'reserved' and 'unsafe' sets are equivalent to their '%HEX HEX' encoding.
The abstract protocol defined in IPP Model (RFC 2911) places a limit of 1023 octets (NOT characters) on the length of a URI. IPP Printers ought to be cautious about depending on URI lengths above 255 bytes for older client compatibility.
The 'ipp' URL scheme MUST only be used to specify absolute URLs; relative IPP URLs are not allowed. It MUST only be used to specify the use of the abstract IPP protocol over an HTTP transport as defined in RFC 2910.
When comparing two IPP URLs, an IPP Client MUST use the same rules as those defined for HTTP URI comparisons in RFC 2616, with the exception that a port that is empty or not given MUST be treated as equivalent to port 631.
The IPP URL scheme syntax in ABNF is: ipp-URL = 'ipp:' '//' host [ ':' port ] [ abs_path [ '?' query ]]. If the port is empty or not given, port 631 is assumed. If 'abs_path' is not present, it MUST be given as '/' when used as a Request-URI.
This document registers the 'ipp' URL scheme with IANA. The scheme is intended for COMMON usage to specify the network location of IPP print services and associated resources (e.g., print jobs) over HTTP transport on port 631.
An IPP URL does not have parameters to specify the required client authentication mechanism or required security mechanism (e.g., 'tls'). Service discovery or directory protocols might be used to discover these mechanisms associated with given IPP URLs.
An IPP URL might be faked to point to a rogue IPP print service, collecting confidential document contents from IPP clients. Server authentication mechanisms and security mechanisms in RFC 2910 are sufficient to address this threat.
An IPP URL might be used to access an IPP print service at a print protocol application layer gateway (e.g., an IPP to LPD gateway per RFC 2569), causing silent compromise of IPP security mechanisms. There is no practical client-side defense; system administrators should avoid such configurations.