>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
>--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
