Editors meeting suggestion: add a correlation id for the registration to coordinate on long-running operation requests.

Question from the editor's call: Was the request ID also meant to be the operationId, or was it intended to be a tuple where the client can submit a unique ID that needs to be validated? However, can the server return a guaranteed unique ID? The client submitting a unique ID is part of the idempotent design pattern.

Some background on idempotent patterns

• IETF Draft: The Idempotency-Key HTTP Header Field
• Life beyond Distributed Transactions
• Reducing client complexity with idempotent API design
• Idempotent REST API

Do we need a request ID (Idempotency-Key)?

1. If the client makes a registration request and fails to get a response, the client is unsure if the registration was received, the response failed, or the request was never received.
2. The client would try again, which could generate multiple registrations

In an idempotent world, the server would check if the request was previously made and, if so, return the same response.
The issue is that a client could be intentionally making a secondary registration because the registration policy may have changed or the client needs a new registration for a new point in time.

• Do we need to support multiple registrations of the same signed statement from the same issuer?
  • Yes, as client may be registering, knowing a new registration policy has been set, or they simply need a new registered timestamp. If the client wishes to register the same signed statement multiple times, they would generate a unique Idempotency-Key
• Can the server specify a window of time (which is implementation-specific) by which it treats them as idempotent?
  • Yes, and Section 2.3. Idempotency Key Validity and Expiry supports the scenario. If the client submits a second registration, and the server purged the Idempotency-Key, the "duplicate request" would generate a duplicate entry
• How short should validity window be?
  • This is likely a new issue, with a SHOULD that would hopefully represent weeks or months, if not years.

Separately, a discussion to support success/failure response codes for failed registration vs. "not found" is needed.

Question from the editor's call: Was the request ID also meant to be the operationId, or was it intended to be a tuple where the client can submit a unique ID that needs to be validated? However, can the server return a guaranteed unique ID? The client submitting a unique ID is part of the idempotent design pattern.

The addition of the request_id in Commit 4 came out of the discussion in the prior editors' call where a couple of people asked for some kind of a correlation ID that the client could use to keep its own track of the LROs it was checking and receiving. Various use cases were mooted all along the lines that contexts may be confused (in the case of connection pooling or similar at the client end) or lost (in the case of one end or other crashing).

This seemed reasonable to try to accommodate and I did it to show how it might look, but actually I don't like how it's turned out and would gladly revert. Reasons:

• Having the operation ID and request/correlation ID was redundant...unless we also enabled LIST on /operations which doesn't seem terribly sensible. That's why I removed the server-generated ID from the resource path.
• Inserting the optional request ID into the POST required us to throw it in the unprotected header, which feels grotty

In an idempotent world, the server would check if the request was previously made and, if so, return the same response. The issue is that a client could be intentionally making a secondary registration because the registration policy may have changed or the client needs a new registration for a new point in time.

I like the idempotency key stuff and we should look into it but I think it's a reasonable and coherent v1 to just say that EVERY POST is a new registration and starts a new registration operation for a new receipt. We can't legislate for software bugs or try to guess the intention of the client.

Separately, a discussion to support success/failure response codes for failed registration vs. "not found" is needed.

Agreed. That's already on the list.

I like the idempotency key stuff and we should look into it but I think it's a reasonable and coherent v1 to just say that EVERY POST is a new registration and starts a new registration operation for a new receipt. We can't legislate for software bugs or try to guess the intention of the client.

Yes, I think I am convinced by this argument, the request_id returned for the /operations call is a unique identifier for the registration and is enough for clients. The ability to set request_id in the registration request is unnecessary and may be confusing. I would also suggest to rename request_id to registration_id to make it clear that it is the identifier picked by the server when the registration is accepted

@JAG-UK here are my proposed changed to resolve this

jag-uk/23-distinct-async-operations...ad-l:draft-ietf-scitt-scrapi:jag-uk/23-distinct-async-operations

Meeting notes:
This PR dealt with several aspects, making it a bit harder to merge.
Jon will create separate PRs, based on work for 121 hackathon.