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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Sep 2005 09:27:49 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Tuesday, September 20, 2005 8:50 AM
> To: [email-masked]
> Subject: Re: [ietf-provreg] EPP to Draft: Next Steps
> 
> Hello,
> 
> Sorry not to have responded earlier.
> 
> Hollenbeck, Scott <[email-masked]> 2005-09-13 19:02
> > 1. I need to make a minor edit to the contact (3733bis) and host
> > (3732bis) documents to fix one last <poll> use description. 
>  I described
> > that fix here [1].  I also need to add a sentence to 
> 3730bis (EPP core)
> > to note that it obsoletes 3730.  The references in 3731bis 
> (domain) will
> > need to be updated if 3732bis and 3733bis change.  These 
> are the last
> > needed document changes I'm aware of.
> 
> I think it would be good if these new versions got a 1.1 value in the
> <version> tag during server greeting as opposed to 1.0 for the
> current RFCs.
> 
> 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.

-Scott-

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 20 Sep 2005 16:33:30 +0200

Hollenbeck, Scott <[email-masked]> 2005-09-20 16:14
> 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/>