Subject: RE: [ietf-provreg] EPP to Draft: Next Steps

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Sep 2005 12:32:16 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Tuesday, September 20, 2005 10:34 AM
> To: [email-masked]
> Subject: Re: [ietf-provreg] EPP to Draft: Next Steps
> 
> Hollenbeck, Scott <[email-masked]> 2005-09-20 16:14
> > > There are minor incompatibilites between the two (among 
> which how to
> > > fill <domain:update> in case of an extension), so it 
> seems worthwile
> > > to me to be able to clearly separates between the two, as some
> > > servers will implement one version, and some will implement the
> > > other.
> > 
> > Given that the schemas have not changed, and the version numbers
> > identify the namespaces and schemas, I don't see the need 
> to increment
> > the version numbers.  Anything that was working a certain way before
> > should continue to work the same way with the proposed text changes.
> 
> I believe not, or there is something I do not understand, so please
> correct me.
> 
> The current RFC, mandates something in domain:update, either add, rem
> or chg.
> (btw the schema does not seem to reflect that if I read it correctly,
> as all three elements are in a sequence with minOccurs=0)
> For an extension, there is thus the need of an empty domain:chg with
> true changes in the extension part.

All having a minOccurs=0 attribute means that all are optional.  This is
part of the error in 3731.  The schema correctly says they don't need to
be there.  The text does.  The text is wrong.

If a client send an empty element and an extension element as described
in the old text, the server should do nothing with the empty element
because the "real" update is described in the extension.  That's still
the case with the new text, except that the new text now accurately
reflects what's in the schema.  It might indeed cause a problem for a
server written to the old text.

> Your third point in 3731bis states:
> 3.  Changed text in Section 3.2.1.4 from "At least one <domain:add>,
>     <domain:rem>, or <domain:chg> element MUST be provided." to "At
>     least one <domain:add>, <domain:rem>, or <domain:chg> element
>     MUST be provided if the command is not being extended.  All of
>     these elements MAY be omitted if an <update> extension is
>     present.".
> 
> This means to me that an empty domain:chg is not needed anymore in
> domain:update if there is an extension in use during the
> domain:update

Correct.  Sending one is a no-op; it's not needed.

> As examples, see RFC3915 :
>    C:    <update>
>    C:      <domain:update
>    C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
>    C:       domain-1.0.xsd">
>    C:        <domain:name>example.com</domain:name>
>    C:        <domain:chg/>
>    C:      </domain:update>
>    C:    </update>
>    C:    <extension>
> [..]
> 
> and compare it to draft-hollenbeck-epp-secdns-08.txt :
>    C:    <update>
>    C:      <domain:update
>    C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
>    C:       domain-1.0.xsd">
>    C:        <domain:name>example.com</domain:name>
>    C:      </domain:update>
>    C:    </update>
>    C:    <extension>
> [..]
> 
> 
> My current understanding is that RFC3915 is indeed correct related to
> the current RFC3731, and not secdns-08, but after the changes in
> rfc3731bis, secdns-08 is correct, and the empty domain:chg in rfc3915
> can be removed.
> 
> However in the mean time, a server using rfc3731 and enforcing the
> rule:
> "At least one <domain:add>,
>     <domain:rem>, or <domain:chg> element MUST be provided."
> will reject a change as done in the secdns-08 example.

It shouldn't necessarily reject the change.  There's an error in 3731
because the schema allows the element to be omitted and the text
doesn't.  This is clearly an inconsistency and I'll admit that a version
change might help isolate the inconsistency.

> So a client connecting to a RFC3731 or RFC3731bis server should act
> in two different ways, hence my request to be able to separate
> automatically those two cases.

Depends on if you implemented to the text or to the schema.  A server
implemented to the schema is unaffected.  It WILL, however, be affected
if we change the version number.

My barometer for version change has always been schema change.  Change
the schema, change the version number.  This situation presents a bit of
a problem, though, because the text change can definitely have an impact
on server software that deals with extensions.

