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üße, 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”. # 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
