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

[Patrick Mevzek <provreg@contact.dotandco.com>]

Hollenbeck, Scott <shollenbeck@verisign.com> 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.

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

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.

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.

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