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

[Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>]

Hi James

On Mon, 25 Jan 2010, James Gould wrote:

> I had multiple private messages associated with this, but on the list 
> the only message that directly references is from me on December 8th:
> 
> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

Thanks for the pointer.

Sorry, but in this case you can not declare it "consensus", as there was 
not even a sufficient public disussion to reach a consensus.

> The other indirect item is the goal of “XML schema is backward 
> compatible”, which is included in multiple messages on the list.  

Well, I'd say many people are just not aware of this work going on. e.g. I 
only spotted it accidently today, which leads to the other discussion 
about making EPP work in the IETF official...

> Changing the URI (version number) would break this goal, since clients 
> would be required to upgrade their clients to use the new URI, assuming 
> that a server only supports the new draft.  The servers could support 
> two URI’s, which is technically feasible but not simple.  

I don't think the burden should be on the clients. Servers will have to 
implement both versions during a transition period, and Clients will 
gradually upgrade to the new version.

> > What are the disadvantages if the XML schema version number was changed to
> > urn:ietf:params:xml:ns:secDNS-1.1 ?
>
>  1. Clients that support 1.0 would be required to upgrade to 1.1 for servers that support 1.1.  Backward
>     compatibility does not provide a huge benefit if the URI changes.  Client EPP SDK’s need to be
>     upgraded to support this, where if backward compatibility is maintained the clients don’t need to do
>     anything.

If servers are implementing both versions, clients do not need to 
implement both versions during a transition period. If you keep the schema 
backward compatible (as you intend to), there is little complexity added 
to the server.

>  2. Servers might have to support more then one version at a time to migrate users to the new draft.  I
>     don’t know of any servers supporting multiple versions of anything now, so adding this requirement
>     for a backward compatible scheme seems kind of overkill.

Well, I implemented such a scenario with two XML schema versions on a
productive EPP server with extension RFC 5076, which had a change in the 
XML schema during the standardization process. It worked just fine.

> I don’t see a huge advantage of changing the URI, other then clarity in 
> the EPP greeting.  Clients can start exercising the new features of the 
> new draft when the servers supports it as an option instead of as a 
> requirement.  

I don't think that it is a good idea to make a standard that expects such 
a behavior. Servers and clients might run into (unexpected) error cases, 
which are difficult to catch due to ambiguity in the standards, which is 
to be avoided

Another thought: Have you considered to make a complete new XML Schema for 
the new functionality, leaving the existing XML Schema untouched?
[Note: I have not studied in detail whether or not such an approach is 
at all feasible.]

cheers,
  Bernie