[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: EPP Provreg <ietf-provreg@cafax.se>
From: Howard Eland <heland@afilias.info>
Date: Fri, 30 Oct 2009 12:58:25 -0500
In-Reply-To: <4AEB22CA.3050700@knipp.de>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?


On Oct 30, 2009, at 12:30 PM, Klaus Malorny wrote:

On 30/10/09 15:39, Andrew Sullivan wrote:
Hi,

Hi Andrew,


On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:

[...]
2) there is a consensus that<add>  and<rem>  elements shall be allowed in
a single request, which must be on the other hand mutually exclusive to
the<chg>  element.

Are we sure that the<add>  and<rem>  elements have to be processed in
the order in which they appear?  I am not completely sure.  I recall
at least one operator who had an issue related to this
processing-order question.  If they do _not_ have to be so processed,
then in fact they can't be allowed in a single request because the
effect could be different from what is intended.  (Note that this
remark also means that there is by no means a consensus on this matter
yet.)

[...]

This problem has always been the case with EPP. If I submit a domain update request with adding the status "clientHold" and removing the status "clientHold" at the same time, what is the outcome? This applies to contacts, name servers and other stuff as well.

So the protocol should clearly say how such a situation shall be handled:
- define a static execution order, e.g. first the removal, then the addition
- declare this as ambiguous and reject the order
- declare this as a non-change and ignore

By the way, as there seems to be some confusion: IMHO the order in the XML document should *never* imply any order of execution.

Yes and no - that's _exactly_ what <sequence> is for - to prescribe a predetermined order via XML.

If we follow RFC5731 (see below), using domain status as in Klaus' example, then the correct thing to do is declare update child elements as a <sequence>, with add first, then rem.  The RFC is silent beyond that, so I would assume that this means the server must execute all adds in any order, then execute all rems in any order, then execute all chgs in any order.

   <!--
   Child elements of the <update> command.
   -->
   <complexType name="updateType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="add" type="domain:addRemType"
       minOccurs="0"/>
      <element name="rem" type="domain:addRemType"
       minOccurs="0"/>
      <element name="chg" type="domain:chgType"
       minOccurs="0"/>
    </sequence>
   </complexType>



Not elements, but attributes, is the way I've got it at the moment.  I
didn't include the attributes other than the hash in the text as it's
written, but I think James has convinced me there'd be no harm in
adding the other ones.

If this "select" solution is taken, I don't mind whether it is implemented via elements or attributes.

Regards,

Klaus
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se



Home | Date list | Subject list