I don't know which solution is appropriate in this case, so I'll ask:
what would be the impact to existing extension implementations if the
domain, host, and contact version numbers were incremented?  What would
other implementers prefer to do?

-Scott-

---

From: janusz <[email-masked]>
Date: Tue, 20 Sep 2005 13:20:39 -0400

>on server software that deals with extensions.

Impact on EPP clients could be used as addtional measurement tool for 
version number changes.  EPP client implementations should outnumber 
server implementations by very wide margin.

>other implementers prefer to do?
Impact on existing client EPP implementations can be avoided or limited 
if version number stays the same. If version number is upgraded then 
client changes are necessary.

Server changes are required regardless whether version is upgraded or 
not. The scope of server changes is larger in case when version number 
is incremented.

Cheers,

Janusz Sienkiewicz

---

From: James Gould <[email-masked]>
Date: Tue, 20 Sep 2005 13:33:37 -0400

In reviewing this thread, I don't believe there is a need for a protocol
version number change considering the lack of severity of this issue and the
impact of a version number change on existing implementations.  Bumping the
protocol version should be reserved for changes that require XML schema
updates.  

Technically the server should return an error with an empty update according
to the current specification, but in reality there is no real harm in the
server accepting an empty update since the net effect is that no change will
occur.  I don't know any client that would intentionally send an empty
update with the expectation of an error response.  The only time an empty
update is utilized is in support of new extension operations like the
restore request in RFC 3915.  Our implementation does allow for an empty
update to conform to the extension specifications, so the new text will
match our implementation.

My vote is to leave the protocol version and schemas as is and change the
specification text as proposed.

-- 

JG 

James F. Gould
VeriSign Naming and Directory Services
[email-masked]

This message is intended for the use of the individual or entity to which it
is addressed, and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. Any unauthorized use,
distribution, or disclosure is strictly prohibited. If you have received
this message in error, please notify sender immediately and destroy/delete
the original transmission

> From: "Hollenbeck, Scott" <[email-masked]>
> Date: Tue, 20 Sep 2005 12:32:16 -0400
> To: Patrick Mevzek <[email-masked]>, <[email-masked]>
> Subject: RE: [ietf-provreg] EPP to Draft: Next Steps
>

---

From: "Michael Young" <[email-masked]>
Date: Tue, 20 Sep 2005 13:51:35 -0400

Well I am rather torn on the subject, on one hand I agree with James and
Janusz that it does entail more effort and is it worth it?  On the other
hand Patrick's argument that the change could break existing server/client
behavior hasn't been adequately refuted in my opinion.  

So Scott I guess I would say that the "safest" choice is to increment the
version number.  The changes required for existing server and client
implementations are trivial to conform with this version change.  As Janusz
stated, the changes in the documents are going to lead to server changes for
some implementers anyways.  

The biggest thing to avoid for everyone was having to run a dual protocol
server but I don't see that this would be necessary with this version
increment, given the nature of the changes.

Michael Young 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Gould
Sent: Tuesday, September 20, 2005 1:34 PM
To: Hollenbeck, Scott; Patrick Mevzek; [email-masked]
Subject: Re: [ietf-provreg] EPP to Draft: Next Steps

-- 

JG 

James F. Gould

>> as all three elements are in a sequence with minOccurs=0) For an 
>> extension, there is thus the need of an empty domain:chg with true 
>> changes in the extension part.
> 
> All having a minOccurs=0 attribute means that all are optional.  This 
> is part of the error in 3731.  The schema correctly says they don't 
> need to be there.  The text does.  The text is wrong.
> 
> If a client send an empty element and an extension element as 
> described in the old text, the server should do nothing with the empty 
> element because the "real" update is described in the extension.  
> That's still the case with the new text, except that the new text now 
> accurately reflects what's in the schema.  It might indeed cause a 
> problem for a server written to the old text.
> 
> doesn't.  This is clearly an inconsistency and I'll admit that a 
> version change might help isolate the inconsistency.
> 
> implemented to the schema is unaffected.  It WILL, however, be 
> affected if we change the version number.
> 
> the schema, change the version number.  This situation presents a bit 
> of a problem, though, because the text change can definitely have an 
> impact on server software that deals with extensions.
> 
> domain, host, and contact version numbers were incremented?  What 
> would other implementers prefer to do?
> 
> -Scott-
> 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Sep 2005 16:18:15 -0400

