Yes, I understand your consumer dynamic scenario…In the "old" days, admins would configure a service name (like "printer,apple.com") to return multiple IP addresses, and socket API recommendations say you're supposed to walk the list of returned addresses until you successfully connect to one. So there would be a slight delay if you were home and wanted to access imac27.mike.members.icloud.com (unless the home IP address was the first address returned).
It gets even more complicated if your DNS setup is dual-stack in which case you're returning both A and AAAA records, in which case local resolver policy may force a delay if clients try to resolve IPv6 before IPv4 or vice-versa.
R.
On May 11, 2012, at 10:25 AM, Michael Sweet wrote:
>> On May 11, 2012, at 9:43 AM, Randy Turner wrote:
>>>>> Hi Mike,
>>>> Good discussion.
>>>> 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.
>> I agree that N-headed DNS works well for managed, mostly-static infrastructure. However, dynamic consumer services like dyndns and iCloud don't (and can't, as far as I can see) work that way.
>> For example, Apple has something called "Back to My Mac" that allows you to access your computers via iCloud, which handles setting up a secure tunnel between the two computers using your iCloud account. Part of this service is a DNS subdomain for your iCloud account, so I can access "imac27.NNNNNN.btmm.members.icloud.com" to get to my iMac at home. However, if I try to use that hostname when I am at home it won't work because the VPN address doesn't route from my home network.
>> Similarly, I have a DynDNS account setup that allows me to access that same iMac from non-Mac computers. The DynDNS hostname works great outside my home network, but does not work on the home network.
>>> ...
>> 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.
>> I suspect that consumer products will "obey" this limitation, but you can expect enterprise and "prosumer" products will continue to support (re)configuration of the printer to report externally-available resources. I say "continue to" because existing IPP-based printers already support this functionality.
>> ________________________________________________________________________
> 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/78c9c290/attachment-0001.html>