[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


Home | Date list | Subject list