Can I request that text to this effect be put into the document under a "Server Version Support" (or similar) header. No more need be said on the matter. We tend to overcomplicate things unnecessarily.
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Saturday, 27 June 2009 11:08 AM
To: gabor.bajko@nokia.com; br@brianrosen.net; mlinsner@cisco.com
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Issue: version "negotiation"
> In this case, you have a (small) installed base of V0. Any
> new device or server has to implement both V0 and V1 if
> there is a possibility of encountering a V0-only end. It's
> certainly possible to implement V1 only if you allow the
> possibility of failure. For an emergency system, that would
> not be an option, but for other use, it might be okay.
The situation is somewhat different on the client and server so we need to think this through in somewhat more detail.
My understanding is that it is not possible for an RFC 3825bis client to explicitly indicate which version it supports to the server. An RFC 3825bis client will include the same option 55 regardless of the geo-location option version it supports, and for 11k/11y there is no way for a client to signal the highest supported version in the location request. In some cases, v0 and v1 clients may be differentiated by OUI or MAC Address, but this cannot be assumed. As a result, an RFC 3825bis client cold receive either a v0 or a v1 response, and should be prepared to handle either version. It is our (so far unverified) assumption that existing RFC 3825 clients will silently discard a v1 response, but will not suffer other ill-effects (e.g. they won't crash and will still be able to obtain an IP address and utilize other configuration parameters).
On the server side, the lack of an explicit version indication in the request implies that an RFC 3825bis server cannot be assumed to know what version a client supports. However, the server's configuration can be based on prior knowledge of the expected population of v0 and v1 clients.
Where few if any v0 clients are expected, the server can send v1 responses to all requesters. Where out-of-band differentiation is possible, an RFC 3825bis server could send v0 or v1 responses based on out-of-band configuration. Where out-of-band configuration is not possible and v0 clients need to be supported, the server can send v0 responses to all requests.
------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] |
