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

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 Jan 2010 17:09:12 +0100 (CET)

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 [email-masked]

---

From: James Gould <[email-masked]>
Date: Mon, 25 Jan 2010 12:29:40 -0500

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
[email-masked]
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-masked]>
Date: Mon, 25 Jan 2010 11:09:12 -0500
To: EPP Provreg <[email-masked]>
Subject: [ietf-provreg] XML Schema versioning in 4310bis

Hi

cheers,
  Bernie

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jan 2010 13:14:03 -0500

> was an acceptable approach.

As a matter of procedure, I think it's important to be careful with
that word "consensus".  There's no working group here, and no chair to
declare consensus.  I'm not at all sure there was consensus: that was
my objection, too, but I said that as a party who didn't have to live
with the results I wouldn't press to hard on this issue.  I still
think it's a serious problem: if we're not going to use the version
number to be the indicator of the version of the specification, what's
it for?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 Jan 2010 19:58:42 +0100 (CET)

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
> 
> 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: James Gould <[email-masked]>
Date: Mon, 25 Jan 2010 15:05:46 -0500

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.

> 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 

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

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 Jan 2010 13:58:42 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

cheers,
  Bernie

> We have considered this in prior discussions on the list.  The consensus was
to keep backward
> RFC, so according to the AD this was an acceptable approach.  
Registry  Sensitive
> e-mail and destroy the original message without making a  copy.  Thank you.
________________________________________________________________________________
_________________

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 Jan 2010 22:05:30 +0100 (CET)

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

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.

>  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

---

From: James Gould <[email-masked]>
Date: Mon, 25 Jan 2010 17:51:02 -0500

Bernie,

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

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

> which are difficult to catch due to ambiguity in the standards, which is

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.

> [Note: I have not studied in detail whether or not such an approach is

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 

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

Date: Mon, 25 Jan 2010 16:05:30 -0500

Hi James

Thanks for the pointer.

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

> two URI¹s, which is technically feasible but not simple.  

>  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

>  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

> I don¹t see a huge advantage of changing the URI, other then clarity in

cheers,
  Bernie

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 26 Jan 2010 09:01:47 +0100

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

---

From: [email-masked]
Date: Tue, 26 Jan 2010 11:54:57 +0000

> Ulrich Wisser <[email-masked]> wrote on 26/01/2010 08:01:47:
> Re: [ietf-provreg] XML Schema versioning in 4310bis
>

That's OK for the server, but thinking about it from the client's point of
view:  How does a client know whether it should use the "old" or "new"
format?
Having the server advertise the protocol version in the <hello> makes it
possible to write a client that can handle both.

Anthony Kirby

--
Nominet UK - http://www.nominet.org.uk

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:15:08 -0500

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

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

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

> If we break the URI there is no need to keep the broken <rem/>, is it?

Right.

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 12:01:07 -0500

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 

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

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:15:08 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Right.

A

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 27 Jan 2010 09:53:18 +0100

Hi,

when discussing 4310bis we did focus very much on backward 
compatibility. Which isn't necessarily a bad thing. But by making the 
old style rem command optional we break exactly the one thing we were 
aiming for.

After some discussions with registrars and my colleagues, we came to the 
conclusion that a new URI would be a better solution. The server could 
support both versions of the protocol (and therefor not break old 
clients) and clients would know which interface to use.

If we change the URI, I propose to drop backward compatibility and get 
rid of the old style rem.

/Ulrich

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 27 Jan 2010 15:42:35 +0100

On 25/01/10 21:05, James Gould wrote:
> [...]

Hi all,

I am currently trying to catch up (once again), and just want to point out in 
this context to my mail from Dec 18th, 2009, and James' answer. Unfortunately, I 
can't find James' e-mail on cafax.se, so I am quoting the respective part 
instead of providing a link:

>> section 5/section 7:
>>
>> I discovered that the schema uses the same XML namespace as RFC 4310. I am not
>> familiar with the policies of XML namespaces at the IETF, but I wonder whether
>> there is a need to use a different XML namespace, since we considerably
>> changed
>> the schema (despite the fact that it should be backward compatible).
>
> Not according to the Area Director Alexey Melnikov, who replied with the following on the URI:
>
> I think just keeping namespace URIs would be fine. Your document would
> need to list all changes (including additions) since RFC 4310, so that
> would help in verifying that schema changes are backward compatible.
> If your changes end up not being backward compatible, then new namespace
> URIs can be allocated.
>
> Keeping the schema backward compatible is one of the key goals, where changing the URI itself would not make it backward compatible.

I have to admit that I missed the point regarding the greeting message. While I 
think that EPP cannot live up to the expectations of an "out-of-the-box" 
deployment and automatic negotiations of capabilities, as the policy differences 
between the various registries are simply too large and beyond the scope of EPP, 
I think it is better to change the URI just to enable the client software to 
detect protocol changes and to raise an alarm if need be.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 27 Jan 2010 15:53:18 +0100

Hi,

> old style rem command optional we break exactly the one thing we were

Hmm. I am quite sure that the current version of 4310bis allows the processing 
of all valid 4310 requests.

> clients) and clients would know which interface to use.

