Internet Engineering Task Force (IETF) J. Singh
Request for Comments: 9877 ARIN
Category: Standards Track T. Harrison
ISSN: 2070-1721 APNIC
October 2025
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.
このドキュメントでは、RDAP サーバーがその IP ネットワーク オブジェクトのジオフィード URL をホストしていることを示すための、新しい RDAP (Registration Data Access Protocol) 拡張機能「geofeed1」を定義します。また、応答に含まれる関連リンク オブジェクトの新しいメディア タイプと新しいリンク関係タイプも定義します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9877.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9877 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Specification
2.1. Media Type for a Geofeed Link
2.2. Geofeed Link
2.3. Extension Identifier
2.4. Example
3. Operational Considerations
4. Privacy Considerations
5. Security Considerations
6. IANA Considerations
6.1. RDAP Extensions Registry
6.2. Link Relations Registry
6.3. Media Types Registry
6.4. Structured Syntax Suffixes Registry
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
[RFC8805] and [RFC9632] detail the IP geolocation feed (commonly known as 'geofeed') file format and associated access mechanisms. While [RFC9632] describes how a registry can make geofeed URLs available by way of a Routing Policy Specification Language (RPSL) [RFC2622] service, the Regional Internet Registries (RIRs) have deployed Registration Data Access Protocol (RDAP) ([RFC7480], [RFC7481], [RFC9082], [RFC9083]) services as successors to RPSL for Internet number resource registrations, and maintaining feature parity between the two services supports client transition from RPSL to RDAP in this context. To that end, this document specifies how geofeed URLs can be accessed through RDAP. It defines a new RDAP extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects, as well as a new media type and a new link relation type for the associated link objects.
[RFC8805] および [RFC9632] では、IP 地理位置情報フィード (一般に「ジオフィード」として知られる) ファイル形式と関連するアクセス メカニズムについて詳しく説明しています。[RFC9632] では、レジストリがルーティング ポリシー仕様言語 (RPSL) [RFC2622] サービスを通じてジオフィード URL を利用可能にする方法について説明していますが、地域インターネット レジストリ (RIR) は登録データ アクセス プロトコル (RDAP) ([RFC7480]、[RFC7481]、[RFC9082]、
[RFC9083]) はインターネット番号リソース登録用の RPSL の後継サービスとして機能し、2 つのサービス間の機能パリティを維持することで、このコンテキストでの RPSL から RDAP へのクライアントの移行がサポートされます。そのために、このドキュメントでは、RDAP を介してジオフィード URL にアクセスする方法を指定します。これは、RDAP サーバーがその IP ネットワーク オブジェクトのジオフィード URL をホストすることを示すための新しい RDAP 拡張子「geofeed1」と、関連するリンク オブジェクトの新しいメディア タイプと新しいリンク関係タイプを定義します。
Fetching and making use of geofeed data is out of scope for the purposes of this document. See [RFC8805] and [RFC9632] for further details.
ジオフィード データの取得と使用は、このドキュメントの目的の範囲外です。詳細については、[RFC8805] および [RFC9632] を参照してください。
The key words "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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Indentation and whitespace in examples are provided only to illustrate element relationships and are not required features of this specification.
例におけるインデントと空白は、要素の関係を説明するためにのみ提供されており、この仕様の必須の機能ではありません。
"..." in examples is used as shorthand for elements defined outside of this document.
例中の「...」は、このドキュメントの外で定義された要素の短縮形として使用されています。
[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.
[RFC9632] では、ジオフィード ファイルが UTF-8 [RFC3629] カンマ区切り値 (CSV) ファイルであり、オプションのリソース公開鍵基盤 (RPKI) [RFC6480] 署名の最後に一連の「#」コメントが付いている必要があります。一見すると、「text/csv」メディア タイプは、RPKI 署名を含めるのに必要な「#」コメントをサポートしているため、ジオフィード ファイルの適切な候補のように見えます。
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".
ただし、CSV ジオフィード データは、「text/csv」メディア タイプが適切であればユーザーが直接表示できますが、最も一般的な使用例では、後続の IP アドレス検索操作を容易にするために、最初に何らかのアプリケーションによって処理されます。したがって、ジオフィード データには、「text/csv」を使用するよりも、「geofeed」サブタイプ ([RFC6838] のセクション 4.2.5) を持つ新しい「application」メディア タイプを使用することをお勧めします。
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).
そのために、この文書は、IANA「Media Types」レジストリ (セクション 6.3 を参照) に新しい「application/geofeed+csv」メディア タイプを登録し、IANA「Structured Syntax Suffixes」レジストリ (セクション 6.4 を参照) に新しい「+csv」サフィックスを登録します。
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]).
IP ネットワーク オブジェクトのジオフィード URL をホストする RDAP サーバー ([RFC9083] のセクション 5.4) は、その応答内の IP ネットワーク オブジェクトにそれらのジオフィード URL のリンク オブジェクトを含めることがあります。これらのリンク オブジェクトは、各オブジェクトの "links" メンバーに追加されます ([RFC9083] のセクション 4.2)。
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:
RDAP では、すべてのリンク オブジェクトに「value」、「rel」、「href」の JSON メンバーが必要です。さらに、ジオフィード リンク オブジェクトの場合、「type」JSON メンバーが推奨されます。リンク オブジェクトのジオフィード固有のコンポーネントは次のようになります。
"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.
リンク関係タイプは「ジオフィード」に設定されます。これは、IP 地理位置情報フィード データの新しいリンク関係タイプであり、この文書によって IANA "Link Relations" レジストリ (セクション 6.2 を参照) に登録されます。
"href":
"href":
The target URL is set to the HTTPS URL of the geofeed file (Section 6 of [RFC9632]) for an IP network.
ターゲット URL は、IP ネットワークのジオフィード ファイル ([RFC9632] のセクション 6) の HTTPS URL に設定されます。
"type":
"タイプ"：
"application/geofeed+csv" (see Section 2.1).
「application/geofeed+csv」 (セクション 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.
RDAP サーバーから返される IP ネットワーク オブジェクトには、ジオフィード リンク オブジェクトが 0 個以上含まれていても構いません (MAY)。ただし、通常、IP ネットワークには 0 個または 1 個だけ含まれます。複数のジオフィード リンク オブジェクトが返されるシナリオは、サーバーがそのデータを複数の言語で表現できる場合です。このような場合、サーバーはジオフィード リンク オブジェクトに「hreflang」メンバーを提供する必要があります (SHOULD)。複数言語のシナリオを除き、サーバーは複数のジオフィード リンク オブジェクトを返してはなりません (SHOULD NOT)。
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:
この文書は、IP ネットワーク オブジェクトのジオフィード URL をホストし、セクション 2.2 に従ってクライアントへの応答にジオフィード URL リンク オブジェクトを含めるサーバーが使用する新しい拡張識別子「geofeed1」を定義します。この拡張識別子を使用するサーバーは、ヘルプ応答だけでなく、IP ネットワーク オブジェクトを含むルックアップまたは検索応答の「rdapConformance」配列 ([RFC9083] のセクション 4.1) にそれを含めなければなりません (MUST)。この包含の省略された例を次に示します。
{
"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.
サーバーが「rdapConformance」配列に「geofeed1」を含む場合、サーバーがジオフィード URL を所有し、それをクライアントに返すことができる (つまり、サーバーは規制上の制約などによりそれを省略することを強制されない) 特定の IP ネットワーク オブジェクトに関する応答について、サーバーは対応するジオフィード リンク オブジェクトを応答に含めなければなりません (MUST)。
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.
RDAP サーバーは、特定の拡張機能を実装せずに、標準応答で登録されているメディア タイプまたはリンク関係を自由に使用できるため、応答に「geofeed1」拡張識別子を含めずに、この仕様で定義されている「application/geofeed+csv」メディア タイプと「geofeed」リンク関係を応答で使用できます。「rdapConformance」配列に拡張識別子を含めることの追加の価値は、サーバーがその IP ネットワーク オブジェクトのジオフィード URL をホストしていることをクライアントに通知することです。これは、クライアントがジオフィード リンク オブジェクトなしで IP ネットワーク オブジェクトを受信する場合に便利です。その場合、クライアントは、そのオブジェクトに利用できるジオフィード データが存在しないと推測できます (利用可能な場合はサーバーが提供するため)。
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.
サーバーはリンク オブジェクトで登録されたメディア タイプを制限なく使用できますが、サーバーがそのタイプのデータにアクセスできるようにすることをクライアントに伝えるために、それらのメディア タイプに新しい RDAP 拡張機能を定義すると便利です。これは、サーバーが「geofeed1」拡張識別子を使用して行うことです。
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.
「geofeed1」の「1」は、これがジオフィード拡張機能のバージョン 1 であることを示します。ジオフィード拡張機能の新しいバージョンでは、異なる拡張機能識別子が使用されます。
The following is an elided example of an IP network object with a geofeed link object:
以下は、ジオフィード リンク オブジェクトを含む IP ネットワーク オブジェクトの省略された例です。
{
"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"
},
...
],
...
}
When an RDAP client performs an IP network lookup, per Section 3.1.1 of [RFC9082], the RDAP server is required to return the most-specific IP network object that covers the IP address range provided by the client. That IP network object may not have an associated geofeed link, but it is possible that a less-specific IP network object does have such a link. Clients attempting to retrieve geofeed data for a given IP address range via RDAP should consider whether to retrieve the parent object for the initial response (and so on, recursively) in the event that the initial response does not contain geofeed data. Conversely, server operators should consider interface options for resource holders in order to support the provisioning of geofeed links for all networks covered by the associated data.
[RFC9082] のセクション 3.1.1 に従って、RDAP クライアントが IP ネットワーク ルックアップを実行する場合、RDAP サーバーは、クライアントが提供する IP アドレス範囲をカバーする最も具体的な IP ネットワーク オブジェクトを返す必要があります。その IP ネットワーク オブジェクトには関連付けられたジオフィード リンクがない可能性がありますが、より限定的でない IP ネットワーク オブジェクトにはそのようなリンクがある可能性があります。RDAP 経由で特定の IP アドレス範囲のジオフィード データを取得しようとするクライアントは、初期応答にジオフィード データが含まれていない場合に、初期応答の親オブジェクトを (再帰的に) 取得するかどうかを検討する必要があります。逆に、サーバー オペレーターは、関連データがカバーするすべてのネットワークへのジオフィード リンクのプロビジョニングをサポートするために、リソース ホルダー向けのインターフェイス オプションを検討する必要があります。
It is common for a resource holder to maintain a single geofeed file containing the geofeed data for all of their resources. The resource holder then updates each of their network object registrations to refer to that single geofeed file. As with geofeed references in inetnum: objects (per [RFC9632]), clients who find a geofeed link object within an IP network object and opt to retrieve the data from the associated link MUST ignore any entry where the entry's IP address range is outside the IP network object's address range.
リソース所有者は、すべてのリソースのジオフィード データを含む単一のジオフィード ファイルを管理するのが一般的です。次に、リソース ホルダーは、その単一のジオフィード ファイルを参照するように各ネットワーク オブジェクトの登録を更新します。inetnum:objects のジオフィード参照 ([RFC9632] による) と同様に、IP ネットワーク オブジェクト内でジオフィード リンク オブジェクトを見つけ、関連付けられたリンクからデータを取得することを選択したクライアントは、エントリの IP アドレス範囲が IP ネットワーク オブジェクトのアドレス範囲外にあるエントリをすべて無視しなければなりません (MUST)。
Section 3.2 of [RFC8805] recommends that consumers of geofeed data verify that the publisher of the data is authoritative for the relevant resources. The RDAP bootstrap process [RFC9224] helps clients with this recommendation, since a client following that process will be directed to the RDAP server that is able to make authoritative statements about the disposition of the relevant resources.
[RFC8805] のセクション 3.2 は、ジオフィード データの利用者が、データの発行者が関連するリソースに対して権限があることを確認することを推奨しています。RDAP ブートストラップ プロセス [RFC9224] は、クライアントがこの推奨事項を実行するのに役立ちます。そのプロセスに従うクライアントは、関連リソースの処分について権限のあるステートメントを作成できる RDAP サーバーに誘導されるからです。
To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups. See Section 6 of [RFC9632] for further details.
RDAP およびジオフィード サーバーへの過度の負荷を防ぐために、これらのメカニズムを使用してジオフィード データを取得するクライアントは、頻繁にリアルタイム ルックアップを実行してはなりません (MUST NOT)。詳細については、[RFC9632] のセクション 6 を参照してください。
All the privacy considerations from Section 7 of [RFC9632] apply to this document. In particular, the service provider publishing the geofeed file MUST take care not to expose the location of any individual.
[RFC9632] のセクション 7 のプライバシーに関するすべての考慮事項がこの文書に適用されます。特に、ジオフィード ファイルを公開するサービス プロバイダーは、個人の位置が公開されないよう注意しなければなりません。
Many jurisdictions have laws or regulations that restrict the use of "personal data", per the definition in [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.
多くの法域には、[RFC6973] の定義に従って「個人データ」の使用を制限する法律または規制があります。そのため、レジストリ オペレータは、自らが運用する規制環境がこの文書で定義されている機能の実装を許可しているかどうかを確認する必要があります。
Sections 6 and 9 of [RFC9632] document several security considerations that are equally relevant in the RDAP context.
[RFC9632] のセクション 6 と 9 では、RDAP コンテキストにも同様に関連するいくつかのセキュリティに関する考慮事項が文書化されています。
A geofeed file MUST be referenced with an HTTPS URL, per Section 6 of [RFC9632]. The geofeed file may also contain an RPKI signature, per Section 5 of [RFC9632].
[RFC9632] のセクション 6 に従って、ジオフィード ファイルは HTTPS URL で参照されなければなりません (MUST)。[RFC9632] のセクション 5 に従って、ジオフィード ファイルには RPKI 署名が含まれる場合もあります。
Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications ([RFC7481], [RFC9560]).
それに加えて、この文書では、RDAP プロトコル仕様 ([RFC7481]、[RFC9560]) で既に議論されているセキュリティ上の考慮事項を超える新しいセキュリティ考慮事項は導入されません。
IANA has registered the following value in the "RDAP Extensions" registry at [RDAP-EXTENSIONS]:
IANA は、[RDAP-EXTENSIONS] の「RDAP Extensions」レジストリに次の値を登録しました。
Extension Identifier:
拡張機能の識別子:
geofeed1
ジオフィード1
Registry Operator:
レジストリオペレーター:
Any
どれでも
Specification:
仕様：
RFC 9877
RFC 9877
Contact:
接触：
IETF <iesg@ietf.org>
IETF <iesg@ietf.org>
Intended Usage:
使用目的:
This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.
この拡張機能は、RDAP を通じて IP 地理位置情報フィード データにアクセスする方法のバージョン 1 について説明します。
IANA has registered the following value in the "Link Relations" registry at [LINK-RELATIONS]:
IANA は、[LINK-RELATIONS] の「Link Relations」レジストリに次の値を登録しました。
Relation Name:
関係名:
geofeed
ジオフィード
Description:
説明：
Refers to a resource with IP geofeed location information related to the link context.
リンク コンテキストに関連する IP ジオフィード位置情報を持つリソースを指します。
Reference:
参照：
RFC 9877
RFC 9877
IANA has registered the following media type in the "Media Types" registry at [MEDIA-TYPES]:
IANA は、[MEDIA-TYPES] の「メディア タイプ」レジストリに次のメディア タイプを登録しました。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
geofeed+csv
ジオフィード+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]).
「charset」は「text/ csv」のオプションのパラメータですが、ジオフィードのコンテンツは常に UTF-8 であるため、「application/geofeed+csv」には使用されません ([RFC8805] のセクション 2.1)。
Encoding considerations:
エンコーディングに関する考慮事項:
See Section 2 of [RFC9632].
[RFC9632] のセクション 2 を参照してください。
Security considerations:
セキュリティに関する考慮事項:
See Section 5 of RFC 9877.
RFC 9877 のセクション 5 を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
There are no known interoperability problems regarding this media format.
このメディア形式に関する既知の相互運用性の問題はありません。
Published specification:
公開された仕様:
RFC 9877.
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.
ジオフィード データ用の登録データ アクセス プロトコル (RDAP) 拡張機能の実装。さらに、CSV ジオフィード データを処理するアプリケーション。
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].
このメディア タイプは、IETF REGEXT Working Group の製品です。REGEXT 憲章、REGEXT メーリング リストに関する情報、および REGEXT ワーキング グループによって作成されたその他の文書は、[REGEXT] で見つけることができます。
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
REGEXT Working Group <regext@ietf.org>
REGEX ワーキング グループ <regex@ietf.org>
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
None
なし
Authors:
著者:
Tom Harrison, Jasdip Singh
トム・ハリソン、ジャスディップ・シン
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
IANA has registered the following value in the "Structured Syntax Suffixes" registry at [STRUCTURED-SYNTAX-SUFFIXES]:
IANA は、[STRUCTURED-SYNTAX-SUFFIXES] の「構造化構文接尾辞」レジストリに次の値を登録しました。
Name:
名前：
Comma-Separated Values (CSV)
カンマ区切り値 (CSV)
+suffix:
+接尾辞:
+csv
+CSV
References:
参考文献:
[RFC4180], [RFC7111]
[RFC4180]、[RFC7111]
Encoding Considerations:
エンコーディングに関する考慮事項:
Same as "text/csv".
「テキスト/csv」と同じです。
Interoperability Considerations:
相互運用性に関する考慮事項:
Same as "text/csv".
「テキスト/csv」と同じです。
Fragment Identifier Considerations:
フラグメント識別子の考慮事項:
The syntax and semantics of fragment identifiers specified for +csv SHOULD be as specified for "text/csv".
+csv に指定されたフラグメント識別子の構文とセマンティクスは、「text/csv」に指定されたものと同じである必要があります (SHOULD)。
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+csv" SHOULD be processed as follows:
特定の「xxx/yyy+csv」のフラグメント識別子の構文とセマンティクスは、次のように処理される必要があります。
* For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified for +csv.
* +csv で定義されている場合、フラグメント識別子は +csv ルールに従って解決され、+csv で指定されたとおりになります。
* For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified for "xxx/yyy+csv".
* +csv で定義されている場合、フラグメント識別子が +csv ルールに従って解決されない場合は、「xxx/yyy+csv」に指定されているとおりになります。
* For cases not defined in +csv, then as specified for "xxx/yyy+csv".
* +csv で定義されていない場合は、「xxx/yyy+csv」の指定に従います。
Security Considerations:
セキュリティに関する考慮事項:
Same as "text/csv".
「テキスト/csv」と同じです。
Contact:
接触：
IETF <iesg@ietf.org>
IETF <iesg@ietf.org>
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley,
"Finding and Using Geofeed Data", RFC 9632,
DOI 10.17487/RFC9632, August 2024,
<https://www.rfc-editor.org/info/rfc9632>.
[LINK-RELATIONS]
IANA, "Link Relations",
<https://www.iana.org/assignments/link-relations/>.
[MEDIA-TYPES]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types/>.
[RDAP-EXTENSIONS]
IANA, "RDAP Extensions",
<https://www.iana.org/assignments/rdap-extensions/>.
[REGEXT] IETF, "Registration Protocols Extensions (regext)",
<https://datatracker.ietf.org/wg/regext/>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment
Identifiers for the text/csv Media Type", RFC 7111,
DOI 10.17487/RFC7111, January 2014,
<https://www.rfc-editor.org/info/rfc7111>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>.
[RFC9560] Hollenbeck, S., "Federated Authentication for the
Registration Data Access Protocol (RDAP) Using OpenID
Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
<https://www.rfc-editor.org/info/rfc9560>.
[STRUCTURED-SYNTAX-SUFFIXES]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix/>.
Mark Kosters provided initial support and encouragement for this work, along with the authors of [RFC9632]. Gavin Brown suggested using a web link instead of a simple URL string to specify a geofeed file URL. Andy Newton, James Gould, Scott Hollenbeck, Mario Loffredo, Orie Steele, Alexey Melnikov, Mark Nottingham, Rifaat Shekh-Yusef, Dale R. Worley, Dhruv Dhody, Mohamed Boucadair, Mahesh Jethanandani, Ketan Talaulikar, and Éric Vyncke provided valuable feedback for this document.
Mark Kosters は、[RFC9632] の著者とともに、この研究に対して初期のサポートと奨励を提供しました。Gavin Brown さんは、単純な URL 文字列の代わりに Web リンクを使用してジオフィード ファイルの URL を指定することを提案しました。Andy Newton、James Gould、Scott Hollenbeck、Mario Loffredo、Orie Steele、Alexey Melnikov、Mark Nottingham、Rifat Shekh-Yusef、Dale R. Worley、Dhruv Dhody、Mohamed Boucadair、Mahesh Jethanandani、Ketan Talaulikar、および Éric Vyncke から、この文書に対して貴重なフィードバックを提供していただきました。
Jasdip Singh
ARIN
Email: jasdips@arin.net
Tom Harrison
APNIC
Email: tomh@apnic.net