RFC 9877: Registration Data Access Protocol (RDAP) Extension for Geofeed Data

2.1. Media Type for a Geofeed Link

[RFC9632] requires a geofeed file to be a UTF-8 [RFC3629] comma-separated values (CSV) file, with a series of "#" comments at the end for the optional Resource Public Key Infrastructure (RPKI) [RFC6480] signature. At first glance, the "text/csv" media type seems like a good candidate for a geofeed file, since it supports the "#" comments needed for including the RPKI signature.¶

However, although the CSV geofeed data could be viewed directly by a user such that the "text/csv" media type was appropriate, the most common use case will involve it being processed by some sort of application first, in order to facilitate subsequent IP address lookup operations. Therefore, using a new "application" media type with a "geofeed" subtype (Section 4.2.5 of [RFC6838]) for the geofeed data is preferable to using "text/csv".¶

To that end, this document registers a new "application/geofeed+csv" media type in the IANA "Media Types" registry (see Section 6.3), and a new "+csv" suffix in the IANA "Structured Syntax Suffixes" registry (see Section 6.4).¶

2.2. Geofeed Link

An RDAP server that hosts geofeed URLs for its IP network objects (Section 5.4 of [RFC9083]) may include link objects for those geofeed URLs in IP network objects in its responses. These link objects are added to the "links" member of each object (Section 4.2 of [RFC9083]).¶

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. The geofeed-specific components of a link object are like so:¶

"rel":

The link relation type is set to "geofeed". This is a new link relation type for IP geolocation feed data, registered in the IANA "Link Relations" registry (see Section 6.2) by this document.¶

"href":

The target URL is set to the HTTPS URL of the geofeed file (Section 6 of [RFC9632]) for an IP network.¶

"type":

"application/geofeed+csv" (see Section 2.1).¶

An IP network object returned by an RDAP server MAY contain zero or more geofeed link objects, though typically an IP network will have either zero or only one. The scenario where more than one geofeed link object could be returned is when the server is able to represent that data in multiple languages. In such a case, the server SHOULD provide "hreflang" members for the geofeed link objects. Except for the multiple-languages scenario, the server SHOULD NOT return more than one geofeed link object.¶

2.3. Extension Identifier

This document defines a new extension identifier, "geofeed1", for use by servers that host geofeed URLs for their IP network objects and include geofeed URL link objects in their responses to clients in accordance with Section 2.2. A server that uses this extension identifier MUST include it in the "rdapConformance" array (Section 4.1 of [RFC9083]) for any lookup or search response containing an IP network object, as well as in the help response. Here is an elided example of this inclusion:¶

{
    "rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
    ...
}

If the server includes "geofeed1" in the "rdapConformance" array, then for any response concerning a particular IP network object for which the server possesses a geofeed URL and is able to return it to the client (i.e., the server is not compelled to omit it due to regulatory constraints or similar), the server MUST include a corresponding geofeed link object in the response.¶

An RDAP server may make use of the "application/geofeed+csv" media type and the "geofeed" link relation defined in this specification in its responses without including the "geofeed1" extension identifier in those responses, because RDAP servers are free to use any registered media type or link relation in a standard response without implementing any particular extension. The additional value of including the extension identifier in the "rdapConformance" array is that it signals to the client that the server hosts geofeed URLs for its IP network objects. This is useful where a client receives an IP network object without a geofeed link object, because in that case the client can infer that no geofeed data is available for that object, since the server would have provided it if it were available.¶

Although a server may use registered media types in its link objects without any restrictions, it is 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. This is what the server does with the "geofeed1" extension identifier.¶

The "1" in "geofeed1" denotes that this is version 1 of the geofeed extension. New versions of the geofeed extension will use different extension identifiers.¶

2.4. Example

The following is an elided example of an IP network object with a geofeed link object:¶

{
    "objectClassName": "ip network",
    "handle": "XXXX-RIR",
    "startAddress": "2001:db8::",
    "endAddress": "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
    "ipVersion": "v6",
    "name": "NET-RTR-1",
    "type": "DIRECT ALLOCATION",
    "country": "AU",
    "parentHandle": "YYYY-RIR",
    "status": [ "active" ],
    "links":
     [
        {
            "value": "https://example.net/ip/2001:db8::/48",
            "rel": "self",
            "href": "https://example.net/ip/2001:db8::/48",
            "type": "application/rdap+json"
        },
        {
            "value": "https://example.net/ip/2001:db8::/48",
            "rel": "geofeed",
            "href": "https://example.com/geofeed",
            "type": "application/geofeed+csv"
        },
        ...
    ],
    ...
}

6.1. RDAP Extensions Registry

IANA has registered the following value in the "RDAP Extensions" registry at [RDAP-EXTENSIONS]:¶

Extension Identifier:

geofeed1¶

Registry Operator:

Any¶

Specification:

RFC 9877¶

Contact:

IETF <iesg@ietf.org>¶

Intended Usage:

This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.¶

6.2. Link Relations Registry

IANA has registered the following value in the "Link Relations" registry at [LINK-RELATIONS]:¶

Relation Name:

geofeed¶

Description:

Refers to a resource with IP geofeed location information related to the link context.¶

Reference:

RFC 9877¶

6.3. Media Types Registry

IANA has registered the following media type in the "Media Types" registry at [MEDIA-TYPES]:¶

Type name:

application¶

Subtype name:

geofeed+csv¶

Required parameters:

N/A¶

Optional parameters:

"charset" is an optional parameter for "text/csv", but it is not used for "application/geofeed+csv" because the geofeed content is always in UTF-8 (Section 2.1 of [RFC8805]).¶

Encoding considerations:

See Section 2 of [RFC9632].¶

Security considerations:

See Section 5 of RFC 9877.¶

Interoperability considerations:

There are no known interoperability problems regarding this media format.¶

Published specification:

RFC 9877.¶

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 [REGEXT].¶

Person & email address to contact for further information:

REGEXT Working Group <regext@ietf.org>¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Authors:

Tom Harrison, Jasdip Singh¶

Author/Change controller:

IETF¶

6.4. Structured Syntax Suffixes Registry

IANA has registered the following value in the "Structured Syntax Suffixes" registry at [STRUCTURED-SYNTAX-SUFFIXES]:¶

Name:

Comma-Separated Values (CSV)¶

+suffix:

+csv¶

References:

[RFC4180], [RFC7111]¶

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 for +csv.¶
• For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified for "xxx/⁠yyy+csv".¶
• For cases not defined in +csv, then as specified for "xxx/⁠yyy+csv".¶

Security Considerations:

Same as "text/csv".¶

Contact:

IETF <iesg@ietf.org>¶

Author/Change controller:

IETF¶