Re: [ietf-provreg] EPP to Draft: Next Steps
Patrick Mevzek <provreg@contact.dotandco.com> Tue, 20 September 2005 14:44 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHjM8-00058a-N4 for provreg-archive@megatron.ietf.org; Tue, 20 Sep 2005 10:44:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04869 for <provreg-archive@ietf.org>; Tue, 20 Sep 2005 10:44:22 -0400 (EDT)
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHjRt-0006YT-DO for provreg-archive@ietf.org; Tue, 20 Sep 2005 10:50:27 -0400
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j8KEXWWc004214 for <ietf-provreg-outgoing@nic.cafax.se>; Tue, 20 Sep 2005 16:33:32 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j8KEXWIq005908 for ietf-provreg-outgoing; Tue, 20 Sep 2005 16:33:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from nohope.patoche.org ([62.160.23.78]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j8KEXVUv001302 for <ietf-provreg@cafax.se>; Tue, 20 Sep 2005 16:33:32 +0200 (MEST)
Received: from nohope.patoche.org (localhost.localdomain [127.0.0.1]) by nohope.patoche.org (8.13.4/8.13.4/Debian-3) with ESMTP id j8KEXVKp007878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-provreg@cafax.se>; Tue, 20 Sep 2005 16:33:31 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.13.4/8.13.4/Submit) id j8KEXV6E007876 for ietf-provreg@cafax.se; Tue, 20 Sep 2005 16:33:31 +0200
Date: Tue, 20 Sep 2005 16:33:30 +0200
From: Patrick Mevzek <provreg@contact.dotandco.com>
To: ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] EPP to Draft: Next Steps
Message-ID: <20050920143330.GF28515@nohope.patoche.org>
References: <046F43A8D79C794FA4733814869CDF07E20EFE@dul1wnexmb01.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <046F43A8D79C794FA4733814869CDF07E20EFE@dul1wnexmb01.vcorp.ad.vrsn.com>
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD 9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Dot And Co
User-Agent: Mutt/1.5.9i
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
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/>
- [ietf-provreg] EPP to Draft: Next Steps Hollenbeck, Scott
- RE: [ietf-provreg] EPP to Draft: Next Steps Michael Young
- RE: [ietf-provreg] EPP to Draft: Next Steps Hollenbeck, Scott
- Re: [ietf-provreg] EPP to Draft: Next Steps Patrick Mevzek
- RE: [ietf-provreg] EPP to Draft: Next Steps Hollenbeck, Scott
- Re: [ietf-provreg] EPP to Draft: Next Steps Patrick Mevzek
- RE: [ietf-provreg] EPP to Draft: Next Steps Hollenbeck, Scott
- Re: [ietf-provreg] EPP to Draft: Next Steps janusz
- Re: [ietf-provreg] EPP to Draft: Next Steps James Gould
- RE: [ietf-provreg] EPP to Draft: Next Steps Michael Young
- Re: [ietf-provreg] EPP to Draft: Next Steps Andrew Sullivan
- Re: [ietf-provreg] EPP to Draft: Next Steps Edward Lewis
- Re: [ietf-provreg] EPP to Draft: Next Steps Eric Brunner-Williams in Portland Maine
- RE: [ietf-provreg] EPP to Draft: Next Steps Michael Young
- Re: [ietf-provreg] EPP to Draft: Next Steps Patrick Mevzek
- Re: [ietf-provreg] EPP to Draft: Next Steps Eric Brunner-Williams in Portland Maine
- Re: [ietf-provreg] EPP to Draft: Next Steps Patrick Mevzek