Re: XML Schema versioning in 4310bis

Bernie,

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

Maybe the word ³consensus² from a WG perspective is not correct, but based
on the work done on this list for the past few months I believe I can fairly
claim that no one on the list had a major concern using the existing URI and
maintaining backward compatibility.  Andrew looks like he now has a
different view and sees this as a ³serious problem², which was not
previously expressed on the list or in private messages.  Scott Hollenbeck
was the one that brought the potential need to change the URI to my
attention, and that¹s when I went to the AD to find out what the options
are.  The AD said that the same URI can be used as long as the schema is
backward compatible. That is when I sent the message out to the list with
the goals along with the results of my communication with the AD.  There is
no way for me to define ³consensus² from a mailing list, but I have done the
best I can with an individual submission.

> 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.
    
The burden is certainly going to be on the clients, who will most likely
have to use different implementations across different servers.  The servers
don¹t have to implement both versions and most likely will not.  We will
most likely look to implement one version of the extension, which would be
1.1.  Clients can¹t gradually incorporate the new features of the new draft
since the new URI is a syntax change and is therefore not backward
compatible.        

> 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

I don¹t believe that there is much ambiguity in this case.  The new draft is
additive to RFC 4310, so the only confusion is the ability to do more with
the new draft.  A server can support the old model and the new model without
the URI change, since the new draft supports the old syntax.

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

No, the changes are cross cutting and would not work in a separate XML
schema.   

My goal in this effort was to address the main issues with RFC 4310, while
having the least amount of impact to existing implementations, and
maximizing the adoption of DNSSEC by supporting new usability features.
Creating a different URI for the new draft is not a large effort on my part,
but I believe is fundamentally against the goals of the work.


-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
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 <[email protected]>
Date: Mon, 25 Jan 2010 16:05:30 -0500
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

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