rfc-9877

Registration Data Access Protocol (RDAP) Extension for Geofeed Data

J. Singh, T. Harrison
date2025-10 streamIETF areaops wgregext statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc9877 doi10.17487/RFC9877
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses.

Extracted elements (21)

design-rationale §2.1

A new 'application/geofeed+csv' media type is preferred over 'text/csv' because the most common use case involves application processing (for IP address lookups) rather than direct user viewing, making an 'application' media type with 'geofeed' subtype more appropriate.

design-rationale §2.3

The extension identifier 'geofeed1' (with trailing '1') denotes version 1; new versions will use different identifiers. Servers may use the registered media type and link relation without the extension identifier, but including it signals to clients that the server hosts geofeed URLs so clients can infer absence of geofeed data when no link is returned.

interoperability-note §2.3

RDAP servers are free to use the 'application/geofeed+csv' media type and 'geofeed' link relation in standard responses without including the 'geofeed1' extension identifier, since servers may use any registered media type or link relation without implementing a particular extension.

interoperability-note §3

When an RDAP client performs an IP network lookup, the returned most-specific object may lack a geofeed link while a less-specific parent object has one. Clients should consider retrieving parent objects recursively if the initial response lacks geofeed data.

ip

normative-requirement §5 MUST

A geofeed file MUST be referenced with an HTTPS URL, per Section 6 of RFC 9632.

security

normative-requirement §2.3 MUST

A server that uses the 'geofeed1' extension identifier MUST include it in the 'rdapConformance' array for any lookup or search response containing an IP network object, as well as in the help response.

json

normative-requirement §2.2 SHOULD NOT

An IP network object MAY contain zero or more geofeed link objects. Typically it has zero or one; if multiple are returned (e.g., for multiple languages), the server SHOULD provide 'hreflang' members. Except for the multiple-languages scenario, the server SHOULD NOT return more than one geofeed link object.

json

normative-requirement §3 MUST

Clients who find a geofeed link object within an IP network object and retrieve the data MUST ignore any entry where the entry's IP address range is outside the IP network object's address range.

ip

normative-requirement §2.3 MUST

If the server includes 'geofeed1' in the 'rdapConformance' array, then for any response concerning an IP network object for which the server possesses a geofeed URL and is able to return it, the server MUST include a corresponding geofeed link object in the response.

json

normative-requirement §4 MUST

The service provider publishing a geofeed file MUST take care not to expose the location of any individual.

privacy

normative-requirement §2.2 RECOMMENDED

The 'type' JSON member in a geofeed link object is RECOMMENDED to be set to 'application/geofeed+csv'.

json

normative-requirement §3 MUST NOT

To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups.

privacy-consideration §4

All privacy considerations from Section 7 of RFC 9632 apply. Registry operators must ascertain whether regulations in their jurisdiction permit implementation of this functionality, given laws restricting use of 'personal data' as defined in RFC 6973.

privacy

protocol-element §2.2

A geofeed link object is added to the 'links' member of an IP network object in RDAP responses. It requires 'value', 'rel', and 'href' JSON members; the 'type' member is RECOMMENDED. The 'rel' is set to 'geofeed', 'href' to the HTTPS URL of the geofeed file, and 'type' to 'application/geofeed+csv'.

json

protocol-element §2.1

The 'application/geofeed+csv' media type is defined for geofeed files. The geofeed content is always UTF-8; the optional 'charset' parameter used by 'text/csv' is not used for this media type. The '+csv' structured syntax suffix is also registered.

json, registry

protocol-element §2.3

The 'geofeed1' RDAP extension identifier signals that a server hosts geofeed URLs for its IP network objects and includes geofeed link objects in responses. It is included in the 'rdapConformance' array of lookup, search, and help responses.

registry, json

registry §6.1

IANA has registered 'geofeed1' in the RDAP Extensions registry, with Registry Operator 'Any', describing version 1 of a method to access IP geolocation feed data through RDAP.

registry

registry §6.3

IANA has registered the 'application/geofeed+csv' media type in the Media Types registry, with no required parameters, UTF-8 encoding, and no known interoperability problems.

registry

registry §6.4

IANA has registered the '+csv' structured syntax suffix in the Structured Syntax Suffixes registry, with the same encoding, interoperability, and security considerations as 'text/csv'. Fragment identifier syntax and semantics SHOULD follow 'text/csv' rules.

registry

registry §6.2

IANA has registered the 'geofeed' link relation in the Link Relations registry, referring to a resource with IP geofeed location information related to the link context.

registry

security-consideration §5

Security considerations from Sections 6 and 9 of RFC 9632 apply equally in the RDAP context, including the requirement for HTTPS URLs and the option for RPKI signatures on geofeed files. No new security considerations beyond those in RFC 7481 and RFC 9560 are introduced.

security, crypto