I do not have much to offer other than the OGC Members spent considerable
discussion time defining a standard OGC approach for version negotiation
for use in all OGC web service standards.
And there are still some sticky wickets.
If anyone is interested, I can provide what OGC wording on this topic. May
be helpful.
Carl
> At 08:51 PM 6/28/2009, geopriv issue tracker wrote:
>>#10: Server Version Support
>>---------------------------------------+------------------------------------
>> Reporter: martin.thomson@andrew.com | Owner:
>>
>> Type: enhancement | Status: new
>>
>> Priority: major | Milestone:
>> draft-ietf-geopriv-3825bis
>>Component: rfc3825bis | Version:
>>
>> Severity: - | Resolution:
>>
>> Keywords: |
>>---------------------------------------+------------------------------------
>>
>>Comment(by bernard_aboba@hotmail.com):
>>
>> Client Version Support
>>
>> Clients implementing this specification MUST support receiving
>> responses
>> of versions 0 and 1. Since this specification utilizes the same DHCP
>> option code as [RFC3825], the option format does not provide a means
>> for
>> the client to indicate the highest version that it supports to the
>> server.
>>
>> Server Version Support
>>
>> Servers implementing this specification MUST support sending v0 and v1
>> responses. The version of the response depends on server
>> configuration.
>> For example, where few v0 clients are expected, the server could be
>> configured to send only v1 responses. Where few v1 clients are
>> expected,
>> the server could be configured to send only v0 responses. Where a
>> mixture
>> of v0 and v1 clients are expected, the server could be configured to
>> send
>> either a v0 or v1 response (possibly making the choice based on
>> information such as the client MAC address). It is NOT RECOMMENDED for
>> a
>> server to send a response containing both a v0 and a v1 option.
>
> everything was fine until this last sentence. If an OFFER (which is a
> DHCP response) contains two Option values where both Options are
> identified as the same Option _number_, the second Option overwrites
> the first Option value. Therefore a server cannot respond to a
> client by providing both versions, as the first will become
> immediately useless and forgotten.
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
