Thanks Mike,
I'll have to spend some time processing the "v1." prefix link you sent, so maybe will comprehend that later.
However, for the 2nd issue:
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.
Is it not true, that interfaces en0 and wlan0 will have different link local addresses (based on different MAC addresses)? In that case, if the printer is queried from interface en0, then the URI's it returns should be based on the en0 link local address from the request. So the URI's in the responses should be different and a scope should not be needed (by the printer at least). I guess the issue may be that the same hostname is used for both interfaces?
Of course, I guess there is no requirement for separate interfaces to use separate hostnames, but even so, a printer is going to respond to the address the request comes from, why should the printer care if a request came from en0 (fe80::1234) or wlan0 (fe80::5678)? It should just send request responses to the IPv6 address the request came from, and it should be up to the client to decide on what interface to send the request... If the client needs to make a series of requests (ie - Create-Job/Send-Document), the onus should be on the client to use the same interface. Even the HTTP request/response, while stateless, still uses a TCP connection to ensure sender and receiver are the same...
Of course, I'm by no means an expert on IPv6 addressing and interfaces, not sure how or if two interfaces could share the same IPv6 address.
Chris
Christopher Rizzo
Engineer II, Software Engineering
Design & Development Engineering
[signature_1210663338]<http://www.xerox.com/>
Xerox Corporation
Virtual Office Employee
26600 SW Parkway Ave
Wilsonville, OR 97070
[signature_3702933122]<https://www.linkedin.com/company/xerox/> [signature_888572592] <https://www.youtube.com/user/XeroxCorp> [signature_2365106133] <https://twitter.com/Xerox> [signature_238776473] <https://www.instagram.com/xerox/> [signature_954636144] <https://www.facebook.com/XeroxCorp>
From: Michael Sweet <msweet at msweet.org>
Date: Tuesday, November 4, 2025 at 4:17 PM
To: PWG Workgroup <ipp at pwg.org>
Cc: Christopher Rizzo <christopher.rizzo at xerox.com>
Subject: Re: [IPP] Support for IPv6 addresses with Scope ID's and what ?was? IPvFuture addresses?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Chris,
On Nov 4, 2025, at 3:00 PM, Christopher Rizzo via ipp <ipp at pwg.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9065 bytes
Desc: image001.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1409 bytes
Desc: image002.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1427 bytes
Desc: image003.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1528 bytes
Desc: image004.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1648 bytes
Desc: image005.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 1456 bytes
Desc: image006.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20251105/2c6e1136/attachment-0005.png>