Agreed.

> rid of the old style rem.

This is a valid option, but it throws us back nearly to the beginning of the 
discussion. But if it's worth...

Regards,

Klaus

---

From: James Gould <[email-masked]>
Date: Wed, 27 Jan 2010 12:41:14 -0500

Klaus,

Thanks for responding to this topic.  Below is my feedback to the feedback.

> of all valid 4310 requests.

There was much discussion related to supporting the old style secDNS:rem
with secDNS:keyTag on the list.  The following text in the draft directly
addresses the issue according to a compromise from this list:

> <secDNS:keyTag> element MUST contain a key tag value as described in section
> 5.1.1 of RFC 4034 [6]. Removing all DS information can remove the ability of
> the parent to secure the delegation to the child zone. The server SHOULD
> return an EPP error result code of 2305 if more than one DS record matches the
> <secDNS:keyTag>. <secDNS:dsData> should be used by the client if there is more
> than one DS record with the same <secDNS:keyTag>.

I would like to continue with what was compromised in addressing the issue
of using the non-unique secDNS:keyTag.  Is this not an acceptable solution?

>> clients) and clients would know which interface to use.

Ok, it looks like the feedback is to use a different URI.  I can go with
this.  If anyone disagrees, please respond to the list or to me privately.
I can go with urn:ietf:params:xml:ns:secDNS-1.1 as proposed by Bernie.

> discussion. But if it's worth...

I don¹t believe that there is a compelling need to open up pandora¹s box for
this item.  The goal is to address the main issues with RFC 4310, which the
draft I believe does.  I¹ll drop the URI backward compatibility goal (or I
guess sub-goal).  

-- 

JG 

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

From: Klaus Malorny <[email-masked]>
Date: Wed, 27 Jan 2010 09:53:18 -0500
To: Ulrich Wisser <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi,

> old style rem command optional we break exactly the one thing we were

Hmm. I am quite sure that the current version of 4310bis allows the
processing
of all valid 4310 requests.

Agreed.

Regards,

Klaus

---

From: Ulrich Wisser <[email-masked]>
Date: Thu, 28 Jan 2010 11:22:31 +0100

Hi James,

[...]
> with secDNS:keyTag on the list.  The following text in the draft 
> directly addresses the issue according to a compromise from this list:
> 
>     <secDNS:keyTag> element MUST contain a key tag value as described in
>     section 5.1.1 of RFC 4034 *[6]*. Removing all DS information can
>     remove the ability of the parent to secure the delegation to the
>     child zone. The server SHOULD return an EPP error result code of
>     2305 if more than one DS record matches the <secDNS:keyTag>.
>     <secDNS:dsData> should be used by the client if there is more than
>     one DS record with the same <secDNS:keyTag>.
> 
> 
> I would like to continue with what was compromised in addressing the 
> issue of using the non-unique secDNS:keyTag.  Is this not an acceptable 
> solution?  

How could I miss this? If a client (our own registrar currently does) 
send two DS records per key (SHA-1 and SHA-256), these posts could not 
be deleted with they old style <rem/>.

/Ulrich

---

From: James Gould <[email-masked]>
Date: Thu, 28 Jan 2010 09:15:00 -0500

Ulrich,

> be deleted with they old style <rem/>.

That is correct as long as the server does what is recommended (SHOULD) by
the draft.  The client should use the secDNS:dsData with a secDNS:rem to
explicitly specify which DS to remove.  Does this address your concern?

-- 

JG 

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

From: Ulrich Wisser <[email-masked]>
Date: Thu, 28 Jan 2010 05:22:31 -0500
To: James Gould <[email-masked]>
Cc: Klaus Malorny <[email-masked]>, EPP Provreg
<[email-masked]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James,

[...]

/Ulrich