[IPP] RFC: Link local addresses in URIs, addition for IPP Everywhere

[IPP] RFC: Link local addresses in URIs, addition for IPP Everywhere

Michael Sweet msweet at apple.com
Fri May 11 17:25:07 UTC 2012


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/703e1e18/attachment-0001.html>


More information about the ipp mailing list