Telechat Review of draft-deshpande-secevent-http-multi-set-push-05
review-deshpande-secevent-http-multi-set-push-05-httpdir-telechat-nottingham-2026-10-13-00

# Issues

## Absent Motivation

This document is motivated by the following argument:

> When sending a large number of SETs, sending them one by one is inefficient.

That ignores the possibility of using multiplexing in HTTP/2 and HTTP/3. While
applications do need to consider efficiency in their API design, they should
not needlessly create affordances for efficiency when adequate improvements are
available and ready in the protocol infrastructure.

It may be that there is another reason for submitting more than one SET at the
same time -- for example, batching them because there are interdependencies, or
enforcing ordering (when timestamps or other ordering mechanisms are
insufficient). However, the document does not argue that.

As such, I would recommend the IESG not progress this document unless a strong
motivation for it can be found and described sufficiently.

## URI vs media type

The document also establishes a separate endpoint for batched SET submission.
Was using a different media type to denote a batch considered? In general
indicating format syntax is done with media types, not by duplicating endpoints.

RFC 8935 leaves the SET endpoint URL deployment-specific, so operators
configure one URL per Recipient. Requiring a second URL for batches doubles
that configuration and leaves undefined how the two relate (same host, same
authentication, same Transmitter identity). It also invites operators to settle
on fixed path conventions for the new endpoint, which BCP 190 discourages. A
media type on the existing endpoint avoids all three.

## Acknowledgements and identity

Section 5 puts Transmitter authentication out of scope, yet also introduces a
new mechanism -- the ability to read the status of previously submitted SETs in
section 4.4.

This leaves open _which_ previously submitted SETs should be acknowledged
(etc); without a concept of client identity in the spec, an implementer could
easily get this wrong and leak acknowledgements.

Also, getting state from the server by sending a POST with an empty data
structure is convoluted; this is bad protocol design. Create some sort of
stateful session (most likely via a dedicated resource) and use GET (if acks
are not cleared by the request).

# Comments

* Terminology. The use of 'Recipient' conflicts with HTTP; use 'SET Recipient'
and 'SET Transmitter' consistently.

* Accept. Section 4.3 requires Accept to be "application/json". However, you're
also using problem details, which has its own media type.

* 4.4.1 requires 202 with a MUST. This is the "POST MUST return 201" pattern,
and an intermediary, a redirect or a deployment choice can produce other codes.
Say "a 2xx response of this form".

* Figure 5 shows authentication_failed with 400, where the semantics call for
401 or 403. RFC 8935's own examples do the same, so the authors have a
precedent, but it is still the wrong approach.

* The draft doesn't say which status goes with too_many_sets, though 7.1
implies 413. It is also unstated whether any non-2xx response means none of the
request's SETs were accepted. It should say so for 413 and for 5xx or 503 from
an intermediary.

* Use the current name, 413 (Content Too Large).

* Retries and overload. Nothing covers 429 or 503, Retry-After, backoff or
jitter.

* Redirects. For POST, 301 and 302 may become GET. Say whether Transmitters
follow redirects (307 and 308 only, and only to https).

* Endpoint URI. Say it is an https URI, and cite RFC 9110 4.3.4 for certificate
checks.

* Ack response media type. This recurs from the earlier HTTPDIR review.
Register a type for the ack object, or say why not.

* Distinguishing support. A Recipient that supports only RFC 8935 should answer
415 to application/secevents+json. Consider Accept-Post (RFC 7694) for
advertising support.

* Media type registration. For a +json type, the fragment identifier
considerations should follow RFC 6839, and the draft should reference it.

# Nits

* "body" and "payload" appear throughout; use "content".

* Content-Type, not "content-type" (4.4.1) or "Content-type" (Figures 3 and 4).

* "Section 4.4.1 Section." (in 4.4.2) and "section Section 5" (in 7.2).

* 4.3 says "MUST contain the following fields" before a single field. Say
"member" for JSON.

* The Figure 1 JWTs have line breaks inside JSON strings. Use RFC 8792 folding
and mark the examples http-message in source so they can be validated.

* Figure 4's "errors ... for acknowledging one SET" reads badly.

* Section 1 says it "will handle all the use cases" of RFC 8935. This is an
alternative, not a replacement; state the relationship.

* Sections 5 and 7.2 duplicate each other.

* Use named references for HTTP and TLS.