draft-deshpande-secevent-http-multi-set-push-00 early Httpdir review

[Darrel Miller via Datatracker <[e-mail]>]

Document: draft-deshpande-secevent-http-multi-set-push
Title: Push-Based Delivery For Multiple Security Event Token (SET) Using HTTP
Reviewer: Darrel Miller
Review result: On the Right Track

I am the assigned HTTPDIR reviewer for this draft. Please treat these comments
just like any other last call comments.

Summary: On the right track

Section 3.1

"A Transmitter MUST ensure that it includes the jti value of each SET it
receives… to the Transmitter"

I believe this should say "A Receiver MUST ensure" as it is referring to
acknowledging the receipt of SETs back to the Transmitter.

## Section 3.3

Considering RFC8417 went to the effort of registering application/secevent+jwt
it would seem unfortunate that this draft would fall back on using
application/json.  Would the authors consider registering
application/secevents+json as a media type for containing a list of SETs?

## Section 3.4

"The Transmitter SHOULD limit 20 SETs in the sets."

This sentence is a little difficult to parse considering the terminology. 
Perhaps wording such as,

"The Transmitter SHOULD limit the sets object to 20 members"

may reduce the confusion.

References to RFC 7231 should be replaced by RFC 9110.

## Section 3.4.1 Success Response

"If the Receiver is successful in processing the request, it MUST return the
HTTP status code 202 (Accepted)."

If the Receiver is only "accepting" the request then the 202 status code is
fine.  The term "processing the request" would suggest that a 200 response
would be more appropriate.

However, this statement in section 3 suggests that a 202 is more appropriate,

"The SET Recipient SHALL NOT use the event acknowledgement mechanism to report
event errors other than those relating to the parsing and validation of the
SET."

I would suggest replacing the word "processing" with "accepting".

## Section 3.4.2 Failure Response

Considering this section specifically calls out that the Failure Response are
not specific to SET specific errors, it would seem appropriate to use the
http-problem media type RFC 9457: Problem Details for HTTP APIs for returning
these errors rather than reusing the "err" and "description" structure used in
the success response.

## Section 3.4.3 Error Response

I am confused by this section. Section 3 suggests that only "parsing and
validation" errors should be returned in the 202 response and section 3.4.2
describes the scenario there the HTTP request fails for generic reasons.  I
don't understand under which conditions a RFC 8935 style error response would
be returned.   Is this describing an HTTP response or simply qualifying the
error code to be used in the setErrs list?

Regards,

Darrel