Hi Med, Thanks for your feedback.
On Mon, Jun 02, 2025 at 01:02:33PM +0000, [email protected] wrote: > De : Tom Harrison <[email protected]> >> We think that in the context of RIR Whois services, drawing a >> distinction between IPs and ASNs is reasonable, because although >> they are related to each other in a general sense, the category >> split is quite pronounced in Whois, and in RDAP as well. > > [Med] ACK. A minor change without disturbing what seems to be an > established practice would be then: > > OLD: IP- > NEW: IP address/prefix. > > That would be consistent with how these options are offered by, e.g., > > - IP Address or CIDR range > - ASN (Autonomous System Number or Autnum) > - Origin AS Updated: The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and ASNs, which are provided by RIRs via their Whois services, but for which there is no corresponding RDAP functionality. >>> # Extension & Version pattern >>> >>> CURRENT: >>> 'ips/rirSearch1/<relation>/<IP address>': Used to identify >>> an IP network search using a relation and an IP address to >>> match a set of IP networks. >>> >>> Why a version is used here but not for the other extensions defined in >>> this document? >> >> "rirSearch1" includes a "version number" to indicate that there may >> be a successor extension at some point in the future (extension >> identifiers in RDAP are opaque, but it's relatively common to >> include a number for this purpose). > > [Med] Can we then say explicitly in the text that this is about > version 1 of rirSearch in the text? Thanks. Updated: The "1" in "rirSearch1" denotes that this is version 1 of the RIR search extension. New versions of the RIR search extension will use different extension identifiers. >> The extension identifiers without version numbers (e.g. "ips") have >> that form so that they are consistent with the corresponding search >> URLs and result members that are defined in the base RDAP >> documents. > > [Med] I interpret this as there won't be successor extensions for > these. A note would be helpful because otherwise, it is not obvious > why distinct patterns are used for naming the extensions. Updated: The "1" in "rirSearch1" denotes that this is version 1 of the RIR search extension. New versions of the RIR search extension will use different extension identifiers. A version suffix is not used for the remaining identifiers defined by this document, partly because such a suffix would reduce consistency with the corresponding functionality for the other object classes, and partly because it is very unlikely that the functionality associated with those identifiers will change. >>> # Compliance with HTTP BCP (RFC9205) >>> >>> CURRENT: >>> server SHOULD respond with an HTTP 501 (Not Implemented) [RFC9110] >>> response code if it receives such a request. Server operators MAY >>> also opt not to support "status" filtering for values other than >>> "active" for the "rdap-up" and "rdap-top" link relations, in which >>> case the server SHOULD respond with an HTTP 501 (Not Implemented) >>> [RFC9110] response code if it receives such a request. >>> >>> via a lookup URL (see Section 3.1 of [RFC9082]). If there is no >>> result for the search, the server returns an HTTP 404 (Not Found) >>> [RFC9110] response code. >>> >>> The use of normative language is IMO not compliant with the guidance >>> in RFC9205 about error handling, especially this part: >>> >>> Applications using HTTP MUST NOT re-specify the semantics of HTTP >>> status codes, even if it is only by copying their definition. It is >>> NOT RECOMMENDED they require specific reason phrases to be used; >> >> Our reading of RFC 9205 is that the text in the document is OK, >> because it's mapping application errors to status codes, rather >> than trying to re-specify the semantics of those codes. From that >> document: >> >> ... applications using HTTP should define their errors to use >> the most applicable status code, making generous use of the >> general status codes (200, 400, and 500) when in doubt. >> >> Without defining that mapping, servers end up using different >> codes. > > [Med] I'm afraid that you do: " SHOULD respond with an HTTP 501 .." > is an example. We've attempted to address this feedback by relying on https://mailarchive.ietf.org/arch/msg/anima/qHRppN_6T3KBdsjOksxu8bw4byI/, where a similar issue was flagged in another document. If we've misinterpreted the requirements here, please let us know. Updated: By default, any valid status value may be used for status filtering. Server operators MAY opt not to support "status" filtering for the "rdap-down" and "rdap-bottom" link relations, in which case the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request. Server operators MAY also opt not to support "status" filtering for values other than "active" for the "rdap-up" and "rdap-top" link relations, in which case the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request. >> Also, just to avoid any doubt, although the document includes >> reason phrases, this is just for the benefit of the reader, rather >> than indicating that those phrases should be used as-is in the >> responses. > > [Med] Thanks for clarifying. Better to have this intent clarified in > the spec itself. Updated: Where this document includes HTTP reason phrases, that is purely for the benefit of the reader, and is not an indication that those phrases need to be used as-is in responses. -Tom _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
