Some comments:
- I believe an idempotency considerations section is in order and its writing
will allow confirmation of idempotency throughout the spec
- For instance, it would have indicated the renewal section to have a MUST
instead of a MAY for the current expiration date. Without that there is no
idempotency for the renewal transaction.
- I believe the create command should use PUT instead of POST because an object
is being added
- I believe the renewals and transfers should focus on the attribute being
changed and not on the action, like in /{c}/{I}/expiration and
/{c}/{I}/stewardship
- A transfer request should be a PUT. A transfer approve should be a PATCH.
- Since there is no option in EPP to stack transfer requests, I don’t see the
need for the “latest” component in transfers. Either there is a single transfer
in progress or there isn’t .
- You might want to consider add the information that there is a transfer in
progress to GET /{c}/{I}/.
- Mapping of already approved standard extensions (TMCH, pricing, balance)
could be described to ensure the extension component will support them.
Possibly in a different draft though. Rubens > Em 15 de fev. de 2024, à(s) 07:22, Maarten Wullink > <maarten.wullink=40sidn...@dmarc.ietf.org> escreveu: > > Hi all, > > We have just uploaded the 01 version of the draft for RESTful EPP > > https://datatracker.ietf.org/doc/draft-wullink-restful-epp/ > > We have requested some time at the meeting in Brisbane, to discuss the > changes we’ve made between the 00 and the 01 version > and to receive guidance on how to best proceed from here. > > All feedback is very welcome! > > Best, > > Maarten > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
