Re: [httpapi] Idempotency Key - Are we ready for last call?

[Mark Nottingham <[e-mail]>]

I think this document needs significant work before it's ready to publish.

I've made a number of editorial suggestions in a PR.

More substantially, there are many vague and open statements in this specification. For example:

> Uniqueness of the key MUST be defined by the resource owner and MUST be implemented by the clients of the resource server.

How is this interoperable? If the resource has to document the syntax and semantics of the value, what does standardising it add?

> The resource MAY enforce time based idempotency keys, thus, be able to purge or delete a key upon its expiry. The resource server SHOULD define such expiration policy and publish it in the documentation.

Again, this seems counter to the goal of interoperability. If there's an expiration mechanism, a client should be able to discover it in an interoperable fashion.

It may be that a future development -- e.g., something in OpenAPI -- might provide these mechanisms. If that's the case, fine, but this specification doesn't need to invite interop problems by making these statements; it should be silent.

Throughout, RFC2119 requirements are misused. Concentrate on what MUST be done for interoperability, and remove the MAYs and SHOULDs.

Does the 'idempotency fingerprint' concept really add anything here? I understand that some implementations may do it, but should we document it as part of the standard?

Section 2.7 defines multiple ways to signal errors -- again, bad for interoperability. Choose one, unless there is a convincing reason why more than one method is necessary (in which case, document when it's appropriate to use each). 

Those are the high-level concerns I had from a quick pass over the document.

Cheers,




> On 6 Jan 2024, at 12:39 pm, Darrel Miller <[e-mail]> wrote:
> 
> Hey Sanjay, Jeyadeba,
> 
> Other than Mark's question about Repeatable Read, there are no more open issues for this document.  Are you ok for me to issue last call on this document? 
> I'll be doing the shepherd write up for it.
> 
> Darrel
> -- 
> httpapi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpapi


--
Mark Nottingham   https://www.mnot.net/