2.1.2.2 Status 202 requires the resolve receipts endpoint to do double duty

[robinbryce]

https://www.ietf.org/archive/id/draft-ietf-scitt-scrapi-01.html#name-status-202-registration-is-

"If 202 is returned, then clients should wait until Registration succeeded or failed by polling the receipt endpoint using the receipt identifier returned in the response."

I understand that to mean "poll the optional interface defined by 2.2.4 Resolve Receipt".

There are some issues with a request model that mixes "poll for operation a (OP A) completion, with do operation b (OP B)"

1. It forces complexity and mixed state handling on the endpoint implementation. It has to both determine if OP A was extant and is now complete, then it has to follow on and do dependent OP B. Mixed state handling can require that single instance has access to two differently provisioned and permissioned data stores.
2. It forces the same authorization & authentication model on both OP A and OP B. (I will raise a seperate issue for another concerne regading the authentication SHOULD for Resolve Receipt)
3. Implementors will likely want different rate limits for those actions. Checking if an extant operation is complete is light weight and can be designed for "polling clients". Producing a receipts, potentially finalising registration, could be a much heavier load. I would want the ability to seperately rate limit that request.

I very much prefered the previous draft's approach of having a distinct endpoint on which to check for the completion of async registration

[JAG-UK]

Agreed, I think a distinct operation handler makes sense and works cleanly from implementation experience. I can put up a PR to reflect this for the group to comment on