Ray,
On 2013-05-29, at 2:52 AM, Ray Hunter <v6...@globis.net> wrote:
> ...
> Where's the standard that says ZoneID MUST be included in the Host
> header? I presume this is rfc2616#page-128.
RFC 2616 just says to use the host and port from the original URI. It doesn't
say anything about IPv6 link-local addresses and preceded RFC 3986's IPvFuture
format. And section 3.2.2 just says that IP addresses SHOULD be avoided
whenever possible with a reference to RFC 1900.
> And the value of "Host" is always set to the host portion of the
> original URI [which will currently include a ZoneID on current
> implementations]?
Correct.
> Do you think that 6874 mandates that the ZoneID MUST be stripped from
> the "Host" HTTP request header, as Host is sub-string of a URI?
Yes, from section 4 of RFC 6874:
An HTTP client, proxy, or other intermediary MUST remove any ZoneID
attached to an outgoing URI, as it has only local significance at the
sending host.
Since the Host value is extracted from the outgoing URI, my assumption would be
that this prohibition applies to the Host value as well, which should probably
be spelled out in the future (perhaps with examples).
(this is text I plan on updating in my draft...)
>> ...
>> The server knows its own link-local addresses and doesn't need the zoneid
>> information.
> I don't understand this logic. I'm presuming the outbound interface for
> replies is being selected by mirroring the inbound addresses of the
> request [quoting RFC6724: "In many cases, this is trivially dealt with
> by an application using the source address of a received packet as the
> response destination and the destination address of the received packet
> as the response source."]
>
> However I thought one of the use cases was the printer sending
> unsolicited information such as "out of paper".
In the case of IPP, the connection is always initiated by the client, and the
server only responds to requests sent by the client. There is an asynchronous
event notification extension for IPP (RFC 3995 combined with RFC 3996), but
that is effectively a long-duration pull operation (the client sends a
Get-Notifications request to the printer, and the printer will continue sending
events in the same response as needed) and not a push operation back to the
client.
> How would the server then select its correct local outbound interface,
> if it had multiple?
> Does the client supply a "callback address/port" that the printer
> stores/caches?
As indicated above, the printer never contacts the client, it is always the
client contacting the printer.
>> For the use case under discussion, the client only knows its zoneid
>> information because the user/administrator has supplied it along with the
>> printer's link-local address.
> Right. That was going to be my next question.
>
> How does the very first URI learn the correct ZoneID in the first place?
> Manually.
The manually-entered URI case is actually the edge case of an edge case, i.e.,
that 1-in-a-million user that just tries things to see if they will work...
The more typical case is where the client uses a discovery protocol that either
does not support name-based resolution or makes it optional. The specific
protocols I personally have to deal with are WS-Discovery, UPNP, and (coming
soon) Wi-Fi Direct Services. The first two generally use IPv4, but for Wi-Fi
Direct the preference will be IPv6.
Once a client discovers the printer they may only have an IPv6 link local
address for it, and that's what gets put in the URI for the printer.
Conceptually one could do some clever name mapping on the host
("mac-xxxxxxxxxxxx.something.") so that the URIs would not need to contain
link-local addresses at all, but given that I can't expect every OS to adopt
such a strategy I need to be able to target a printer using a URI containing an
IPv6 link-local address, have it return resource URIs that the client can use,
have a functional web interface, etc.
_________________________________________________________
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
--------------------------------------------------------------------
