From nobody Wed Nov 2 14:32:57 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069E8C1522D7; Wed, 2 Nov 2022 14:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50joS3bvU8Ua; Wed, 2 Nov 2022 14:32:52 -0700 (PDT) Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842D0C1524B1; Wed, 2 Nov 2022 14:32:46 -0700 (PDT) Received: from client-0198.vpn.uni-bremen.de (client-0198.vpn.uni-bremen.de [134.102.107.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4N2g8q6X7FzDCcB; Wed, 2 Nov 2022 22:32:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <166627224606.10641.5749459667185024591@ietfa.amsl.com> Date: Wed, 2 Nov 2022 22:32:43 +0100 Cc: draft-ietf-httpapi-rfc7807bis@ietf.org, httpapi@ietf.org X-Mao-Original-Outgoing-Id: 689117563.566407-3ac5b6efec50735a5fdbaf1272653c83 Content-Transfer-Encoding: quoted-printable Message-Id: References: <166627224606.10641.5749459667185024591@ietfa.amsl.com> To: Last Call X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [httpapi] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2022 21:32:57 -0000 I reviewed draft-ietf-httpapi-rfc7807bis-04.txt mostly from an ART area point of view, although this is not be confused with the formal ARTART review. (Disclosure: The reviewer has contributed to RFC 9290, which is a mechanism inspired by RFC 7807, but specifically for constrained environments -- which has led to a few differences both in overall approach and in some details.) Gr=C3=BC=C3=9Fe, Carsten This update to RFC 7807 is a highly useful document, building and improving on the existing RFC 7807, and containing significant amounts of to-the-point implementation and usage advice. # Major: There seems to be an expectation that IANA will make https://iana.org/assignments/http-problem-types#foo resolvable. I'm not sure IANA is in a position to do this today. Section 5.2: The cited [RFC8126] Section 4.5 is "Expert Review", but the text says "Specification Required=E2=80=9D. # Minor: The specification is a bit wobbly on whether type URIs should be resolvable -- it explains the possibility, immediately explains an evolvability problem with non-resolvable type URIs, and then later has a SHOULD for being resolvable. Appendix A has a data definition for the JSON form in the current json-schema.org language version, but none in CDDL (RFC 8610). I propose adding the CDDL in the same spirit (informative definition), see PR#59 [2]. # Nits: -- 3.1.1: Non-resolvable URIs ought not be used when there is some future possibility that it might become desirable to do so. To this non-native speaker, "to do so" points nowhere (well, actually to using them, but that is a paradox then). What is probably meant is: Non-resolvable URIs ought not be used when there is some future possibility that it might become desirable to be able to resolve the URIs. Further nits (typos) are in PR#58 [1]. [1]: https://github.com/ietf-wg-httpapi/rfc7807bis/pull/58 [2]: https://github.com/ietf-wg-httpapi/rfc7807bis/pull/59