An RDAP Extension for Geofeed Data

Introduction and (obsoletes ) detail the IP geolocation feed (in short, geofeed) concept. This document specifies how the geofeed data can be accessed through RDAP. It defines a new RDAP extension "geofeed1" for including a geofeed file URL in an IP Network object.

Requirements Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol. "..." in examples is used as shorthand for elements defined outside of this document.

Specification

Extension A new RDAP extension "geofeed1" is defined for accessing the geofeed data through RDAP. It updates the IP Network object class definition () to include a new link object for the geofeed file URL in its "links" array (). An RDAP server conforming to this specification MUST include the "geofeed1" extension string in the "rdapConformance" array for any lookup or search response containing an IP Network object, as well as in the help response. Here is an elided example for this inclusion:

Geofeed Link The IP Network object class () MAY include a link object for the geofeed file URL (also referred to as a Geofeed link object) in its "links" array (). In RDAP, the "value", "rel", and "href" JSON members are REQUIRED for any link object. Additionally, for a Geofeed link object, the "type" JSON member is RECOMMENDED. Pertinent details of a Geofeed link object:

"rel" -- The link relation type is set to the "geo" string. The "geo" link relation type is new and will be registered in the IANA Link Relations Registry (see ).
"href" -- The target URI is set to the HTTPS URL of the geofeed file for an IP network.
"type" -- See for acceptable "type" values.

There MAY be zero or more Geofeed link objects in the "links" array of an IP Network object. Further, more than one Geofeed link object is allowed in case a geofeed file target needs to be represented in multiple formats and/or languages.

Media Type for a Geofeed Link requires a geofeed file to be a UTF-8 CSV file, with a series of "#" comments at the end for the optional RPKI (Resource Public Key Infrastructure) signature. At first glance, the "text/csv" media type () seems like a good candidate to represent a geofeed file since it now supports the "#" comments needed for including the RPKI signature. However, although the CSV geofeed data could be directly viewed by a user, the most common use case will involve it being processed by some sort of application first, in order to facilitate subsequent address lookup operations. Therefore, using a new “application” media type with a “geofeed” subtype under the "application" top-level type () for the geofeed data is preferable over the existing "text/csv" media type. To that end, a new media type "application/geofeed+csv" will be registered in the IANA Media Types Registry (see ), and a new suffix "+csv" will be registered in the IANA Structured Syntax Suffixes Registry (see ). The "type" JSON value in a Geofeed link object SHOULD be set to the "application/geofeed+csv" media type. A server that includes the "geofeed1" extension identifier in its responses is indicating that by way of its responses, it will provide access to geofeed data at a target site, in accordance with the text of this document. However, this document does not restrict the use of other media types that relate to geographic information, nor the use of link objects more generally. Although a server may use registered media types in its link objects without any restrictions, it may be useful to define new RDAP extensions for those media types in order for the server to communicate to clients that it will make data for that type accessible, in the same way that the server does with the "geofeed1" extension identifier.

Example The following is an elided example of an IP Network object with a Geofeed link object:

Privacy Considerations When including a geofeed file URL in an IP Network object, an RDAP server operator SHOULD follow the guidance from to not accidentally expose the location of an individual.

Security Considerations requires an HTTPS URL for a geofeed file, and optionally RPKI-signing the data within. Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications.

IANA Considerations

RDAP Extensions Registry IANA is requested to register the following value in the RDAP Extensions Registry at https://www.iana.org/assignments/rdap-extensions/:

Extension identifier: geofeed1
Registry operator: Any
Published specification: This document.
Contact: IETF iesg@ietf.org
Intended usage: This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.

Link Relations Registry IANA is requested to register the following value in the Link Relations Registry at https://www.iana.org/assignments/link-relations/:

Relation Name: geo
Description: Indicates that the link context has a resource with geographic information at the link target.
Reference: This document.

Media Types Registry IANA is requested to register the following value in the Media Types Registry at https://www.iana.org/assignments/media-types/:

Type name: application
Subtype name: geofeed+csv
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: See .
Security considerations: See of this document.
Interoperability considerations: There are no known interoperability problems regarding this media format.
Published specification: This document.
Applications that use this media type: Implementations of the Registration Data Access Protocol (RDAP) Extension for Geofeed Data. Furthermore, any application that processes the CSV geofeed data.
Additional information: This media type is a product of the IETF REGEXT Working Group. The REGEXT charter, information on the REGEXT mailing list, and other documents produced by the REGEXT Working Group can be found at https://datatracker.ietf.org/wg/regext/.
Person & email address to contact for further information: IETF iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: None
Authors: Tom Harrison, Jasdip Singh
Change controller: IETF
Provisional Registration: No

Structured Syntax Suffixes Registry IANA is requested to register the following value in the Structured Syntax Suffixes Registry at https://www.iana.org/assignments/media-type-structured-suffix/:

Name: Comma-Separated Values (CSV)
+suffix: +csv
References: ,
Encoding Considerations: Same as "text/csv".
Interoperability Considerations: Same as "text/csv".
Fragment Identifier Considerations:

The syntax and semantics of fragment identifiers specified for +csv SHOULD be as specified for "text/csv". The syntax and semantics for fragment identifiers for a specific "xxx/yyy+csv" SHOULD be processed as follows: For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified in +csv. For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified in "xxx/yyy+csv". For cases not defined in +csv, then as specified in "xxx/yyy+csv".

Security Considerations: Same as "text/csv".
Contact: IETF iesg@ietf.org

Acknowledgements Mark Kosters provided initial support and encouragement for this work, along with the authors. Gavin Brown suggested using a web link instead of a simple URI string to specify a geofeed file URL. Andy Newton, James Gould, and Scott Hollenbeck also provided valuable feedback for this document.

Change History

Changes from 00 to 01

Now using a web link instead of a simple URI string to specify a geofeed file URL.
Renamed the extension as "geofeed1" instead of "geofeedv1".
Introduced the new "geo" link relation type.
Introduced the new "application/geofeed+csv" media type.

Changes from 01 to 02

Updated the "Requirements Language" section for examples.
Added an example for RDAP conformance.
Updated the rationale for using the new "application/geofeed+csv" media type.
Updated the "Applications that use this media type" section for the "application/geofeed+csv" registration.

Changes from 02 to 03

Removed "value" and "hreflang" explanations from the "Geofeed Link" section. Further, clarified the cardinality of Geofeed link objects.
Updated extensibility verbiage in the "Media Type for a Geofeed Link" section.
In the "Example" section, updated the domain in "href" of the Geofeed link object to contrast with the domain in "value" to highlight that "href" is for a geofeed file hosted at a network operator site whereas "value" is for an IP network object from an RDAP server.
Removed the "Redaction" section since the geofeed files are public to start with.
Added URLs for various IANA registries.

Changes from 03 to 04

Updated the criteria for including the extension identifier in "rdapConformance".