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

[James Gould <[e-mail]>]

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