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

["Hollenbeck, Scott" <[e-mail]>]

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