Re: 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 [email protected]
>