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). &nbsp;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>&nbsp; &nbsp; <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. &nbsp;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&nbsp;Representing IPv6 Zone Identifiers in&nbsp;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; ">&nbsp; &nbsp; <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; ">&nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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>&nbsp; &nbsp; RFC 3986/STD 66:&nbsp;Uniform Resource Identifier (URI): Generic Syntax</div><div><br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://tools.ietf.org/html/rfc6874">http://tools.ietf.org/html/rfc6874</a></div><div><br></div><div>&nbsp; &nbsp; RFC 6874:&nbsp;Representing IPv6 Zone Identifiers in&nbsp;Address Literals and Uniform Resource Identifiers</div><div><br></div><div>&nbsp; &nbsp; &nbsp; &nbsp; <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&nbsp;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>