Httpdir last call review of draft-ietf-privacypass-protocol-12
Mark Nottingham via Datatracker <noreply@ietf.org> Thu, 31 August 2023 03:54 UTC
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1qbYgL-00GbU9-2X for ietf-http-wg@listhub.w3.org; Thu, 31 Aug 2023 03:54:06 +0000
Received: from mail.ietf.org ([50.223.129.194]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1qbYku-008ubp-B9 for ietf-http-wg@w3.org; Thu, 31 Aug 2023 03:54:06 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28AC15DD44; Wed, 30 Aug 2023 20:53:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mark Nottingham via Datatracker <noreply@ietf.org>
To: ietf-http-wg@w3.org
Cc: draft-ietf-privacypass-protocol.all@ietf.org, last-call@ietf.org, privacy-pass@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169345403996.812.3096903782580737856@ietfa.amsl.com>
Reply-To: Mark Nottingham <mnot@mnot.net>
Date: Wed, 30 Aug 2023 20:53:59 -0700
Received-SPF: pass client-ip=50.223.129.194; envelope-from=noreply@ietf.org; helo=mail.ietf.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1qbYku-008ubp-B9 be4a795de72f8d03bf631d639111d1b7
X-Original-To: ietf-http-wg@w3.org
Subject: Httpdir last call review of draft-ietf-privacypass-protocol-12
Archived-At: <https://www.w3.org/mid/169345403996.812.3096903782580737856@ietfa.amsl.com>
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?
- Httpdir last call review of draft-ietf-privacypas… Mark Nottingham via Datatracker
- Re: [Privacy-pass] Httpdir last call review of dr… Tommy Pauly