Re: [Privacy-pass] Httpdir last call review of draft-ietf-privacypass-protocol-12

To follow up here, Chris published a revision just now to address this:

https://www.ietf.org/archive/id/draft-ietf-privacypass-protocol-13.html

Best,
Tommy

> On Aug 30, 2023, at 8:53 PM, Mark Nottingham via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Mark Nottingham
> Review result: Ready with Issues
> 
> 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
> caching..'.
> 
> * 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:
> <https://httpwg.org/admin/editors/style-guide>
> 
> * 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?
> 
> 
> 
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass