Randy,
On May 10, 2012, at 10:22 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>> 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.
However, it is very common for printers to be reachable by multiple names and addresses. For example, "foo.example.com" 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 "foo.example.com" from the internal network you'll typically get a "no route to host" error when you connect.
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.
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!
> ...
> 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."
>> 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.
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.
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120511/218ff29e/attachment-0001.html>