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

[Thibault Meunier <[e-mail]>]

Hi Martin,

I've proposed some changes on GitHub https://github.com/ietf-wg-privacypass/ietf-draft-privacypass-batched-tokens/pull/58

I have not added anything on redirect to stay in line with [RFC9578]. Would a reference to [RFC9110] be sufficient here, or are you looking for specific handling?

On point I'm still unsure about is how to best satisfy "Using HTTP Status Code" of [RFC9205]. The PR removes normative MUST qualifying HTTP status code, replaces 422 with 400, removes 206 partial response discussion, and allow successful responses without forcing a status code. Is this the type of writing you were referring to in your review?

[RFC9578] https://datatracker.ietf.org/doc/html/rfc9578
[RFC9110] https://datatracker.ietf.org/doc/html/rfc9110
[RFC9205] https://datatracker.ietf.org/doc/html/rfc9205

Best,
Thibault

On Tuesday, October 13th, 2026 at 08:25, Martin Thomson via Datatracker <[e-mail]> wrote:

> Document: draft-ietf-privacypass-batched-tokens
> Title: Batched Token Issuance Protocol
> Reviewer: Martin Thomson
> Review result: Almost Ready
> 
> I've really only looked at the HTTP integration in this draft.  The bulk of the
> work is the two cryptographic protocols for obtaining multiple tokens.  On that
> part, I've not spent any time.
> 
> The HTTP integration is pretty straightforward: each protocol has a request for
> tokens, which returns the tokens in response.  Each protocol has a media type
> defined for request and response, which is perfectly fine and in line with how
> RFC 9578 does it.  I see no major problems in the high-level approach.  Where
> it gets a bit rough is in the use of status codes.  More on that below.
> 
> The description of how a client might obtain the URL where these requests are
> sent is a little thin.  RFC 9578 has a section on configuration, which
> addresses what a client needs to be given to use the protocol.  This draft sort
> of slides past that question a little too quickly for my taste.  One question
> I'd want answered is whether each protocol (of which there would be three now)
> would be expected to operate on different resources and with different keys.  I
> can see how you might be able to use content negotiation for this, but I'm
> unsure about the security properties you get if the RFC 9578 public keys are
> reused.  That's something to look at addressing.
> 
> The draft plays a little fast and loose with concepts from other PP documents,
> so I'd suggest tightening things up with references.  For instance, there is a
> token type that is taken from a challenge and fed as input to the request.  A
> citation for that datum, so it could be possible to get more detail on where it
> came from, would have been a great help.
> 
> The draft variously requires a 200, 400, or 422 status code with "MUST"-level
> strength.  BCP 56 advises against making such strong requirements.  Noting that
> the client can use a successful response to the POST request if it carries the
> right response media type works.  It seems like you might need to deal with
> redirects.  For this, I recommend reviewing Section 4.6 of RFC 9205.  For
> instance, the 400 requirement might be something that a resource could use a
> 5xx series response for (indicating that it's a problem at the resource, not
> with the request; after all, the request could be valid) or a 429 response (the
> "you ask too much" code) or something else entirely.  HTTP relies heavily on
> status codes being more flexible than this specification currently allows for.
> 
> The requirement to use a 206 status code is not going to work very well without
> a fresh definition of a range type for Content-Range.  You probably don't want
> the pain that comes from that.  It's probably enough to say that a successful
> response might contain fewer than the number of requested tokens, such that
> clients need to cope.
> 
> As a minor point, I'm not sure that your design requires a minimal encoding for
> the RFC 9000 variable-length integer encoding.  As a general rule, I recommend
> avoiding unnecessary requirements, especially if you aren't enforcing them.  If
> you want this sort of thing, then you need to mandate *receiver* handling.  (I
> don't think you need a length prefix at all, but who am I to tell someone using
> TLS syntax that?)
> 
> 
> 
>