attachment-0001
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>RFC 3986/STD 66 (Uniform Resource Identifier (URI): Generic Syntax) did not define a syntax for specifying IPv6 link-local addresses with zone identifiers (interface names/numbers). Back in 2005, I requested clarification and received the following advice: use the IPvFuture syntax and "+" as a separator between the IPv6 address and Zone ID, for example an IPP URI at address FE80::1234 on interface "en0" would be encoded as follows:</div><div><br></div><div> <a href="ipp://[v1.fe80::1234+en0]/ipp/print">ipp://[v1.fe80::1234+en0]/ipp/print</a></div><div><br></div><div>For IPP Everywhere we require that Clients use this form in the Host: header when submitting a request to a Printer so that the Printer can provide the Client with link-local addresses containing the Client's Zone ID information. This allows referenced URIs in IPP responses to work from the Client, and similarly for URLs in HTML returned by the Printer's Embedded Web Server (EWS).</div><div><br></div><div>Fast forward (!) 8 years and now the IETF has finally published an official extension to RFC 3986 titled Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (RFC 6874). Unfortunately, the extension introduces an incompatible new address format (<span style="font-size: 1em; ">IPv6addrz); for the previous example the URI would be encoded as:</span></div><div><br></div><div><div><span style="font-size: 1em; "> <a href="ipp://[fe80::1234%25en0]/ipp/print">ipp://[fe80::1234%25en0]/ipp/print</a></span></div></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">However, applications conforming to RFC 3986 will reject this address information since percent-encoding and Zone ID information is not allowed for an IPv6address literal. In particular, all versions of CUPS since 2005 will reject IPv6 link local addresses using this format.</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">In addition, RFC 6874 introduces</span><span style="font-size: 1em; "> some unfortunate conformance requirements: Clients MUST NOT include their Zone ID in URIs or the HTTP Host header for the reason that the Server has no use for the information (!).</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">I have had some fruitful initial discussions with the IETF Area Directors and the 6man (IPv6) working group chairs about updating this document and will be preparing a replacement for RFC 6874 with review from the PWG IPP WG to ensure that our needs are met. My planned changes are as follows:</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">1. Add the IPvFuture encoding ([v1.address+zoneid]) as an alternate, backwards-compatible encoding. The new percent-encoded format will still be preferred. Provide implementation guidance with an eye towards backwards-compatibilty.</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">2. Add use cases and discussion concerning why/when IPv6 link-local addresses are used, and how clients and servers can use the zone ID to provide/generate accessible URIs</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">3. Modify the current conformance terms to align with our usage in IPP (Host header) and require servers to validate and use the Host value as supplied</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">In the meantime, please make sure to *NOT* strictly follow RFC 6874 as it will break your printers when used with IPv6 link-local addresses. My recommendation would be to support consumption/use of RFC 6874 URIs but continue to include and accept the Zone ID in the Host header. For printers this means returning URIs using the same format as supplied, i.e. if a Client supplies an RFC 6874 address, return an RFC 6874 URI, otherwise return an RFC 3986 URI.</span></div><div><span style="font-size: 1em; "><br></span></div><div><span style="font-size: 1em; ">References:</span></div><div><span style="font-size: 1em; "><br></span></div><div> RFC 3986/STD 66: Uniform Resource Identifier (URI): Generic Syntax</div><div><br></div><div> <a href="http://tools.ietf.org/html/rfc6874">http://tools.ietf.org/html/rfc6874</a></div><div><br></div><div> RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers</div><div><br></div><div> <a href="http://tools.ietf.org/html/rfc6874">http://tools.ietf.org/html/rfc6874</a></div><div><br></div><div>_________________________________________________________</div><div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>