I couldn't find anything specific - rather the whole document supports this conclusion. There is no mention of overriding or replacing anywhere that I can find.
It would be possible to define an option 123 semantic that allowed for the behaviour you describe, but that would need to be specific to the option definition (i.e. option 123 can be a multiple of 16 octets, containing different versions of the encoding in sequence; the last encoding that the client understands should be used).
--Martin
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, 30 June 2009 11:37 AM
> To: Thomson, Martin; 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 07:06 PM 6/29/2009, Thomson, Martin wrote:
> >As James points out, MUST NOT is probably just "cannot".
>
> I initially thought as Martin did, that "cannot" is the word. But
> nothing prevents an OFFER from containing two Option 123s. DHCP (RFC
> 2131 - which is further clarified in RFC 3396 defining how Options
> can be concatenated into one longer single Option value - because
> DHCP has length limits on Options) states that if a client receives
> an Option, the next reception of that same Option overwrites the
> value of the Option in the client.
>
> For example, if the client receives Option 123 with value FOO first,
> then receives another Option 123 with value BAR, all the client knows
> about is Option 123 value BAR. These consecutive Option 123s can be
> from within the same DHCP OFFER, or in subsequent packets, or spaced
> a hour apart. The last value overwrites the previous value.
>
> This is different from the same DHCP OFFER containing Options 99 and
> 123. In this case, because they are two different Options, both are
> retained until another 99 or 123 is received and overwrites the
> previous value.
>
> Therefore, I think the answer is "can" but is pointless. I initially
> think this is how it should be stated also, that this doesn't
> accomplish anything (i.e., it is pointless to do).
>
> James
>
>
> >RFC 3315 (v6) forbids it, RFC 2131 and RFC 3396 allow for
> >concatenation, which wouldn't make sense.
> >
> > > -----Original Message-----
> > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > > Behalf Of James M. Polk
> > > Sent: Tuesday, 30 June 2009 9:58 AM
> > > To: 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 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
> >
> >----------------------------------------------------------------------
> --------------------------
> >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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
