[art] Artart last call review of draft-ietf-httpbis-proxy-status-06
Jim Fenton via Datatracker <noreply@ietf.org> Sat, 21 August 2021 18:57 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D92533A1D41; Sat, 21 Aug 2021 11:57:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jim Fenton via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-httpbis-proxy-status.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162957224782.5016.13692797609730766925@ietfa.amsl.com>
Reply-To: Jim Fenton <fenton@bluepopcorn.net>
Date: Sat, 21 Aug 2021 11:57:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/slXTvhFQGNlZRdZFgMQcdB1vs94>
Subject: [art] Artart last call review of draft-ietf-httpbis-proxy-status-06
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2021 18:57:28 -0000
Reviewer: Jim Fenton Review result: Almost Ready Substantive comment: The third paragraph from the end of Section 2 says: When adding a value to the Proxy-Status field, intermediaries SHOULD preserve the existing members of the field, to allow debugging of the entire chain of intermediaries handling the request. Under what circumstances would an intermediary need to mess with existing Proxy-Status entries? Please consider upgrading this requirement to a MUST, and perhaps also require that the ordering of existing entries be preserved. Minor comments: The descriptions of errors in sections 2.3.13, 2.3.14, 2.3.28, 2.3.30, and 2.3.31 all contain a paragraph saying, "Note that additional information...(as is the case for all errors)." It isn't clear whether this text belongs in the "Notes" column of the registry entry being created since it is separate from the bulleted list describing the entry. Please consider removing this text in these sections and instead including it as introductory text describing the error parameter. The Notes for the entries either are empty or contain the text, "Responses with this error type might not have been generated by the intermediary." I wonder if this might more efficiently be represented by a Boolean flag in the registry entries, but probably preserving the Notes field in the registry for future use. The introduction uses both the phrase "towards the origin server" and the term "upstream". It might be helpful to some readers to make it clear that they're synonymous, e.g., "towards the origin server (upstream)" Section 1.1 says that this specification uses ABNF, but I find only structured fields. Consider removing the mention of ABNF and the informative reference to RFC 5234.
- [art] Artart last call review of draft-ietf-httpb… Jim Fenton via Datatracker
- Re: [art] Artart last call review of draft-ietf-h… Mark Nottingham
- Re: [art] Artart last call review of draft-ietf-h… Francesca Palombini