On Wed, Jun 17, 2020, at 08:23, Hollenbeck, Scott wrote: > 7) Section 10.2.3 - The definition of "last changed" event type seems > to be inconsistent with "upDate" defined in RFC 5731,5732,5733. For > example, I report an extract from RFC5731 here in the following: > > - An OPTIONAL <domain:upDate> element that contains the date and > time of the most recent domain-object modification. This element > MUST NOT be present if the domain object has never been modified. > > So, should we redefine the "last changed" event accordingly? Should we > change all the examples where "last changed" date is equal to > "registration" date? > > [SAH] I think we can leave this one alone. The meaning seems clear to > me since we also have the registration event. We could change the > examples, but before I do that I'd like to know what people have > implemented. Do servers return this value for an object that has been > registered, but never updated?
The problem I think is that we try to bake too much policy stuff here in the protocol. There is no harm at the protocol level (both EPP or RDAP) if upDate/last changed is there even right after just a create. The EPP wording may infer that should not happen but one could argue that a creation is a kind of modification in fact. And even without arguing I am sure some EPP servers set upDate right after creation, probably because, even if the registrar sees only a create, for the registry it could be internally a create + update (like create the domain without the nameservers and then add nameservers). The EPP text does not specify "if the domain object has never been modified." but by modified registry or registrar? Take the case also of defered domain creations, those starting in pendingCreate and allocated later. It may happen that crDate is the time at which the request came in but upDate will then be set when the status change from pendingCreate to ok. This status change is a modification and hence per above text could allow upDate to be set, yet it is not a registrar triggered modification. So I am neutral on the change to apply or not apply in RDAP specification, but I would emphasize that whatever you do, like for EPP, you will find implementations that add the last changed date right after creation and creation only. This is for me more policy stuff (and good registry documentation would specify that somewhere, even if I bet it doesn't happen), as it has no real consequences on the protocol or interoperability matters. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
