>Excellent :)
>
>Since we agree on this, can we agree that this text isn't helpful:
>
>"
>As a matter of practice within DHCP, a server sending one version of
>Option 123 to a client followed by the other version (in the same
>response or a separate response) does not allow clients to retain
>both versions in memory. Receiving two copies of the same Option
>causes the client to replace the old information with the new
>information of the same Option (123 in this case). Therefore it is
>not useful for a server to send both v0 and v1 options to the client.
>"
>
>The first sentence implies (to me) that it's possible to send both versions,
I think the first sentence says "it's stupid to do this, so don't try".
I think this is still useful.
>which is a little misleading. I'm pretty sure that the second is
>only true if the copies are in different messages.
>
>And instead use the text that I proposed.
>
><http://www.ietf.org/mail-archive/web/geopriv/current/msg07431.html>
>
>Maybe changing the first sentence to:
>
>A server that provides location information cannot provide both v0
>and v1 formats.
>
>--Martin
>
> > -----Original Message-----
> > From: James M. Polk [mailto:jmpolk@cisco.com]
> > Sent: Friday, 3 July 2009 3:18 PM
> > To: Thomson, Martin; Spencer Dawkins; bernard_aboba@hotmail.com
> > Cc: geopriv@ietf.org
> > Subject: RE: [Geopriv] [geopriv] #10: Server Version Support (was:
> > Should not encourage use of "old" encoding)
> >
> > At 10:38 PM 7/2/2009, Thomson, Martin wrote:
> > >You can't rely on the server being able to send a second option.
> >
> > correct, but I didn't think I implied that.
> >
> > >If it's at the end of a lease, that could be hours away; far too
> > >long a time to be useful.
> > >
> > >You also cannot rely on a client ignoring a version that it doesn't
> > >support and retaining the version that it does.
> >
> > I think the behavior is pretty much set, get the first - use the
> > first, until a second is received; then purge the first and replace
> > it with the second, then use the second; and so on...
> >
> > >It will keep the most recent, and if that's not supported, then it
> > >will have to assume that it can't use any location information.
> >
> > agreed, and this should be avoided
> >
> > >After all, it doesn't necessarily know that it hasn't moved.
> > >
> > >It's ultimately pointless attempting to use multiple messages to
> > >deal with this problem.
> >
> > I agree
> >
>------------------------------------------------------------------------------------------------
>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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
