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

[James Gould <jgould@verisign.com>]

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

Bernie,

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

The other indirect item is the goal of “XML schema is backward compatible”, which is included in multiple messages on the list.  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.  

There were also four versions of the draft created and sent out to the list that did not change the URI (version number), with no negative feedback. 

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

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.  

-- 


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: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
Date: Mon, 25 Jan 2010 13:58:42 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

Thanks for this information.

Could you please send me the pointers to the archive where this has been
discussed? I was unable to locate the relevant posts concerning this
discussion.

I still believe this is a bad idea from implementors point of view. The
EPP client needs the means to discover the capabilities of the EPP Server
which in EPP is done with the hello command and xml schema (incl. version
number) in the response.

What are the disadvantages if the XML schema version number was changed to
urn:ietf:params:xml:ns:secDNS-1.1 ?

cheers,
  Bernie


On Mon, 25 Jan 2010, James Gould wrote:

> Bernie,
>
> We have considered this in prior discussions on the list.  The consensus was to keep backward
> compatibility by keeping the version number the same.  The updated draft is additive to the original
> RFC, so according to the AD this was an acceptable approach.  
>
> --
>
>
> 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: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
> Date: Mon, 25 Jan 2010 11:09:12 -0500
> To: EPP Provreg <ietf-provreg@cafax.se>
> Subject: [ietf-provreg] XML Schema versioning in 4310bis
>
> Hi
>
> As already pointed out to the authors of draft-gould-rfc4310bis, I see an
> issue with the version numbering of the XML Schema. Although rfc4310bis
> changes the XML schema defined in RFC 4310, it intends to reuse the
> version number.
>
> >From implementor point of view this is a very bad idea. It leads to
> confusion and inconsistencies, in particular in the transition phasis. How
> should an EPP Client figure out the capabilities of the EPP Server? The
> repsonse to hello won't be useful to distiguish which schema applies.
>
> I run into a similar problem while implementing RFC 5076. As there was a
> change in the schema during the standardization process, I even needed to
> distinguish between early I-D implementions and the final version of the
> XML schema. I solved it by incrementing the sub-version of the XML schema.
> See: http://tools.ietf.org/html/rfc5076#section-7
>
> Therefore I strongly recommend to increment the (sub-)version number of
> the XML Schema for 4310bis to 1.1
>
> During transition period, the server can announce both versions and the
> client knows what it is up to.
>
> cheers,
>   Bernie
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to ietf-provreg-request@cafax.se
>
>
>
>