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

["Michael Young" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
Behalf Of James Gould
Sent: Tuesday, September 20, 2005 1:34 PM
To: Hollenbeck, Scott; Patrick Mevzek; [e-mail]
Subject: Re: [ietf-provreg] EPP to Draft: Next Steps

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
[e-mail]

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" <[e-mail]>
> Date: Tue, 20 Sep 2005 12:32:16 -0400
> To: Patrick Mevzek <[e-mail]>, 
> <[e-mail]>
> Subject: RE: [ietf-provreg] EPP to Draft: Next Steps
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Patrick Mevzek
>> Sent: Tuesday, September 20, 2005 10:34 AM
>> To: [e-mail]
>> Subject: Re: [ietf-provreg] EPP to Draft: Next Steps
>> 
>> Hollenbeck, Scott <[e-mail]> 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-
> 
>