Re: [ietf-provreg] XML Schema versioning in 4310bis

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] XML Schema versioning in 4310bis

All,

The way I view this is considering what is done from an Object Oriented perspective.  If I have a defined interface that is being used, to add features but with maintaining backward compatibility I would create an extended interface without touching the existing interface.  I’m assuming that some sort of factory is being used here to return the appropriate object, where clients of the old interface would continue using the old interface and clients of the new interface would type cast to use the new interface.  As far as 4310bis goes, changing the URI is like changing the package of the existing interface which will not allow the client to use the existing interface.  I do see the issue of a client that wants to use the new interface not being aware that it’s supported.  In programming languages, the client would use reflection to determine if the new interface is supported.  

I have always been an advocate for backward compatibility, where a change to the URI will break compatibility.  How about looking for a compromise on this?  What if we reused urn:ietf:params:xml:ns:secDNS-1.0 for the protocol messages but add the requirement that the server publish the new URI  urn:ietf:params:xml:ns:secDNS-1.1 in addition to urn:ietf:params:xml:ns:secDNS-1.0 in the greeting if 4310bis is supported?  We could register the new URI namespace (not the schema) and use it strictly for publishing the support for the later draft.  Clients are not forced to deal with different versions across the servers, servers can support a single version (either old or backward compatible new), and servers explicitly publish support for the new specification in the greeting.  

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: Andrew Sullivan <ajs@shinkuro.com>
Date: Tue, 26 Jan 2010 09:15:08 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On Tue, Jan 26, 2010 at 09:01:47AM +0100, Ulrich Wisser wrote:
> 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.

That argument is circular.  What is up for debate is whether there is
in fact a need to do this.

> 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

But in (2) and (3), the client _can't tell_ what support is in the
server.  The whole point of the handshake in the protocol is to make
it possible for people to tell.

> Which registry is going to support 1.0 after 1.1 has been released for
> any time longer then needed?

Who knows?  This is the Internet.  We have parts of the DNS
infrastructure (including several MSFT APIs) that don't support the
DNS Unknown type, even though that was specified over 10 years ago and
is terribly useful.

> 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?

Right.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se