> increment, given the nature of the changes.

Like Michael, I'm of two minds about the change; but I have doubts
about the claim above.  A version number change is an automatic
client-server incompatibility, if I understand the documents
correctly, so it will either require a flag day upgrade or some sort
of dual-protocol support.  For ICANN-regulated registries, the
decision might be made by the GNSO instead of the registry, too, so
there are some pretty powerful external reasons to prefer leaving the
version number alone.  (That doesn't mean that we should prefer it;
it's just a consideration.)

I think the most principled stand might come from the answer to the
question, "What part of the RFC is 'most normative'?"  If the XML
schema is definitive, and overrules the text where there is
disagreement, then we have an easy answer.  If the _text_ is
definitive, and the XML is mere formalization, then we have a harder
time.

Perhaps there are others who have more experience, and are aware of
cases where this sort of text/formalization inconsistency has been
solved before (and how).  I don't know of any precedents.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Sep 2005 16:55:25 -0400

>specification text as proposed.

Ditto.  I talked it over with our coders and they agree with this.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Sep 2005 11:58:44 -0400

> be there.  The text does.  The text is wrong.

Agree. Schema is normative.

>                                  It might indeed cause a problem for a

A problem only for server(s) written (imprudently) to the (non-normative)
text.

> My barometer for version change has always been schema change.

Agree.

Delta text, not version identifier and definitely not schema.

Cheers,

Eric

---

From: "Michael Young" <[email-masked]>
Date: Tue, 20 Sep 2005 17:59:48 -0400

Scott looks like you have a significant group saying don't version - I will
defer to the collective given that clearly no one wants the hassle of a
version change.

Patrick I still think you have a point but it seems like not a strong enough
one for this audience.      

Best

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Brunner-Williams in Portland Maine
Sent: Tuesday, September 20, 2005 11:59 AM
To: Hollenbeck, Scott
Cc: Patrick Mevzek; [email-masked]; [email-masked]
Subject: Re: [ietf-provreg] EPP to Draft: Next Steps 

Agree.

Cheers,

Eric

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 21 Sep 2005 00:23:40 +0200

Michael Young <[email-masked]> 2005-09-21 00:08
> Patrick I still think you have a point but it seems like not a strong enough

I have no problem with that, and did not want to cause so much
trouble. I have read and implemented the
documents in one way, others in another. I will change my software to
accomodate both cases, and future version of documents will be more
clear, which will be a benefit for everyone. Sorry not to have
spotted this discrepancy way earlier, I'm kind of always late, and
sorry for the trouble.

> Agree. Schema is normative.

And when XML did not exist, what was normative in the RFC ? The text,
no ? :-)

> A problem only for server(s) written (imprudently) to the (non-normative)

Since it is nowhere written that some part is less normative than
another, I believe it to be risky to say something is imprudent.
This is another reason for interoperability tests :-)

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Sep 2005 12:06:12 -0400

> And when XML did not exist, what was normative in the RFC ? The text,

During the drafting process Scott published the corresponding schema.

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 21 Sep 2005 00:43:32 +0200

Eric Brunner-Williams in Portland Maine <[email-masked]> 2005-09-21 00:36
> During the drafting process Scott published the corresponding schema.

I was speaking about other RFCs, either not using XML at all, or
before XML existed and became widespread for protocols.

I know that I probably should have followed the well known rule that
the code (here the XML schema) is more authoritative than the
documentation (here the text), but I'm still a newbie here.
Of course, I have noone to blame, except me, and
I just hope things will be even better in the next iteration, with
this discrepancy removed so that my error will benefit others.