[Last-Call] Httpdir last call review of draft-ietf-privacypass-protocol-12
Mark Nottingham via Datatracker <noreply@ietf.org> Thu, 31 August 2023 03:53 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/vCWS_SOJN1nI6XqW0pI3Rlap-z0>
Subject: [Last-Call] Httpdir last call review of draft-ietf-privacypass-protocol-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2023 03:54:00 -0000
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?
- [Last-Call] Httpdir last call review of draft-iet… Mark Nottingham via Datatracker
- Re: [Last-Call] [Privacy-pass] Httpdir last call … Tommy Pauly