Chris,
> On Nov 4, 2025, at 3:00 PM, Christopher Rizzo via ipp <ipp at pwg.org> wrote:
>> Not sure if this is out of the scope of IPP PWG, but Apple AirPrint has requirements for support of IPv6 addressing that does not appear to be in any standards.
The history of scoped IPv6 addresses in URIs (particularly for link-local addresses) is both political and religious...
The original IPvFuture work by Bill Fenner and Martin Durst in the old IETF URI WG can be found here:
https://datatracker.ietf.org/doc/draft-fenner-literal-zone/
CUPS adopted this format to support IPv6 link-local addresses back in 2005, and that eventually was adopted for use in AirPrint because there was nothing else coming from the IETF. Later, 3 years *after* AirPrint had adopted the original IPvFuture work, the IETF 6man WG published RFC 6874 (somehow escaping the notice of the Apple folks that were involved in that WG) which uses a completely different method of encoding the scope/zone identifier and which breaks the RFC 3986/STD 66 URI format and outlaws the use of the scope by the receiving server (not understanding that a service might need to provide absolute URIs back to a client).
Fast forward another 10 years and various people (including me) were able to convince 6man to reopen the issue, which led to a *third* scheme/format being proposed. But during wider review the web browser developers told 6man that they would never support IPv6 link local addresses, no matter what format is used. Ultimately the new format was dropped and a 4th draft was put together that obsoletes RFC 6874 and says "web browsers and other software should ask the user which interface to use" and completely ignores the issue for HTTP-based protocols like IPP. 🙄
A subsequent draft (which has not been adopted, again because browser vendors said no) tried to standardize on using mDNS hostnames based on unique addresses (e.g. vendor prefix + MAC address), since that is effectively what everyone does. But somehow a globally-unique identifier being used over mDNS isn't satisfactory for the web folks, and somehow regular DNS, perhaps managed by some vendor's cloud solution, is "better"...
> Also, there is the issue of Scope (or Zone?) ID's: the addition of "%X" on the end of an IPv6 address where X is a reference to the local client interface. According to what I read, the scope id is only relevant for the local machine and helps identify which interface the client request goes out on, and it should be removed by the client before communicating on the network, so why would there be a requirement that a printer IPP or HTTP daemon/server comprehend IPv6 addresses with a scope id appended?
That was the wording from RFC 6874 that was not present in the original URI WG draft and was removed from the subsequent draft that would have replaced RFC 6874.
The reason for having the scope in the URI is to allow a Client to access Printer resources. For example, if a Printer is accessible at link-local address fe80::1234 and the Client has two network interfaces (en0 and wlan0), a Printer URI of "ipp://[fe80::1234]/ipp/print" is insufficient to communicate with the Printer from the Client. Similarly, the "printer-more-info" and "printer-supply-info-uri" attributes are commonly used to access the Printer's embedded web interface and entering "http://[fe80::1234]/supplies" (for example) won't work because the web browser can't determine which interface will work. And the "printer-icons" and "printer-strings-uri" attributes (pointing to printer icon and strings file resources on the Printer) won't have the necessary network interface association that would allow a Client to access those resources.
However, if the Client is able to include the scope in the URI, then the Printer can use that information (from the Host: header) to generate these URIs so that the Client knows which interface to use.
FWIW, a similar approach is used for IPP-USB - there the hostname is always "localhost" with the port number being used by the Client to "route" the communications to the correct USB endpoints. Local (Client) software provides a proxy/gateway that converts network requests to/responses from the USB Printer.
________________________
Michael Sweet