attachment-0001
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Ok, so you're surfacing an issue that is pretty common in a client-server scenario: a "service" should always advertise a contact point that is resolvable(name) and reachable(address) by any and all potential clients of the service. Which, to your point, is an important concept.<div><br></div><div>Given the ubiquity of this requirement in client/server scenarios, there's probably language that we can borrow that describes this requirement. OR we could keep it abstract, similar to the way I have described it above.</div><div><br></div><div>By the way, in your earlier #2 proposal, there was text that said "...SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols."</div><div><br></div><div>I don't think is correct -- we want to be able to use IPv6 literal addresses that are global in scope, or it would seem like we would want to -- and global-scope IPv6 addresses can be autoconfigured via DHCP or SLAAC.</div><div><br></div><div>Comments?</div><div><br></div><div>R.</div><div><br><div><br><div><div>On May 10, 2012, at 9:58 PM, Mike Sweet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>Randy,</div><div><br></div><div>The main issue is link local, but when you start getting a mix of traditional and multicast host names being used (common for today's network printers) with a new reliance on the information supplied by the printer, it is really important that the client be able to use it... If the printer reports a .local name the the resource won't be accessible from outside the subnet. Similarly, if you get <a href="http://foo.example.com/">foo.example.com</a> a client might not be able to resolve that if it doesn't have a proper dns server configured...</div><div><br></div><div><br>Sent from my iPad</div><div><br>On May 10, 2012, at 8:48 PM, Randy Turner <<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div><br></div><div><br></div>Hi Mike,<div><br></div><div>Can you just simplify 1-3 below by saying implementations MUST NOT use literal link-local addresses in URI values?</div><div><br></div><div>Everything else is ok, right?</div><div><br></div><div>Randy</div><div><br></div><div><br><div><div>On May 10, 2012, at 10:59 AM, Michael Sweet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>Another issue that has come to light recently is the use of link-local addresses by printers that haven't gotten an IP address from a DHCP server.</div><div><br></div><div>To summarize the issue: RFC 3986 does not address how to represent link-local addresses in URIs. Two separate (and incompatible) methods have been proposed for IPv6 addresses:</div><div><br></div><div> <a href="http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt">http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt</a> (expired)</div><div> <a href="http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01">http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01</a></div><div><br></div><div>However, even if one of these methods is eventually adopted it is still impossible for a Printer to advertise the correct URI with a link-local address because zoneid strings are system-specific - they are basically the name of the network interface on the client.</div><div><br></div><div>What I'd like to do in IPP Everywhere is:</div><div><br></div><div>1. Add rationale of not using link-local numeric addresses in printer-uri-supported and other URI values: Link-local numeric addresses cannot be represented by the Printer because the zone identifier is specific to the Client and not the Printer.</div><div><br></div><div>2. Add normative requirement: Printers MUST NOT transfer/provide URI values using link-local addresses, SHOULD transfer/provide URIs values using the Host supplied in the Client HTTP request, SHOULD transfer/provide URI values using fully qualified domain names (FQDNs) in preference to numeric addresses, and SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols. Printers MAY advertise multiple printer-uri-supported values to cover all of the configured FQDNs and non-link-local numeric addresses.</div><div><br></div><div>3. Add implementation discussion where the printer can tailor the addresses reported to the Host: value supplied in the client HTTP request; printer-icons, printer-supply-info-uri, printer-more-info are not as flexible as printer-uri-supported, so using the value supplied in the Host HTTP request header is important.</div><div><br></div><div>4. Add security considerations text talking about DNS rebinding attacks - Printers SHOULD NOT allow requests with unknown or invalid Host values, including "localhost".</div><div><br></div><div>5. Add security considerations text referencing security consideration in current mDNS draft.</div><div><br></div><div>Thoughts?</div><div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div>__________________________________________________</div><div style="font-family: Helvetica; ">Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></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.
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a><br></blockquote></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.
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>ipp mailing list</span><br><span><a href="mailto:ipp@pwg.org">ipp@pwg.org</a></span><br><span><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a></span><br></div></blockquote></div></blockquote></div><br></div></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>