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
