Re: draft-ietf-privacypass-batched-tokens-08 early Httpdir review

[Martin Thomson <[e-mail]>]

I'm sure that there will be more, but that seems good.

On Mon, Nov 2, 2026, at 09:14, Thibault Meunier wrote:
> Thanks for the additional precision! I've opened [63] to clarify and 
> try to address them.
>
> In the previous change, I tried to follow Section 4.6 of RFC 9205 [1]
> | Applications using HTTP should define their errors to use the most 
> applicable status code, making generous use of the general status codes 
> (200, 400 and 500) when in doubt
>
> As I understand, you point that instead of using a generic 400, we 
> could either drop any status code recommendation ("the issuer rejects 
> the request") or make it clear these are examples ("the issuer rejects 
> the request, for instance with 422 (Unprocessable Content)").
>
> Is there any wording that you find clearer for the document?
>
> [1] https://www.rfc-editor.org/info/rfc9205/#section-4.6-4
> [63] 
> https://github.com/ietf-wg-privacypass/ietf-draft-privacypass-batched-tokens/pull/63
>
> Thanks,
> Thibault
>
>
> On Monday, November 2nd, 2026 at 08:40, Martin Thomson 
> <[e-mail]> wrote:
>
>> I noted this on the PR, but the general pattern for HTTP is to be looser in general.
>> 
>> The key insight you might need here is that a server (or intermediary) can reject a request for many reasons.  This includes faults of its own (overloading, etc...), errors in the request, and whatever other reason it chooses (see 429).  Being prescriptive about status codes interferes with that.
>> 
>> What you can do is say that rejecting a request with a 4xx series status code is expected in most of the conditions you described.  The content type check points to 415, for sure, but most of the others are generic errors that probably need generic language.  It's enough to say that the server is expected to reject the request; as a general rule, it's not necessary to specify even the series of status codes.