Patrick, As stated before, I do agree that the purging of the object either via the “delete” operation with the “op” attribute set to “purge” or the “autopurge” operation as a grey area, but the use of the “before” state is an optional feature of the protocol that is not meant to be used for this corner case. The server may choose to support providing both the before and after state, but is required to provide the after state. There is no clean mechanism to extend the info response of a purged object, so in the case of a “purge” or an “autopurge”, the last state of the purged object is returned. If we started mixing in the use of the “before” state with the “after” state, the client would need to interrogate the extension as well to determine whether the object was purged or whether the server is providing the before image of another operation. Fundamentally, clients can ignore the “before” state if that don’t require it and they should interrogate the change poll extension to determine what actions they should take. The opposite scenario would for the “create” operation, where there would be no “before” state but there would be an “after” state. I would recommend taking a similar approach here as well if a server chooses to support the “before” state option if they were to perform some form of create (bulk or individual) on behalf of the client. So, in general, the change poll extension needs to support the full set of CRUD operations, where the create and the delete (purge) represent a special case when supporting the required “after” state and the optional “before” state poll messages. Semantically you are correct that there is no “before” state for a create operation and there is no “after” state for a delete (purge) operation, but from a protocol perspective it’s important to separate the requirements for the “after” state behavior and the “before” state behavior. In this case, “after” is required and “before” is optional, so the extension must support an “after” state mechanism for all possible operations including the delete (purge).
I can add a subsection in section 2 to describe the expected before for both the create and the delete (purge) to ensure that the servers implement it consistently and the clients know what to expect. Do you agree? — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/2/18, 8:59 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: Hello James, >> I am not sure to understand the example for the autopurge. >> If the registry deletes a domain with an immediate purge I expect the >> domain not to exist anymore. But in your example you show the "after" >> state >> and there you have a domain:name and a domain:clID still... but the >> domain >> should not exist anymore. >> In my view you should have the before state with all domain:infDatq, and >> for the >> after state, there should be no domain data anymore. >> I agree it creates a problem as you loose the domain name itself >> in the message, but I still think there should be no domain >> data if it was purged. >> What do you think? > > I thought about this one, and yes this is a grey area. I believe it’s > more important to keep the use of the required “after” state here. The > use of the “before” state is optional and I don’t want to add complexity > by adding support for it here. In this case, the operation is > identifying to the client that the specified record that is included was > purged from the system. On a purely semantic level I still find it wrong to have an "after" purge message reflecting data as if the domain still exists. This will need to be handled by registrars as a specific case, since they could, for example, not always update their database based on the "after" messages because in this specific case if they do it like that they will see the domain existing, where it was deleted. So that message will have a specific handling just for it. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
