Ole, On 2013-05-24, at 4:33 PM, Ole Troan <otr...@employees.org> wrote: >> ... >> All of this falls apart with link-local addresses and RFC 6874. Because the >> client is required to remove the zoneid from the outgoing request, the URIs >> it gets back from the server are no longer "reachable". > > how is this different from any other application using link-local addresses?
In this case, the server is returning absolute URIs (for printers, typically URIs with http, https, ipp, or ipps schemes on a variety of ports) that the client can later use for accessing the corresponding resources. > ... > client connects to http:://[fe80::1%Ethernet0/0] > the client has to assume that all embedded URIs with link-local addresses > belong to the same zone that it connected to. > after all they cannot belong to any other zone... the server obviously has > to make sure it never gives out these URIs > to a client connecting using non-link-local addresses multiple hops away. OK, so the problem is that absolute URIs are embedded in the content returned by the server. Forcing the client to rewrite all of the URIs in the returned content is a tremendous burden on the client, while the server is generating these absolute URIs on-the-fly to satisfy the client's request and could include the zoneid information essentially "for free" with minor changes to its input validation (to allow addresses with zoneid information). Put another way, would you rather write the client code that "fixes" every embedded URI in an IPP response, HTML document, CSS file, XML file, XSLT file, PDF file, etc., or would you prefer writing the server code that just embeds the client-provided address in the URIs it returns? >> What I propose is that we change the wording to allow the zoneid in the Host >> header but not in the Request-URI. HTTP proxies would be required to strip >> any zoneid information in the Host header. HTTP servers would be required >> to ignore any zoneid information for purposes of address validation but >> include it for any absolute URIs to the server they generate. >> >> Thoughts? > > to reword. you need something for which the client gives the server some > opaque information that it can use to identify interface when it gets the > embedded URIs in the reply back? > again I don't understand why the client doesn't know the interface to use > already. The client software /may/ know the interface in use because it has an absolute URI containing this information. I say may because in many cases this information is abstracted away in some toolkit so all the client software may see is a printer name, e.g., "Acme Laser Printer down the Hall". Moreover, the returned IPP response, HTML document, etc. may be used by code that no longer has access to the original address information - it has lost the original context and thus a link local address without zoneid information is basically inaccessible short of iterating over all the client's interfaces (assuming your OS of choice even allows ordinary users/applications to do that...) For example, CUPS supports PPD keywords that specify the absolute URI of the printer's administration and supply report web pages. This information is collected when the queue is setup, and if the printer is setup using a numeric IPv6 link local address we need to store the client's interface name (zoneid) with the URI so it can be accessed in the future. We made an implementation choice 8 years ago (in cooperation with the printer vendors) to support this configuration by passing the client's zoneid in the request so that the printer could return the same address+zoneid in any URIs, and that has served us well for the (small number of) users that want/need this capability. Each client has its own PPD file using its own zoneid information... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
