Skip to main content

Last Call Review of draft-ietf-privacypass-protocol-12

Request Review of draft-ietf-privacypass-protocol
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team HTTP Directorate (httpdir)
Deadline 2023-08-31
Requested 2023-08-17
Authors Sofia Celi , Alex Davidson , Steven Valdez , Christopher A. Wood
I-D last updated 2023-08-30
Completed reviews Artart Last Call review of -12 by Yoshiro Yoneya (diff)
Secdir Last Call review of -12 by Alexey Melnikov (diff)
Opsdir Last Call review of -12 by Susan Hares (diff)
Httpdir Last Call review of -12 by Mark Nottingham (diff)
Assignment Reviewer Mark Nottingham
State Completed
Request Last Call review on draft-ietf-privacypass-protocol by HTTP Directorate Assigned
Reviewed revision 12 (document currently at 16)
Result Ready w/issues
Completed 2023-08-30
Reviewing purely from the perspective of how this document uses HTTP>

* Given that 'This document describes the issuance protocol for Privacy Pass
built on [HTTP]', I suspect it should be a normative reference.

* 'The Issuer directory and Issuer resources SHOULD be available on the same
domain.' Is "domain" a _hostname_, _origin_, or something else, e.g., using the
Public Suffix List?

* 'Issuers SHOULD use HTTP caching to permit caching of this resource
[RFC5861].' Either 'SHOULD use HTTP cache directives...' or 'SHOULD permit

* Examples use HTTP/2; the style guide recommends using HTTP/1.1 for all
examples except for those that are specific to a protocol version. See:

* It's not necessary to specify Cache-Control on POST requests.

* 'If any of these conditions is not met, the Issuer MUST return an HTTP 400
error to the client.'

  - HTTP status codes should be spelled out; e.g., "400 (Bad Request)".

  - 422 (Unprocessable Content) might be a better status code to use here,
  though -- 400 will be used by generic HTTP software for problems at that
  layer, and so you won't be able to distinguish those problems from these more
  specific ones.

  - Also, we generally encourage using SHOULD when specifying a status code
  like this, so that clients don't form the view that they can depend on seeing
  this status code in this situation (they can't; intermediary and other
  software may change the status code).

  - Have you considered defining one or more HTTP problem types (RFC9457) to
  provide more granularity and detail?