Re: Anyone working on 4310-bis?

Klaus Malorny <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
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 [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.