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


To: EPP Provreg <ietf-provreg@cafax.se>
From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Fri, 30 Oct 2009 18:30:50 +0100
In-Reply-To: <20091030143945.GE76006@shinkuro.com>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

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.

>
> 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