> > Bernard -- I think the key word you used above is
> > "configuration". Do we have a requirement that v0 and v1 can be
> > configurable, and where is this configuration to occur?
> >
> > I think the only place we cannot assume configuration is at the 3825
> > unupgraded client.
>
>Yes, because it is what it is (although the same could also be said of
>a 3825 server).
>
>Question: Is there a notion of configuration on an RFC 3825bis client?
I think there needs to be in case the server is v0. We don't want it
to puke on location (i.e., not accept Option 123) when the location
is readable, just without uncertainty - which is better than no location.
>Although it might have preferences, it is not clear what it can do to
>express them.
I don't believe it can express any.
>Saying a client supports RFC 3825bis would imply to me
>that it can deal with a v1 response.
that's a given I believe
>Wouldn't "backward compatibility" also imply
>the ability of an RFC 3825bis client to handle a v0 response as well?
that's what we're discussing, and I believe we ultimately have to say
yes to this question, at least to the point of accepting the location
values and datum, but possibly ignoring the resolution fields.
> I'm trying
>to understand what the axes of "configuration" are for a client.
An operator may know they only have a v0 server, so they configure
all their clients to be v0 clients. That's a configuration.
>
> > Therefore, the server within a domain has to be
> > able to configure what the domain administrator wants to provide
> by the server.
>
>Sure. Depending on what the population of clients is expected to
>be, the server
>configuration might be different.
The server could understand that certain circuitIDs are from v0
clients, and the rest are from v1 clients - and tune its OFFER to the
right asker. This is probably more applicable on a per geographic
boundary pov, like all those in city X, or building Y get v0, all
other clients get v1 OFFERs
> > I believe this is as far as the 3825bis doc can go, and not mandate
> > v1 or v0 support any more than this. This doc can RECOMMEND all day
> > long, but I don't believe the bis doc can mandate anything on the
> > v0/v1 issue. I could be wrong, but I believe v1 server/v0 client is
> > what we have to allow for if we can.
>
>There are two distinct issues. One is support (e.g. what an RFC
>3825bis server
>is capable of sending). The other is what is used (e.g. what it is
>configured to send). If a server is only capable of sending a v0 response,
>wouldn't that make it an RFC 3825 server?
if it is only capable of 3825 OFFERs, then yes
>But just because an RFC 3825bis
>server is capable of sending a v1 response doesn't mean that it is configured
>to do so; that is an administrative choice.
this is one of the reasons why I don't believe we can MUST NOT send
v0 responses, as wiki AI 10 says.
>
>Given the potential downside of sending a v1 response to a v0 client
>(even if it doesn't crash, it doesn't get location), where v0 clients are
>expected, the ability to configure the RFC 3825bis server to send v0
>responses seems like an important aspect of "backward compatibility".
I think this defines backwards compatibility, doesn't it?
James
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
