> 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?
Although it might have preferences, it is not clear what it can do to
express them. Saying a client supports RFC 3825bis would imply to me
that it can deal with a v1 response. Wouldn't "backward compatibility" also imply
the ability of an RFC 3825bis client to handle a v0 response as well? I'm trying
to understand what the axes of "configuration" are for a client.
> 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.
> 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? 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.
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".
