You also cannot rely on a client ignoring a version that it doesn't support and retaining the version that it does. 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. 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.
--Martin
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Friday, 3 July 2009 1:27 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 06:35 PM 7/2/2009, Thomson, Martin wrote:
> >Sure, on the technical point.
> >
> >I contend that including text in the document (as proposed) might
> >instead by confusing.
> >
> >Certain major DHCP implementations don't ever make a second request
> >and so would not be able to benefit from the suggestion.
>
> err, then we might not be agreeing to the same thing, since this
> second request will *always* occur when the client refreshes its
> lease (or sooner).
>
> >I suspect also that if the second response is the unsupported
> >version, the first option, supported or not, is likely to be
> destroyed.
>
> this is a problem that I hope the new text attempts to prevent - by
> saying sending two versions of the same Option code (123 in this
> case) doesn't achieve what one may want (that both are stored), and
> instead means the second piece of data overwrites the first. If the
> second is not supported, and destroys what was stored, this indeed
> would be a very bad thing.
>
>
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Thursday, 2 July 2009 3:41 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)
> > >
> > > I call this one as we are in violent agreement...
> > >
> > > agreed?
> > >
> > > At 06:17 PM 7/1/2009, Thomson, Martin wrote:
> > > >Except for the fact that this is only possible in _different_ DHCP
> > > >responses. If it were in the same response, concatenation would
> be
> > > >applied and client behaviour would be undefined (and
> unpredictable).
> > > >
> > > > > -----Original Message-----
> > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]
> > > > > Sent: Thursday, 2 July 2009 12:34 AM
> > > > > To: Thomson, Martin; bernard_aboba@hotmail.com; James M. Polk
> > > > > Cc: geopriv@ietf.org
> > > > > Subject: Re: [Geopriv] [geopriv] #10: Server Version Support
> (was:
> > > > > Should not encourage use of "old" encoding)
> > > > >
> > > > > > Do we want to have text saying something about the current
> > > behavior
> > > > > of
> > > > > >
> > > > > > "As a matter of practice within DHCP - a server
> sending
> > > one
> > > > > > version
> > > > > > of Option 123 towards 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)."
> > > > > >
> > > > > > This is useful guidance.
> > > > > >
> > > > > > James
> > > > >
> > > > > I agree with providing guidance like this in an obviously non-
> > > normative
> > > > > way - it's not something everyone knows.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Spencer
> > > > >
> > > > >
> > > >
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >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
> > >
> >
> >----------------------------------------------------------------------
> --------------------------
> >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]
>
------------------------------------------------------------------------------------------------
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
