[要約] RFC 8917は、LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) アプリケーションサービスタグに関するもので、位置情報に基づくサービスルーティングの検証を目的としています。この規格は、緊急通信やその他のサービスでの利用を想定しており、効率的なルーティングとサービスの検証を可能にします。
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8917 Core Technology Consulting
Updates: 5222 B. Rosen
Category: Standards Track October 2020
ISSN: 2070-1721
The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
失われた検証の直接的な命名権限ポインタ（S-NAPTR）アプリケーションサービスタグ
Abstract
概要
This document adds the 'LoST-Validation' service tag to the Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifying LoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.
このドキュメントでは、「失われた検証」サービスタグを「S-NAPTR）アプリケーションサービス」サービスタグIANAレジストリに追加します。このタグは、ロケーション検証のために指定された紛失したサーバーを識別する際に、場所間変換（失われた）プロトコルのクライアントを支援するために、ネーミング権限ポインタ（NAPTR）ドメインネームシステム（DNS）レコードに表示できます。このタグとその使用頻度の検証をサポートするサーバーの明示的な検出を可能にするRFC 5222についての情報を使用します。
Status of This Memo
本文書の状態
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8917.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8917で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Document Scope 2. Introduction 2.1. Requirements Language 3. The LoST-Validation Application Service Tag 4. Backwards Compatibility 5. Security Considerations 6. IANA Considerations 6.1. S-NAPTR Registration 7. References 7.1. Normative References 7.2. Informative References Acknowledgements Authors' Addresses
1. 文書範囲2.はじめに2.1。要件言語3.失われた検証アプリケーションサービスタグ4.下位互換性5.セキュリティ上の考慮事項6. IANAの考慮事項6.1。S-NAPTR登録7.参考文献7.1。規範的参考文献7.2。有益な参照承認著者の住所
This document adds 'LoST-Validation' to the S-NAPTR Application Service Tag IANA registry and describes how this tag fits in the LoST server discovery procedure described in [RFC5222]. This tag is used with Naming Authority Pointer (NAPTR) Domain Name System (DNS) records so that clients of the Location-to-Service Translation (LoST) Protocol [RFC5222] can identify servers designated for location validation. This tag and the information on its use is an update to [RFC5222] that enables the explicit discovery of a server that supports location validation.
このドキュメントでは、S-NAPTRアプリケーションサービスタグIANAレジストリに「失われた検証」を追加し、[RFC5222]に記載されているLost Server検出手順にこのタグがどのように適合しているかを説明します。このタグは、命名権限ポインタ（NAPTR）ドメインネームシステム（DNS）レコード（RFC5222]のクライアントが位置検証用に指定されたサーバーを識別できるように、名前を付けます。このタグとその使用に関する情報は、位置検証をサポートするサーバーの明示的な検出を可能にする[RFC5222]の更新です。
The LoST Protocol [RFC5222] defines a mapping service with the additional ability for a client to request that a civic address be validated. The LoST protocol allows servers to ignore a request to perform location validation. The National Emergency Number Association (NENA) has defined an architecture for all-IP emergency services (known as "i3" [NENA-i3]), which defines the mapping (routing) and validation functions as two distinct functional elements, defined as an Emergency Call Routing Function (ECRF) and a Location Validation Function (LVF). NENA i3 requires that the mapping (ECRF) and validation (LVF) functions be separable; an entity responsible for a LoST server cluster can decide to provide mapping and validation services using consolidated or separate server clusters (i.e., using the same or separate boxes). The rationale is that the mapping service is used in real time during emergency call routing, while the validation service is used in advance, typically when data is provisioned; therefore, the mapping service has much higher availability and response-time requirements than the validation service. An organization might choose to deploy these services using different server clusters to make it easier to provide higher levels of service for the mapping function while shielding it from the potentially bursty load of validation. Another organization might choose to use the same sets of servers for both services, configured and deployed to offer the high service level demanded of the mapping service.
失われたプロトコル[RFC5222]は、クライアントがCivic Addressを検証するように要求するための追加の機能を持つマッピングサービスを定義します。失われたプロトコルにより、サーバーはロケーション検証を実行するための要求を無視することができます。 National Emergency Number Association（NENA）は、ALL-IP緊急サービス（「I3」[NENA-I3]）のアーキテクチャを定義しており、マッピング（ルーティング）および検証機能を定義した2つの異なる機能要素として定義します。緊急呼び出しルーティング機能（ECRF）と位置検証機能（LVF）。 NENA I3では、マッピング（ECRF）機能（LVF）機能が分離可能であることが必要です。 Lost Serverクラスタを担当するエンティティは、統合または別々のサーバークラスタを使用してマッピングおよび検証サービスを提供することを決定できます（すなわち、同じボックスまたは別々のボックスを使用する）。根拠は、緊急通話ルーティング中にマッピングサービスがリアルタイムで使用され、検証サービスは事前に使用され、通常はデータがプロビジョニングされているときに予め使用されます。したがって、マッピングサービスは検証サービスよりはるかに高い可用性と応答時間の要件を持ちます。組織は、さまざまなサーバークラスタを使用してこれらのサービスを展開して、マッピング機能のためのより高いレベルのサービスを提供し、検証の潜在的なバーストロードからシールドすることを容易にすることを選択できます。別の組織は、マッピングサービスを要求する高いサービスレベルを提供するために、5つのサービスと展開された両方のサーバーに同じサーバーセットを使用することを選択できます。
In order to permit this separability, any entity querying a LoST server needs to be able to resolve an Application Unique String (AUS) into a URL for a LoST server designated for the required service (mapping or validation). This separability needs to be maintained throughout the LoST tree structure, from forest guide to leaf node (LoST architecture is described in [RFC5582]). Because LoST referrals return an AUS rather than a URL, either a different service tag or a DNS name convention (e.g., "ecrf.example.org" and "lvf.example.org") is needed to differentiate between the services. DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.
このセパラビリティを許可するために、失われたサーバーを照会するエンティティは、必要なサービス（マッピングまたは検証）のために指定されたLost ServerのURLにアプリケーション固有の文字列（AUS）を解決できる必要があります。この分離性は、フォレストガイドからリーフノードまで、紛失したツリー構造全体を通して維持される必要があります（[ROSTアーキテクチャ]は[RFC5582]に記載されています）。失われた紹介は、サービスを区別するために、異なるサービスタグまたはDNS名規則（例えば、「ecrf.example.org」および「lvf.example.org」）のいずれかではなく、URLを返します。DNS名規則は柔軟で壊れやすいため、異なるサービスタグが優先アプローチになります。
Because LoST servers may ignore a request to perform location validation, a service tag explicitly for location validation also reduces the likelihood (which has existed since [RFC5582]) that a client needing location validation will reach servers that are not doing so (due to configuration and/or conditions).
ロストされているサーバーはロケーション検証を実行するための要求を無視する可能性があるため、ロケーション検証のために明示的にサービスタグも明示的に、ロケーション検証を必要とするクライアントがそうしていないサーバーに到達する可能性がある（RFC5582]から存在しています）。および/または条件）。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document adds 'LoST-Validation' to the "S-NAPTR Application Service Tags" registry created by [RFC3958]. The 'LoST-Validation' tag serves as a counterpart to the 'LoST' tag added by [RFC5222]: the 'LoST' tag identifies servers able to perform the core mapping function, while 'LoST-Validation' identifies servers designated for the validation function.
この文書は、[RFC3958]によって作成された「S-NAPTRアプリケーションサービスタグ」レジストリに「失われた検証」を追加します。「失われた検証」タグは、[RFC5222]によって追加された「失われた」タグに対するカウンターパートとして機能します。「失われた」タグは、コアマッピング関数を実行できるサーバーを識別しますが、「失われた検証」は検証に指定されたサーバーを識別します。関数。
Because some servers might be configured to provide both mapping and validation functions, a server identified using the 'LoST' service tag might also perform the validation function (and resolving the two tags might result in the same URL). Because the two functions might be separate, clients seeking a LoST server for location validation can first try a URI-Enabled NAPTR (U-NAPTR) resolution using the 'LoST-Validation' service tag and can fall back to the 'LoST' service tag if this does not resolve to a usable LoST server.
マッピング関数と検証関数の両方を提供するように一部のサーバーが構成されている可能性があるため、 'Lost' Serviceタグを使用して識別されたサーバーは検証関数も実行される可能性があります（および2つのタグを解決すると同じURLになる可能性があります）。2つの機能が別々になる可能性があるため、ロケーション検証のためにロストされたサーバーを探しているクライアントは、最初に「紛失検証」サービスタグを使用してURI対応のNAPTR（U-NAPTR）解決を試して、「失われた」サービスタグに戻ることができます。これが使用可能な紛失したサーバーに解決されない場合。
LoST [RFC5222] specifies that LoST servers are located by resolving an AUS using U-NAPTR/DDDS (URI-Enabled NAPTR / Dynamic Delegation Discovery Service) [RFC4848] and defines the 'LoST' application service tag. In order to permit separability of the mapping and validation services performed using LoST, this document defines the 'LoST-Validation' service tag. This tag also reduces the likelihood that a client needing location validation might reach servers that are not performing validation (due to configuration and/or conditions). NAPTR records for LoST servers available for location validation contain the 'LoST-Validation' service tag. An entity needing to perform location validation using LoST performs the discovery procedure as described in [RFC5222], except that the 'LoST-Validation' service tag is used in preference to the 'LoST' service tag. For both service tags, the HTTP and HTTPS URL schemes are used. In the absence of any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service tag is used. Fallback to the 'LoST' service tag may follow if the 'LoST-Validation' service tag fails to result in a usable LoST server. The discovery procedure with the 'LoST-Validation' service tag might result in the same URL as the 'LoST' service tag, or it may result in a different URL. When the URLs are different, they could lead to the same physical servers or different servers.
LOST [RFC5222]は、U-NAPTR / DDDS（URI対応のNAPTR / Dynamation Discovery Discovery Service）[RFC4848]を使用してAUSを解決することで、ロストされているサーバーが配置されていることを指定し、[Rost]アプリケーションサービスタグを定義します。失われたマッピングおよび検証サービスの分離性を失ったことを許可するために、このドキュメントは「失効検証」サービスタグを定義します。このタグはまた、位置検証を必要とするクライアントが検証を実行していないサーバに到達する可能性を低下させます（構成や条件など）。 Location Validationに使用できるロストサーバーのためのNAPTRレコードには、「障害検証」サービスタグが含まれています。 LOSTを使用して位置検証を実行する必要があるエンティティは、[RFC5222]で説明されているディスカバリープロシージャを実行します。両方のサービスタグの場合、HTTPおよびHTTPS URLスキームが使用されます。 「障害検証」サービスタグを含むNAPTRレコードがない場合は、「失われた」サービスタグが使用されます。 'Lost-Validation' Serviceタグが使用可能なLost Serverに障害が発生した場合、「失われた」サービスタグへのフォールバックが続くかもしれません。 「失効した検証」サービスタグを使用した検出手順は、「失われた」サービスタグと同じURLをもたらす可能性があります。または、異なるURLになる可能性があります。 URLが異なる場合、それらは同じ物理サーバーまたは異なるサーバーにつながる可能性があります。
The primary use of LoST in general, and the location validation functionality in particular, is within the emergency services area. Within North America, the NENA i3 [NENA-i3] document specifies how protocols including LoST are used. The i3 document is expected to reference the 'LoST-Validation' service tag and specify its use in both server NAPTR DNS records and client resolution of AUS.
一般的に失われた主な使用、および特に位置検証機能は、緊急サービスエリア内にあります。北米内では、NENA I3 [NENA-I3]ドキュメントは、失われたプロトコルが使用される方法を指定します。I3ドキュメントは、「失効検証」サービスタグを参照して、サーバーNAPTR DNSレコードとAUSのクライアント解決の両方で使用することが予想されます。
LoST allows a server to refuse to perform location validation and defines the 'locationValidationUnavailable' warning. LoST also allows a server to refer to another server rather than answering itself. So, in a deployment where a LoST tree has separate server clusters for mapping and for validation, mapping servers receiving a request for validation could either perform the validation as requested or return the 'locationValidationUnavailable' warning and potentially also include a <redirect> element to redirect to a validation server. However, the <redirect> element contains an AUS, so unless the AUSs for validation and mapping are different (e.g., 'ecrf.example.org' and 'lvf.example.org'), we still need a different service tag to allow for flexible deployment choices (i.e., not requiring a DNS name convention).
LOST LOSTサーバーは位置検証を実行し、[LocationValidationUnavailable]警告を定義します。失われたところ、サーバーは自分自身に答えるのではなく、他のサーバーを参照することもできます。したがって、失われたツリーがマッピングおよび検証のための別々のサーバークラスタを持つ展開で、検証要求を受け取るマッピングサーバーは要求されたときに検証を実行したり、「locationValidationUnavailable」警告を返したり、<リダイレクト>要素にも含まれています。検証サーバーにリダイレクトします。ただし、<redirect>要素にはAUSが含まれているため、検証とマッピングのためのAUSSが異なっていない（例： 'ecrf.example.org'と 'lvf.example.org'）、私たちはまだ許可するために別のサービスタグが必要です。柔軟な展開の選択のために（すなわち、DNS名規約を必要としない）。
LoST clients performing emergency services operations in North America are expected to comply with the NENA i3 specification and hence support the 'LoST-Validation' service tag when defined. A LoST client implemented prior to the addition of the 'LoST-Validation' tag would use the 'LoST' tag to resolve an AUS. Such a client might not be performing location validation, but if it is, the LoST server it contacts may perform the service. Even in a deployment where mapping and validation are split, the data is identical; the split is a load and deployment optimization strategy. Servers designated for mapping might perform validation when requested (potentially depending on load or other factors). If an older client attempts validation using a designated mapping server that refuses the request, the client will retry later, at which point the server might provide the function (e.g., if its load or other conditions have changed). Even in the case of a designated mapping server that refuses to perform validation at any time, the server could return a redirect with a different AUS (e.g., "lvf.example.com") that resolves to a designated validation server. In the worst case, the client will be unable to reach a server willing to perform validation and will follow up (e.g., submit a discrepancy report as specified in NENA i3). The resolution may be to update the client with the 'LoST-Validation' service tag, update the AUS returned in a redirect and DNS to use a different DNS host name, or permit the server to perform validation when not under stress (or a combination). Note that, because LoST does not require servers to perform validation, the situation described can exist regardless of the addition of the 'LoST-Validation' service tag. Use of the tag improves the likelihood that a client is able to validate a location when needed.
停止顧客停止停止業務業務を行う北米での業務業務は、NENA I3仕様に準拠しているため、定義されたときに「失効検証」サービスタグをサポートします。 「失われた検証」タグを追加する前に実装された失われたクライアントは、AUSを解決するために「失われた」タグを使用するでしょう。そのようなクライアントは位置検証を実行していない可能性がありますが、それがそうであれば、それが紛失したサーバーがサービスを実行することができます。マッピングと検証が分割されている展開でも、データは同一です。分割は負荷と展開の最適化戦略です。マッピングのために指定されたサーバーは、要求されたときに検証を実行することがあります（負荷やその他の要因によっては潜在的には）。要求を拒否する指定マッピングサーバを使用して古いクライアントが検証を試みると、クライアントは後で再試行し、その時点でサーバが機能を（例えば、その負荷または他の条件が変更された場合）。いつでも検証を拒否する指定されたマッピングサーバの場合でも、サーバは指定された検証サーバに解決される異なるAUS（例えば、「Lvf.example.com」）とのリダイレクトを返すことができる。最悪の場合、クライアントは検証を実行しても構わないと思われるサーバーにアクセスできなくなり（例えば、NENA I3で指定されている矛盾レポートを送信する）。解像度は、「紛失検証」サービスタグを使用してクライアントを更新することができ、リダイレクトおよびDNSで返されたAUSを更新し、異なるDNSホスト名を使用するか、ストレスを受けていないときにサーバーが検証を実行できるようにします（または組み合わせ）。 ）。失われたため、サーバーが検証を実行する必要がないため、「検証喪失」サービスタグの追加にかかわらず、記載されている状況は存在できます。タグを使用すると、クライアントが必要なときに場所を検証できる可能性が向上します。
The security considerations described in [RFC3958], [RFC4848], and [RFC5222] apply here. No additional security aspects are foreseen by the addition of an extra tag. Separation of services might be desired, for example, to be able to allocate different levels of resources (such as server capacity, attack mitigation, bandwidth, etc.) to the mapping and validation services, in which case separate tags are needed to allow LoST clients (which may include other LoST servers) to identify the correct server cluster.
[RFC3958]、[RFC4848]、[RFC5222]で説明したセキュリティ上の考慮事項はここに適用されます。追加のタグを追加することで、追加のセキュリティ側面は予測されません。例えば、さまざまなレベルのリソース（サーバー容量、攻撃軽減、帯域幅など）をマッピングおよび検証サービスに割り当てることができるように、サービスの分離が望ましいかもしれません。正しいサーバークラスタを識別するためのクライアント（他の失われたサーバーを含めることがあります）。
[RFC5222] descriptively discusses the use of DNS security [RFC4033] to mitigate the risk of DNS-based attacks. Because DNS security has become more widely deployed since the publication of [RFC5222], such measures SHOULD be used when performing NAPTR resolution. Note that, while there are valid reasons to proceed with a LoST mapping query despite security failures while initiating or processing an emergency call, these concerns generally do not apply to a LoST validation query done in advance of an emergency call.
[RFC5222] DNSベースの攻撃のリスクを軽減するためのDNSセキュリティ[RFC4033]の使用について説明します。DNSセキュリティは、[RFC5222]の出版物からより広く展開されているため、NAPTRの解決を実行するときにそのような対策を使用する必要があります。緊急呼び出しを開始または処理しながら、セキュリティの失敗にもかかわらず失われたマッピングクエリを進める有効な理由があるが、これらの懸念は一般的に緊急呼び出しの前に行われた失われた検証クエリには適用されません。
IANA has added 'LoST-Validation' to the "S-NAPTR Application Service Tags" registry created by [RFC3958]. This tag serves as a counterpart to the 'LoST' tag added by [RFC5222].
IANAは、[RFC3958]によって作成された「S-NAPTRアプリケーションサービスタグ」レジストリに「失われた検証」を追加しました。このタグは、[RFC5222]によって追加された「失われた」タグへの対応物として機能します。
(Note that IANA and [RFC3958] call this registry "S-NAPTR Application Service Tags", while [RFC5222] calls it "U-NAPTR application service tag".)
（IANAと[RFC3958]は、このレジストリ "S-NAPTRアプリケーションサービスタグ"を呼び出しますが、RFC5222は「U-NAPTR Application Service Tag」と呼びます。）
This document registers an S-NAPTR application service tag:
このドキュメントはS-NAPTRアプリケーションサービスタグを登録します。
Application Service Tag: LoST-Validation
アプリケーションサービスタグ：失われた検証
Defining Publication: This document
出版物の定義：この文書
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC3958] Daigle、L.およびA.ニュートン、「SRV RRSおよび動的委任発見サービスを使用したドメインベースのアプリケーションサービスの場所（DDDS）」、RFC 3958、DOI 10.17487 / RFC3958、2005年1月、<HTTPS：// WWW.rfc-editor.org / info / rfc3958>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, <https://www.rfc-editor.org/info/rfc4848>.
[RFC4848] Daigle、L.、「DOMACEベースのアプリケーションサービスの場所（URISおよび動的委任発見サービス（DDDS）」、RFC 4848、DOI 10.17487 / RFC4848、2007年4月、<https：//www.rfc-編集者。ORG / INFO / RFC4848>。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, <https://www.rfc-editor.org/info/rfc5222>.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H.、およびH.Tschofenig、 "Lost：Service to-Service Translation Protocol"、RFC 5222、DOI 10.17487 / RFC5222、2008年8月、<https：//www.rfc-editor.org/info/rfc5222>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[NENA-i3] National Emergency Number Association (NENA) Interconnection and Security Committee, i3 Architecture Working Group, "Detailed Functional and Interface Standards for the NENA i3 Solution", 2016, <https://www.nena.org/page/i3_Stage3>.
[NENA-I3] NENA緊急ナンバー協会（NENA）相互接続とセキュリティ委員会、I3アーキテクチャワーキンググループ、2016年、2016年、<https://www.nena.org/page/i3_stage3>。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, DOI 10.17487/RFC5582, September 2009, <https://www.rfc-editor.org/info/rfc5582>.
[RFC5582] Schulzrinne、H.、「ロケーションからURLマッピングアーキテクチャとフレームワーク」、RFC 5582、DOI 10.17487 / RFC5582、2009年9月、<https：//www.rfc-editor.org/info/rfc5582>。
Acknowledgements
謝辞
Many thanks to Ted Hardie, Ben Campbell, Dan Banks, Pete Resnick, Shawn Emery, Robert Wilton, Roman Danyliw, and Benjamin Kaduk for their helpful reviews and suggestions and to Barry Leiba for shepherding the document.
Ted hardie、Ben Campbell、Dan Banks、Pete Resnick、Shawn Emery、Robert Wilton、Robert Wilton、Robert Wilton、Roman Danyylw、およびBenjamin Kaduk、およびBarry Leibaの羊飼いのためのBarry Leiba。
Authors' Addresses
著者の住所
Randall Gellens Core Technology Consulting United States of America
Randall Gellens Core Technologyコンサルティングアメリカ合衆国
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com
Brian Rosen 470 Conrad Dr. Mars, PA 16046 United States of America
Brian Rosen 470 Conrad Dr. Mars、PA 16046アメリカ
Email: br@brianrosen.net