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