To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Ulrich Wisser <liste@publisher.de>
Date:
Tue, 26 Jan 2010 09:01:47 +0100
In-Reply-To:
<C7838A86.3702D%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Thunderbird 2.0.0.23 (Macintosh/20090812)
Subject:
Re: [ietf-provreg] XML Schema versioning in 4310bis
Hi, in this case I have to agree with James. We discussed changing the URI and came to the conclusion that changing the URI will break old clients without any need to do so. But let's have a look on the alternatives: 1. Server supports only the "old" 1.0 - no changes on client or server 2. Server supports only the "new" 1.0 - only changes on the server side needed 3. Server supports both - only changes on the server side needed If we change to 1.1: 1. Server supports only 1.0 - client needs to support 1.0 and 1.1 dependingon the registry 2. Server supports only 1.1 - client needs to support 1.0 and 1.1 dependingon the registry 3. Server supports 1.0 and 1.1 - only changes on server side needed Which registry is going to support 1.0 after 1.1 has been released for any time longer then needed? Changing the URI will generate the need to update clients. Another question comes to mind: Why should 1.1 be backwards compatible? If we break the URI there is no need to keep the broken <rem/>, is it? But maybe we could take another approach? We define a new 1.0 backward compatible and a new 1.1 not backward compatible. If the registry will not support the old syntax it could choose to advertise 1.1 if the registry stays backward compatible but gradually wants to move to the new syntax it will advertise the new 1.0. Could that be a solution? /Ulrich -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se