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]