Re: [ietf-provreg] Anyone working on 4310-bis?

[Klaus Malorny <Klaus.Malorny@knipp.de>]

On 04/11/09 14:31, Ulrich Wisser wrote:
>>>> 3. Support for the combination of add and rem
>>> Yes, provided the text clearly states that only one outcome can
>>> occur. This can mean doing all adds first, or all removes first. Of
>>> course, all adds can occur in any order, as can all removes. Allowing
>>> policy to dictate how this works would be mean that registrars would
>>> have to support both.
>>
>> I don't think I understand your remark here. I thought the idea was
>> that we make this a sequence, such that the outcome is whatever that
>> sequence of operations would be. No?
>
> But the sequence in the schema does allow only one kind of sequence. It
> will always be add/rem or rem/add. The schema doesn't allow you to
> choose which one to put first. And therefor the order of execution will
> be fixed.
>
> But if we go for the new dsData/keydata changes for the rem command I
> can't see that we would need rem/add and add/rem. Either scheme allows
> all reasonable updates. As dsData identifies exactly on ds record and
> keydata exactly one key adding and removing the same ds record/key in
> one epp command could be considered unreasonable, couldn't it?
>
> /Ulrich

Hi all,

just an attempt to clarify:

The XML Schema <sequence> *only* defines the order of the elements in the XML 
file. It *does not* impose any implicit processing order. A protocol can define 
any processing order it likes.

Also, there is one <add> and/or <rem> element at most in a request. However, 
within each of them, multiple elements may occur to represent multiple DS 
records (or keys, if you will).

Personally, I really don't care about the order in the XML document, but I 
prefer the perform the removals first and then the additions. Ulrich's way to 
reject a request if a DS record appears both in <add> and <rem> would be also 
acceptable to me, but it makes the implementation a little bit more complex if 
the <keyTag> in the <rem> section is retained -- in this case, the DS data has 
to be checked against these <keyTag> elements as well.

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