attachment-0001
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hi Mike,</div><div><br></div><div>Good discussion.</div><div><br></div><div><div>The VPN-name vs. LAN-name situation is normally cleared up by 2-headed DNS, which most companies employ all the time -- that's not a problem we need to solve. Like all service configurations, administratives have to "do the right thing" when they configure their servers. "<a href="http://printer.foo.com">printer.foo.com</a>" when resolved internally would map to the LAN IP, when "<a href="http://printer.foo.com">printer.foo.com</a>" is resolved externally, it maps to some other IP that is exposed through the firewall.</div><div><br></div><div>I think my earlier statement regarding service "visibility" covers any possible client/server scenario, if we wanted to reuse that language in some fashion.</div><div><br></div><div>I agree with the recommendation about not using literal IP addresses in URIs, especially with IPv6, since that's a bit messy. That's probably a SHOULD NOT USE type of recommendation.</div><div><br></div><div>While it may be possible for a device to advertise multiple URIs for both the principal service, and other URIs (identifying different physical servers) for associated resources, I hope this is the exception and not the rule -- in fact, I would say we need a recommendation that says IPP Everywhere deployments SHOULD NOT use disseparate servers -- it makes the overall aggregate "uptime" for the service questionable, and creates potentially complicated policies for defaults if/when these associates resources are (for some reason) not available.</div><div><br></div><div>R.</div><div><br><div><div>On May 11, 2012, at 8:31 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; ">Randy,<div><br><div><div>On May 10, 2012, at 10:22 PM, Randy Turner <<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>> wrote:</div><blockquote type="cite"><div 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></blockquote><div><br></div>However, it is very common for printers to be reachable by multiple names and addresses. For example, "<a href="http://foo.example.com/">foo.example.com</a>" may resolve to an external address for VPN users while "foo.local" resolves to an internal address for local users. If you attempt to connect to "<a href="http://foo.example.com/">foo.example.com</a>" from the internal network you'll typically get a "no route to host" error when you connect.</div><div><br></div><div>Also, domains are often used as different security domains (think Active Directory...) which have similar routing issues as well as any additional access control that might be involved.</div><div><br></div><div>My recommendation is simply there to address the resource lookups *after* discovery - most discovery protocols will give you a current address, port, and resource path for the IPP print service, but not for the supporting resources (localization file, icons, profiles, etc.) that can be queried. And those resources don't have to be printer resident so a client can't make any assumptions about the values returned by the printer!</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>...</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></blockquote><br></div><div>Yes we want to be able to use them, but both the IPP URI scheme and pending IPPS URI scheme recommend against it (per IETF policy) and DHCP addresses are almost always TEMPORARY. You don't want to make a long-term binding to a numeric address, particularly in a mobile environment.</div><div><br></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; 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>__________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span>
</div>
<br></div></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>