[要約] RFC 7852は、緊急通報に関連する追加データについての要約と目的を提供しています。このRFCの目的は、緊急通報システムにおいて、位置情報や医療情報などの追加データを効果的に扱うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 7852
Updates: 6443, 6881 B. Rosen
Category: Standards Track NeuStar
ISSN: 2070-1721 H. Tschofenig
R. Marshall TeleCommunication Systems, Inc. J. Winterbottom Winterb Consulting Services July 2016
R. Marshall TeleCommunication Systems、Inc. J. Winterbottom Winterb Consulting Services 2016年7月
Additional Data Related to an Emergency Call
緊急通報に関連する追加データ
Abstract
概要
When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.
緊急コールがPSA（Public Safety Answering Point）に送信されると、発信元デバイス、デバイスが接続されているアクセスネットワークプロバイダー、およびコールのパスにあるすべてのサービスプロバイダーが、コールに関する情報、発信者、またはPSAPが緊急事態に対処するのに役立つ場所。このドキュメントでは、そのようなデータをPSAPに伝達するためのデータ構造とメカニズムについて説明します。ここで説明するメカニズムを使用して、すべての緊急コールに、ここで説明する情報をできるだけ多く伝えることを意図しています。
The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.
このメカニズムにより、データを参照（外部リソースとして）または値（SIPメッセージの本文またはロケーションオブジェクト内）で伝達できます。これは、コールシグナリング内の値（つまり、SIPメッセージの本文）または参照によってデータを伝達できる、以前の緊急サービスの標準化作業の伝統に従います。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc7852.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7852で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7
4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Data Provider Information. . . . . . . . . . . . . . . . . 9
4.1.1. Data Provider String . . . . . . . . . . . . . . . . . 9
4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . . 9
4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . . 10
4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . . 11
4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . . 12
4.1.6. Data Provider Language(s) Supported . . . . . . . . . . 13
4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . . 14
4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . . 14
4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . . 15
4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . . 15
4.2. Service Information . . . . . . . . . . . . . . . . . . . 18
4.2.1. Service Environment . . . . . . . . . . . . . . . . . . 18
4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. Service Mobility Environment . . . . . . . . . . . . . 21
4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . . 22
4.3. Device Information . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Device Classification . . . . . . . . . . . . . . . . . 22
4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . . 23
4.3.3. Device Model Number . . . . . . . . . . . . . . . . . . 24
4.3.4. Unique Device Identifier . . . . . . . . . . . . . . . 24
4.3.5. Device/Service-Specific Additional Data Structure . . . 25
4.3.6. Device/Service-Specific Additional Data Structure Type 26
4.3.7. EmergencyCallData.DeviceInfo Example . . . . . . . . . 27
4.4. Owner/Subscriber Information . . . . . . . . . . . . . . . 27
4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . . 27
4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . . 28
4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . . 29
4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . . 32
5. Issues with Getting New Types of Data into Use . . . . . . . 32
5.1. Choosing between Defining a New Type of Block or a New
Type of Device/Service-Specific Additional Data . . . . . 33
6. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33
6.1. Transmitting Blocks Using Call-Info . . . . . . . . . . . 36
6.2. Transmitting Blocks by Reference Using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3. Transmitting Blocks by Value Using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 54
8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . . 56
8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 57
8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 59
8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . . 60
8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . . 61
9. Security Considerations . . . . . . . . . . . . . . . . . . . 62
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
11.1. Emergency Call Additional Data Registry . . . . . . . . . 67
11.1.1. Provider ID Series Registry . . . . . . . . . . . . . 67
11.1.2. Service Environment Registry . . . . . . . . . . . . . 68
11.1.3. Service Type Registry . . . . . . . . . . . . . . . . 68
11.1.4. Service Mobility Registry . . . . . . . . . . . . . . 68
11.1.5. Type of Provider Registry . . . . . . . . . . . . . . 69
11.1.6. Device Classification Registry . . . . . . . . . . . . 69
11.1.7. Device ID Type Registry . . . . . . . . . . . . . . . 69
11.1.8. Device/Service Data Type Registry . . . . . . . . . . 70
11.1.9. Emergency Call Data Types Registry . . . . . . . . . . 70
11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . . 72
11.3. URN Sub-Namespace Registration for <provided-by>
Registry Entry . . . . . . . . . . . . . . . . . . . . . 72
11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72
11.4.1. MIME Content-Type Registration for
'application/EmergencyCallData.ProviderInfo+xml' . . . 72
11.4.2. MIME Content-Type Registration for
'application/EmergencyCallData.ServiceInfo+xml' . . . 73
11.4.3. MIME Content-Type Registration for
'application/EmergencyCallData.DeviceInfo+xml' . . . . 74
11.4.4. MIME Content-Type Registration for
'application/EmergencyCallData.SubscriberInfo+xml' . . 75
11.4.5. MIME Content-Type Registration for
'application/EmergencyCallData.Comment+xml' . . . . . 76
11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 78
11.5.1. Registration for
urn:ietf:params:xml:ns:EmergencyCallData . . . . . . . 78
11.5.2. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo . 78
11.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo . 79
11.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo . . 80
11.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo 81
11.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment . . . 81
11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 82
11.7. vCard Parameter Value Registration . . . . . . . . . . . 83
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
12.1. Normative References . . . . . . . . . . . . . . . . . . 84
12.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 89
Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 111
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113
When an IP-based emergency call is initiated, a rich set of data from multiple data sources is conveyed to the Public Safety Answering Point (PSAP). This data includes information about the calling party identity, the multimedia capabilities of the device, the request for emergency services, location information, and metadata about the sources of the data. In addition, the device, the access network provider, and any service provider in the call path has even more information that is useful for a PSAP when handling an emergency.
IPベースの緊急コールが開始されると、複数のデータソースからの豊富なデータセットがPublic Safety Answering Point（PSAP）に伝達されます。このデータには、発呼者のアイデンティティに関する情報、デバイスのマルチメディア機能、緊急サービスの要求、位置情報、およびデータのソースに関するメタデータが含まれます。さらに、デバイス、アクセスネットワークプロバイダー、およびコールパス内のサービスプロバイダーには、PSAPが緊急事態を処理するときに役立つ情報がさらにあります。
This document extends the basic set of data communicated with an emergency call based on the Session Initiation Protocol (SIP), as described in RFC 6443 [RFC6443] and RFC 6881 [RFC6881], in order to carry additional data that is useful to an entity or call taker handling the call. This data is "additional" to the basic information found in the emergency call signaling used. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.
このドキュメントでは、RFC 6443 [RFC6443]およびRFC 6881 [RFC6881]で説明されているように、Session Initiation Protocol（SIP）に基づいて緊急コールと通信する基本的なデータセットを拡張し、エンティティに役立つ追加データを伝送します。または、コールを処理するテイカーを呼び出します。このデータは、使用される緊急コールシグナリングにある基本情報に「追加」されます。ここで説明するメカニズムを使用して、すべての緊急コールに、ここで説明する情報をできるだけ多く伝えることを意図しています。
This document defines three categories of this additional data that can be transmitted with an emergency call:
このドキュメントでは、緊急コールで送信できるこの追加データの3つのカテゴリを定義しています。
Data Associated with a Location: Primary location data is conveyed in the Presence Information Data Format Location Object (PIDF-LO) data structure as defined in RFC 4119 [RFC4119] and extended by RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for geodetic location information), and RFC 7035 [RFC7035] (for relative location). This primary location data identifies the location or estimated location of the caller. However, there might exist additional, secondary data that is specific to the location, such as floor plans, tenant and building owner contact data, heating, ventilation, and air conditioning (HVAC) status, etc. Such secondary location data is not included in the location data structure but can be transmitted using the mechanisms defined in this document. Although this document does not define any structures for such data, future documents can do so following the procedures defined here.
ロケーションに関連付けられたデータ：プライマリロケーションデータは、RFC 4119 [RFC4119]で定義され、RFC 5139 [RFC5139]およびRFC 6848 [RFC6848]で拡張されたプレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）データ構造で伝達されます（市の位置情報）、RFC 5491 [RFC5491]およびRFC 5962 [RFC5962]（測地位置情報）、およびRFC 7035 [RFC7035]（相対位置）。このプライマリロケーションデータは、発信者のロケーションまたは推定ロケーションを識別します。ただし、フロアプラン、テナントと建物の所有者の連絡先データ、暖房、換気、および空調（HVAC）のステータスなど、場所に固有の追加の二次データが存在する場合があります。このような二次場所データは含まれていませんロケーションデータ構造ですが、このドキュメントで定義されているメカニズムを使用して送信できます。このドキュメントでは、そのようなデータの構造を定義していませんが、今後のドキュメントでは、ここで定義されている手順に従って定義することができます。
Data Associated with a Call: While some information is carried in the call setup procedure itself (as part of the SIP headers as well as in the body of the SIP message), there is additional data known by the device making the call, the access network to which the device is connected, and service providers along the path of the call. This information includes service provider contact information, subscriber identity and contact information, the type of service the service provider and the access network provide, what type of device is being used, etc. Some data is broadly applicable, while other data is dependent on the type of device or service. For example, a medical monitoring device might have sensor data. The data structures defined in this document (Data Provider Information, Device Information, and Owner/Subscriber Information) all fall into the category of "Data Associated with a Call". Note that the owner/subscriber information includes the subscriber's vCard, which might contain personal information such as birthday, anniversary, etc., but the data block itself is still considered to be about the call, not the caller.
通話に関連するデータ：一部の情報は通話設定手順自体で（SIPヘッダーの一部として、およびSIPメッセージの本文として）伝達されますが、通話を行うデバイス、アクセスデバイスが接続されているネットワーク、およびコールのパスに沿ったサービスプロバイダー。この情報には、サービスプロバイダーの連絡先情報、加入者のIDと連絡先情報、サービスプロバイダーとアクセスネットワークが提供するサービスの種類、使用されているデバイスの種類などが含まれます。一部のデータは広く適用可能ですが、他のデータはデバイスまたはサービスのタイプ。たとえば、医療監視デバイスにセンサーデータがある場合があります。このドキュメントで定義されているデータ構造（データプロバイダー情報、デバイス情報、所有者/加入者情報）はすべて、「通話に関連付けられたデータ」のカテゴリに分類されます。所有者/サブスクライバー情報には、誕生日、記念日などの個人情報が含まれる可能性があるサブスクライバーのvCardが含まれますが、データブロック自体は、発信者ではなく、通話に関するものと見なされます。
Data Associated with a Caller: This is personal data about a caller, such as medical information and emergency contact data. Although this document does not define any structures within this category, future documents can do so following the procedures defined here.
発信者に関連付けられたデータ：これは、医療情報や緊急連絡先データなど、発信者に関する個人データです。このドキュメントでは、このカテゴリ内の構造を定義していませんが、今後のドキュメントでは、ここで定義されている手順に従って定義することができます。
While this document defines data structures only within the category of Data Associated with a Call, by establishing the overall framework of Additional Data, along with general mechanisms for transport of such data, extension points, and procedures for future extensions, it minimizes the work needed to carry data in the other categories. Other specifications can make use of the facilities provided here.
このドキュメントでは、コールに関連付けられたデータのカテゴリ内でのみデータ構造を定義しますが、追加データの全体的なフレームワークと、そのようなデータの転送の一般的なメカニズム、拡張ポイント、および将来の拡張のための手順を確立することにより、必要な作業を最小限に抑えます他のカテゴリのデータを運ぶため。他の仕様では、ここで提供される機能を利用できます。
For interoperability, there needs to be a common way for the information conveyed to a PSAP to be encoded and identified. Identification allows emergency services authorities to know during call processing which types of data are present and to determine if they wish to access it. A common encoding allows the data to be successfully accessed.
相互運用性のために、PSAPに伝達される情報をエンコードして識別するための共通の方法が必要です。識別により、緊急サービス当局は、呼処理中にどのタイプのデータが存在するかを知り、それにアクセスするかどうかを決定できます。共通のエンコーディングにより、データに正常にアクセスできます。
This document defines an extensible set of data structures, and mechanisms to transmit this data either by value or by reference, either in the SIP call signaling or in the PIDF-LO. The data structures are usable by other communication systems and transports as well. The data structures are defined in Section 4, and the transport mechanisms (using SIP and HTTPS) are defined in Section 6.
このドキュメントでは、拡張可能なデータ構造のセット、およびSIPコールシグナリングまたはPIDF-LOのいずれかで、値または参照によってこのデータを送信するメカニズムを定義します。データ構造は、他の通信システムやトランスポートでも使用できます。データ構造はセクション4で定義され、トランスポートメカニズム（SIPおよびHTTPSを使用）はセクション6で定義されます。
Each data structure described in this document is encoded as a "block" of information. Each block is an XML structure with an associated Multipurpose Internet Mail Extensions (MIME) media type for identification within transport such as SIP and HTTPS. The set of blocks is extensible. Registries are defined to identify the block types that can be used and to allow blocks to be included in emergency call signaling.
このドキュメントで説明する各データ構造は、情報の「ブロック」としてエンコードされます。各ブロックはXML構造であり、SIPやHTTPSなどのトランスポート内で識別できるように、多目的インターネットメール拡張（MIME）メディアタイプが関連付けられています。ブロックのセットは拡張可能です。レジストリは、使用可能なブロックタイプを識別し、ブロックを緊急コールシグナリングに含めることができるように定義されています。
Much of the information supplied by service providers and devices is private and confidential. Service providers and devices generally go to lengths to protect this information; disclosing it in the context of an emergency call is a trade-off to protect the greater interest of the customer in an emergency.
サービスプロバイダーやデバイスから提供される情報の多くは、機密情報です。サービスプロバイダーとデバイスは、通常、この情報を保護するために最大限の努力をします。緊急通報のコンテキストでそれを開示することは、緊急事態における顧客の大きな関心を保護するトレードオフです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document also uses terminology from [RFC5012]. We use the term "service provider" to refer to an Application Service Provider (ASP). A Voice Service Provider (VSP) is a special type of ASP. With the term "Access Network Provider", we refer to the Internet Access Provider (IAP) and the Internet Service Provider (ISP) without further distinguishing these two entities, since the difference between the two is not relevant for this document. Note that the roles of an ASP and access network provider might be provided by a single company. An Emergency Services Provider is an entity directly involved in providing emergency services. This includes PSAPs, dispatch, police, fire, emergency medical, other responders, and other similar agencies.
このドキュメントでは、[RFC5012]の用語も使用しています。 「サービスプロバイダー」という用語は、アプリケーションサービスプロバイダー（ASP）を指します。音声サービスプロバイダー（VSP）は特別な種類のASPです。 「アクセスネットワークプロバイダー」という用語では、これら2つのエンティティを区別することなく、インターネットアクセスプロバイダー（IAP）とインターネットサービスプロバイダー（ISP）を指します。両者の違いはこのドキュメントには関係がないためです。 ASPおよびアクセスネットワークプロバイダーの役割は、1つの会社によって提供される場合があることに注意してください。緊急サービスプロバイダーは、緊急サービスの提供に直接関与するエンティティです。これには、PSAP、派遣、警察、消防、救急医療、その他の対応者、およびその他の同様の機関が含まれます。
Within each data block definition (see Section 4), the values for the 'Use:' label are specified as one of the following:
各データブロック定義（セクション4を参照）内で、「使用：」ラベルの値は次のいずれかとして指定されます。
'Required': means it MUST be present in the data structure.
「必須」：データ構造に存在する必要があることを意味します。
'Conditional': means it MUST be present if the specified condition(s) is met. It MAY be present if the condition(s) is not met.
「条件付き」：指定された条件が満たされた場合に存在する必要があることを意味します。条件が満たされない場合に存在する可能性があります。
'Optional': means it MAY be present.
「オプション」：存在してもよいことを意味します。
vCard [RFC6350] is a data format for representing and exchanging a variety of information about individuals and other entities. For applications that use XML, the format defined in vCard is not immediately applicable. For this reason, an XML-based encoding of the information elements defined in the vCard specification has been defined, and the name of that specification is xCard [RFC6351]. Since the term vCard is more familiar to most readers, we use the terms xCard and vCard interchangeably.
vCard [RFC6350]は、個人やその他のエンティティに関するさまざまな情報を表現および交換するためのデータ形式です。 XMLを使用するアプリケーションの場合、vCardで定義された形式はすぐには適用されません。このため、vCard仕様で定義されている情報要素のXMLベースのエンコーディングが定義されており、その仕様の名前はxCard [RFC6351]です。 vCardという用語はほとんどの読者にとってより身近なものであるため、xCardとvCardは同じ意味で使用されています。
The scope of this document is explicitly limited to emergency calls. The data structures defined here are not appropriate to be conveyed in non-emergency calls because they carry sensitive and private data. However, in certain private-use situations between a specialized service provider (such as a vehicle telematics service provider) and dedicated equipment (such as in a vehicle) where the endpoints have a preexisting relationship and privacy issues are addressed within the relationship, the mechanisms and data structures defined here can be used with communications within the limited context of the preexisting relationship.
このドキュメントの範囲は、緊急コールに明示的に限定されています。ここで定義されているデータ構造は、機密データやプライベートデータを運ぶため、緊急でない通話での伝達には適していません。ただし、専用のサービスプロバイダー（車両テレマティクスサービスプロバイダーなど）と専用機器（車両など）の間の特定の私的使用状況では、エンドポイントに既存の関係があり、その関係内でプライバシーの問題に対処します。ここで定義されたデータ構造は、既存の関係の限られたコンテキスト内での通信で使用できます。
This section defines the following five data structures, each as a data block. For each block, we define the MIME media type and the XML encoding. The five data structures are:
このセクションでは、それぞれがデータブロックとして、次の5つのデータ構造を定義します。ブロックごとに、MIMEメディアタイプとXMLエンコーディングを定義します。 5つのデータ構造は次のとおりです。
'Data Provider': This block supplies name and contact information for the entity that created the data. Section 4.1 provides the details.
'Data Provider'：このブロックは、データを作成したエンティティの名前と連絡先情報を提供します。セクション4.1で詳細を説明します。
'Service Information': This block supplies information about the service. The description can be found in Section 4.2.
'サービス情報'：このブロックは、サービスに関する情報を提供します。説明はセクション4.2にあります。
'Device Information': This block supplies information about the device placing the call. Device information can be found in Section 4.3.
'デバイス情報'：このブロックは、通話を発信するデバイスに関する情報を提供します。デバイス情報はセクション4.3にあります。
'Owner/Subscriber': This block supplies information about the owner of the device or about the subscriber. Details can be found in Section 4.4.
'Owner / Subscriber'：このブロックは、デバイスの所有者またはサブスクライバーに関する情報を提供します。詳細はセクション4.4を参照してください。
'Comment': This block provides a way to supply free form human-readable text to the PSAP or emergency responders. This simple structure is defined in Section 4.5.
'コメント'：このブロックは、PSAPまたは緊急応答者に自由形式の人間が読めるテキストを提供する方法を提供します。この単純な構造はセクション4.5で定義されています。
Each block contains a mandatory <DataProviderReference> element. The purpose of the <DataProviderReference> element is to associate all blocks added by the same data provider as a unit. The <DataProviderReference> element associates the data provider block to each of the other blocks added as a unit. Consequently, when a data provider adds additional data to an emergency call (such as device information), it MUST add information about itself (via the data provider block), and the blocks added contain the same value in the <DataProviderReference> element. All blocks added by a single entity at the same time MUST have the same <DataProviderReference> value. (In certain situations, the same provider might process a call more than once, likely in different roles, and in such cases, each time it processes the call, it adds a new set of blocks with a new <DataProviderReference> value.) The value of the <DataProviderReference> element has the same syntax and properties (specifically, world-uniqueness) as the value of the 'Message-ID' message body header field specified in RFC 5322 [RFC5322] except that the <DataProviderReference> element is not enclosed in brackets (the '<' and '>' symbols are omitted). In other words, the value of a <DataProviderReference> element is syntactically a msg-id as specified in RFC 5322 [RFC5322].
各ブロックには、必須の<DataProviderReference>要素が含まれています。 <DataProviderReference>要素の目的は、同じデータプロバイダーによって追加されたすべてのブロックを1つの単位として関連付けることです。 <DataProviderReference>要素は、データプロバイダーブロックを、ユニットとして追加された他の各ブロックに関連付けます。したがって、データプロバイダーが緊急呼び出しに追加のデータ（デバイス情報など）を追加するときは、（データプロバイダーブロックを介して）データプロバイダー自体に関する情報を追加する必要があり、追加されたブロックには<DataProviderReference>要素に同じ値が含まれます。単一のエンティティによって同時に追加されたすべてのブロックは、同じ<DataProviderReference>値を持つ必要があります。 （特定の状況では、同じプロバイダーがおそらく異なる役割で呼び出しを複数回処理する可能性があり、そのような場合、呼び出しを処理するたびに、新しい<DataProviderReference>値を持つ新しいブロックのセットを追加します。） <DataProviderReference>要素の値は、RFC 5322 [RFC5322]で指定されている 'Message-ID'メッセージ本文ヘッダーフィールドの値と同じ構文およびプロパティ（具体的には、world-uniqueness）を持っていますが、<DataProviderReference>要素は大括弧で囲まれます（「<」および「>」記号は省略されます）。つまり、<DataProviderReference>要素の値は、RFC 5322 [RFC5322]で指定されているように、構文的にはmsg-idです。
Each block is added to the "Additional Data Blocks" registry created in Section 11.1.9 and categorized as providing data about the caller. New blocks added to the registry in the future MUST also be categorized per the description of the three categories in Section 1. See Sections 5 and 5.1 for additional considerations when adding new blocks or types of data.
各ブロックは、セクション11.1.9で作成された「追加データブロック」レジストリに追加され、発信者に関するデータを提供するものとして分類されます。将来レジストリに追加される新しいブロックも、セクション1の3つのカテゴリの説明に従って分類する必要があります。新しいブロックまたはデータのタイプを追加する際の追加の考慮事項については、セクション5および5.1を参照してください。
Note that the xCard format is reused in some of the data structures to provide contact information. In an xCard, there is no way to specify a 'main' telephone number (that is, a primary or main contact number, typically of an enterprise, as opposed to a direct-dial number of an individual). These numbers are useful to emergency responders who are called to a large enterprise. This document adds a new parameter value called 'main-number' to the 'TYPE' parameter of the 'tel' property. It can be used in any xCard in an emergency call additional data block.
一部のデータ構造ではxCard形式が再利用され、連絡先情報が提供されることに注意してください。 xCardでは、「メイン」の電話番号（つまり、個人の直接ダイヤル番号ではなく、通常は企業のプライマリまたはメインの連絡先番号）を指定する方法はありません。これらの番号は、大企業に呼び出される緊急応答者に役立ちます。このドキュメントでは、「main」番号と呼ばれる新しいパラメーター値を「tel」プロパティの「TYPE」パラメーターに追加します。緊急コールの追加データブロックの任意のxCardで使用できます。
This block is intended to be supplied by any service provider in the path of the call, or the access network provider, and the device. It includes identification and contact information. This block MUST be supplied by any entity that provides any other block; it SHOULD be supplied by every service provider in the call path and by the access network provider if those entities do not add any other blocks. Devices SHOULD use this block to provide identifying information. The MIME media type is 'application/ EmergencyCallData.ProviderInfo+xml'. An access network provider SHOULD provide this block either by value or by reference in the <provided-by> element of a PIDF-LO.
このブロックは、コールのパス内のサービスプロバイダー、またはアクセスネットワークプロバイダー、およびデバイスによって提供されることを目的としています。識別情報と連絡先情報が含まれています。このブロックは、他のブロックを提供するエンティティによって提供される必要があります。これらのエンティティが他のブロックを追加しない場合は、コールパス内のすべてのサービスプロバイダー、およびアクセスネットワークプロバイダーによって提供される必要があります。デバイスは、このブロックを使用して識別情報を提供する必要があります（SHOULD）。 MIMEメディアタイプは「application / EmergencyCallData.ProviderInfo + xml」です。アクセスネットワークプロバイダーは、値またはPIDF-LOの<provided-by>要素の参照によってこのブロックを提供する必要があります（SHOULD）。
Data Element: Data Provider String
データ要素：データプロバイダー文字列
Use: Conditional. Optional for blocks supplied by the originating device; mandatory otherwise.
使用：条件付き。発信元デバイスによって提供されるブロックのオプション。それ以外の場合は必須です。
XML Element: <DataProviderString>
Description: This is a plaintext string suitable for displaying the name of the service provider that supplied the data structure. If the device creates the structure, it SHOULD use the value of the contact header field in the SIP INVITE.
説明：これは、データ構造を提供したサービスプロバイダーの名前を表示するのに適したプレーンテキスト文字列です。デバイスが構造を作成する場合、SIP INVITEの連絡先ヘッダーフィールドの値を使用する必要があります（SHOULD）。
Reason for Need: Inform the call taker of the identity of the entity providing the data.
必要性の理由：データを提供しているエンティティのIDを呼び出し担当者に通知します。
How Used by Call Taker: Allows the call taker to interpret the data in this structure. The source of the information often influences how the information is used, believed, or verified.
コールテイカーによる使用方法：コールテイカーがこの構造のデータを解釈できるようにします。情報の出所は、情報の使用、信頼、検証の方法に影響を与えることがよくあります。
Data Element: Data Provider ID
データ要素：データプロバイダーID
Use: Conditional. Optional for blocks supplied by the originating device; mandatory otherwise. This data MUST be provided by all entities other than the originating device in order to uniquely identify the service provider or access provider.
使用：条件付き。発信元デバイスによって提供されるブロックのオプション。それ以外の場合は必須です。このデータは、サービスプロバイダーまたはアクセスプロバイダーを一意に識別するために、発信元のデバイス以外のすべてのエンティティによって提供される必要があります。
XML Element: <ProviderID> Description: A jurisdiction-specific code for, or the fully qualified domain name of, the access network provider or service provider shown in the <DataProvidedBy> element that created the structure. NOTE: The value SHOULD be assigned by an organization appropriate for the jurisdiction. In the United States, if the provider is registered with NENA, the provider's NENA Company ID MUST appear here. Additional information can be found at the National Emergency Number Association (NENA) Company Identifier Program <http://www.nena.org/?page=cid2014> or the NENA Company ID <http://www.nena.org/?page=CompanyID>. The NENA Company ID MUST be in the form of a URI in the following format: urn:nena:companyid:<NENA Company ID>. If the organization does not have an identifier registered with a jurisdiction-specific emergency services registrar (such as NENA), then the value MAY be the fully qualified domain name of the service provider or access provider. The device MAY use its IP address or fully qualified domain name (and set the 'Data Provider ID Series' element to 'domain').
XML要素：<ProviderID>説明：構造を作成した<DataProvidedBy>要素に示されているアクセスネットワークプロバイダーまたはサービスプロバイダーの管轄区域固有のコード、またはその完全修飾ドメイン名。注：値は、管轄区域に適切な組織によって割り当てられる必要があります（SHOULD）。米国では、プロバイダーがNENAに登録されている場合、プロバイダーのNENA会社IDをここに表示する必要があります。追加情報は、全米緊急番号協会（NENA）企業IDプログラム<http://www.nena.org/?page=cid2014>またはNENA企業ID <http://www.nena.org/？ page = CompanyID>。 NENA会社IDは、urn：nena：companyid：<NENA会社ID>の形式のURIの形式にする必要があります。組織が管轄区域固有の緊急サービスレジストラー（NENAなど）に登録された識別子を持っていない場合、値はサービスプロバイダーまたはアクセスプロバイダーの完全修飾ドメイン名である場合があります。デバイスは、IPアドレスまたは完全修飾ドメイン名を使用できます（および「データプロバイダーIDシリーズ」要素を「ドメイン」に設定します）。
Reason for Need: Inform the call taker of the identity of the entity providing the data.
必要性の理由：データを提供しているエンティティのIDを呼び出し担当者に通知します。
How Used by Call Taker: Where jurisdictions have lists of providers, the Data Provider ID provides useful information about the data source. The Data Provider ID uniquely identifies the source of the data, which might be needed especially during unusual circumstances and for routine logging.
Call Takerによる使用方法：管轄区域にプロバイダーのリストがある場合、データプロバイダーIDはデータソースに関する有用な情報を提供します。データプロバイダーIDは、データのソースを一意に識別します。これは、特に異常な状況や定期的なログ記録で特に必要になる場合があります。
Data Element: Data Provider ID Series
データ要素：データプロバイダーIDシリーズ
Use: Conditional. Optional for blocks supplied by the originating device; mandatory otherwise.
使用：条件付き。発信元デバイスによって提供されるブロックのオプション。それ以外の場合は必須です。
XML Element: <ProviderIDSeries>
Description: Identifies the issuer of the <ProviderID>. The "Provider ID Series" registry created in Section 11.1.1 initially contains the entries shown in Figure 1.
説明：<ProviderID>の発行者を識別します。セクション11.1.1で作成された「プロバイダーIDシリーズ」レジストリには、最初に図1に示すエントリが含まれています。
Reason for Need: Identifies how to interpret the Data Provider ID. The combination of ProviderIDSeries and ProviderID MUST be globally unique.
理由：データプロバイダーIDの解釈方法を示します。 ProviderIDSeriesとProviderIDの組み合わせは、グローバルに一意である必要があります。
How Used by Call Taker: Determines which provider ID registry to consult for more information.
Call Takerによる使用方法：詳細については、どのプロバイダーIDレジストリを参照するかを決定します。
+-----------+--------------------------+----------------------+
| Name | Source | URL |
+-----------+--------------------------+----------------------+
| NENA | National Emergency | http://www.nena.org |
| | Number Association | |
| | | |
| EENA | European Emergency | http://www.eena.org |
| | Number Association | |
| | | |
| domain | (The ID is a fully | (not applicable) |
| | qualified domain name) | |
+-----------+--------------------------+----------------------+
Figure 1: Provider ID Series Registry
図1：プロバイダーIDシリーズレジストリ
Data Element: Type of Data Provider
データ要素：データプロバイダーのタイプ
Use: Required
使用：必須
XML Element: <TypeOfProvider>
Description: Identifies the type of data provider supplying the data. The registry containing all valid values is created in Section 11.1.5, and the initial set of values is shown in Figure 2.
説明：データを提供するデータプロバイダーのタイプを識別します。すべての有効な値を含むレジストリはセクション11.1.5で作成され、値の初期セットは図2に示されています。
Reason for Need: Identifies the category of data provider.
理由：データプロバイダーのカテゴリを識別します。
How Used by Call Taker: This information can be helpful when deciding whom to contact when further information is needed.
Call Takerによる使用方法：この情報は、詳細情報が必要なときに連絡先を決定するときに役立ちます。
+------------------------------+------------------------------------+
| Token | Description |
+------------------------------+------------------------------------+
|Client | Originating client/device |
| | |
|Access Network Provider | Access network service provider |
| | |
|Telecom Provider | Telecom service provider (including|
| | native and over-the-top VoIP |
| | services) |
| | |
|Telematics Provider | A sensor-based service provider, |
| | especially vehicle based |
| | |
|Language Translation Provider | A spoken language translation |
| | service |
| | |
|Emergency Service Provider | An emergency service provider |
| | conveying information to another|
| | emergency service provider |
| | |
|Emergency Modality Translation| An emergency-call-specific |
| | modality translation service, |
| | e.g., for sign language |
| | |
|Relay Provider | An interpretation service, e.g., |
| | video relay for sign language |
| | interpretation |
| | |
|Other | Any other type of service provider |
+------------------------------+------------------------------------+
Figure 2: Type of Data Provider Registry
図2：データプロバイダーレジストリの種類
Data Element: Data Provider Contact URI
データ要素：データプロバイダー連絡先URI
Use: Required
使用：必須
XML Element: <ContactURI>
Description: When provided by a service provider or an access network provider, this information is expected to be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call. When provided by a device, this MUST be the contact information of the user or owner of the device. (Ideally, this is the contact information of the device user, but when the owner and user are separate (e.g., the device owner is an organization), this MAY be the contact information of the owner.) The Data Provider Contact URI SHOULD be a tel URI [RFC3966] in E.164 format and fully specified with a country code. If a tel URI is not available, a generic SIP URI is acceptable. Note that this contact information is not used by PSAPs for callbacks (a call from a PSAP directly related to a recently terminated emergency call, placed by the PSAP using a SIP Priority header field set to 'psap-callback', as described in [RFC7090]).
説明：この情報は、サービスプロバイダーまたはアクセスネットワークプロバイダーによって提供される場合、この緊急コールにPSAPサポートを提供するように任命された24時間年中無休のサポート組織へのURIであることが期待されます。デバイスから提供される場合、これはデバイスのユーザーまたは所有者の連絡先情報である必要があります。 （理想的には、これはデバイスユーザーの連絡先情報ですが、所有者とユーザーが異なる場合（たとえば、デバイスの所有者が組織である場合）、これは所有者の連絡先情報である場合があります。）データプロバイダーの連絡先URIはE.164形式のtel URI [RFC3966]。国コードで完全に指定されています。 tel URIが使用できない場合は、一般的なSIP URIを使用できます。 [RFC7090で説明されているように、 'psap-callback'に設定されたSIP Priorityヘッダーフィールドを使用してPSAPが発信した、最近終了した緊急コールに直接関連するPSAPからのコールは、この連絡先情報はPSAPによって使用されないことに注意してください。 ]）。
Reason for Need: Additional data providers might need to be contacted in error cases or other unusual circumstances.
理由：エラーやその他の異常な状況では、追加のデータプロバイダーに連絡する必要がある場合があります。
How Used by Call Taker: To contact the supplier of the additional data for assistance in handling the call.
コールテイカーによる使用方法：コールの処理の支援について、追加データのサプライヤに連絡する。
Data Element: Data Provider Language(s) supported
データ要素：サポートされるデータプロバイダーの言語
Use: Required
使用：必須
XML Element: <Language>
Description: This field encodes the language used by the entity at the Data Provider Contact URI. The content of this field consists of a single token from the Language Subtag Registry, which can be found at [LanguageSubtagRegistry], and is defined in [RFC5646]. Multiple instances of this element MAY occur, but the order is significant and the preferred language SHOULD appear first. The content MUST reflect the languages supported at the contact URI.
説明：このフィールドは、データプロバイダーの連絡先URIでエンティティが使用する言語をエンコードします。このフィールドの内容は、[LanguageSubtagRegistry]にある言語サブタグレジストリの単一のトークンで構成され、[RFC5646]で定義されています。この要素の複数のインスタンスが発生する可能性がありますが、順序は重要であり、優先言語を最初に表示する必要があります。コンテンツは、連絡先URIでサポートされている言語を反映する必要があります。
(Note that this field informs the PSAP of the language(s) used by the data provider. If the PSAP needs to contact the data provider, it can be helpful to know in advance the language(s) used by the data provider. If the PSAP uses a communication protocol to reach the data provider, that protocol might have language facilities of its own (such as the 'language' media feature tag, defined in RFC 3840 [RFC3840], and the more extensive language negotiation mechanism proposed in [HUMAN-LANG]), and if so, those are independent of this field.)
（このフィールドはPSAPにデータプロバイダーが使用する言語を通知することに注意してください。PSAPがデータプロバイダーに連絡する必要がある場合、データプロバイダーが使用する言語を事前に知っておくと役立ちます。 PSAPは、通信プロトコルを使用してデータプロバイダーに到達します。そのプロトコルには、独自の言語機能（「言語」メディア機能タグ、RFC 3840 [RFC3840]で定義されているものなど）、および[ HUMAN-LANG]）、そしてもしそうなら、それらはこのフィールドから独立しています。）
Reason for Need: This information indicates if the emergency service authority can directly communicate with the service provider or if an interpreter will be needed.
必要性の理由：この情報は、緊急サービス機関がサービスプロバイダーと直接通信できるかどうか、または通訳が必要かどうかを示します。
How Used by Call Taker: If the call taker cannot speak any language supported by the service provider, a translation service will need to be added to the conversation. Alternatively, other persons at the PSAP, besides the call taker, might be consulted for help (depending on the urgency and the type of interaction).
通話係による使用方法：通話係がサービスプロバイダーがサポートする言語を話せない場合は、会話に翻訳サービスを追加する必要があります。代わりに、PSAPの他の担当者が、（担当者の緊急度と種類によっては）相談を受けることもあります。
Data Element: xCard of Data Provider
データ要素：データプロバイダーのxCard
Use: Optional
使用：オプション
XML Element: <DataProviderContact>
Description: Per [RFC6351], the xCard structure is represented within a <vcard> element. Although multiple <vcard> elements can be contained in a structure, only one <vcard> element SHOULD be provided. If more than one appears, the first SHOULD be used. There are many fields in the xCard, and the creator of the data structure is encouraged to provide all available information. N, ORG, ADR, TEL, and EMAIL are suggested at a minimum. N SHOULD contain the name of the support group or device owner as appropriate. If more than one TEL property is provided, a parameter from the "vCard Property Values" registry SHOULD be specified for each TEL. For encoding of the vCard, this specification uses the XML-based encoding specified in [RFC6351], which is referred to in this document as 'xCard'.
説明：[RFC6351]に従い、xCard構造は<vcard>要素内で表されます。複数の<vcard>要素を構造体に含めることができますが、1つだけの<vcard>要素を提供する必要があります（SHOULD）。複数表示される場合は、最初のSHOULDを使用する必要があります。 xCardには多くのフィールドがあり、データ構造の作成者は利用可能なすべての情報を提供することが推奨されます。 N、ORG、ADR、TEL、およびEMAILは最低限推奨されます。 N必要に応じて、サポートグループまたはデバイスの所有者の名前を含める必要があります。複数のTELプロパティを指定する場合は、「vCardプロパティ値」レジストリのパラメーターを各TELに指定する必要があります（SHOULD）。 vCardのエンコーディングには、この仕様では[RFC6351]で指定されているXMLベースのエンコーディングを使用します。これは、このドキュメントでは「xCard」と呼ばれています。
Reason for Need: Information needed to determine additional contact information.
理由：追加の連絡先情報を決定するために必要な情報。
How Used by Call Taker: Assists the call taker by providing additional contact information aside from what is included in the SIP INVITE or the PIDF-LO.
コールテイカーによる使用方法：SIP INVITEまたはPIDF-LOに含まれているものとは別に、追加の連絡先情報を提供することにより、コールテイカーを支援します。
When the entity providing the data is a subcontractor, the Data Provider Type is set to that of the primary service provider, and this entry is supplied to provide information regarding the subcontracting entity.
データを提供するエンティティが下請け業者である場合、データプロバイダーのタイプはプライマリサービスプロバイダーのタイプに設定され、このエントリは下請け業者に関する情報を提供するために提供されます。
Data Element: Subcontractor Principal
データ要素：下請け業者プリンシパル
Use: Conditional. This data is required if the entity providing the data is a subcontractor.
使用：条件付き。このデータは、データを提供するエンティティが下請け業者である場合に必要です。
XML Element: <SubcontractorPrincipal> Description: Some providers outsource their obligations to handle aspects of emergency services to specialized providers. If the data provider is a subcontractor to another provider, this element contains the DataProviderString of the service provider to indicate which provider the subcontractor is working for.
XML要素：<SubcontractorPrincipal>説明：プロバイダーによっては、緊急サービスの側面を処理する義務を専門のプロバイダーに外部委託しています。データプロバイダーが別のプロバイダーの下請け業者である場合、この要素には、サービスプロバイダーのDataProviderStringが含まれ、下請け業者が作業しているプロバイダーを示します。
Reason for Need: Identify the entity the subcontractor works for.
理由：下請業者が働いているエンティティを特定します。
How Used by Call Taker: Allows the call taker to understand what the relationship is between data providers and the service providers in the path of the call.
コールテイカーによる使用方法：コールテイカーは、コールのパスにおけるデータプロバイダーとサービスプロバイダーの関係を理解できます。
Data Element: Subcontractor Priority
データ要素：下請け業者の優先順位
Use: Conditional. This data is required if the entity providing the data is a subcontractor.
使用：条件付き。このデータは、データを提供するエンティティが下請け業者である場合に必要です。
XML Element: <SubcontractorPriority>
Description: If the subcontractor is supposed to be contacted first, then this element MUST have the value 'sub'. If the provider the subcontractor is working for is supposed to be contacted first, then this element MUST have the value 'main'.
説明：下請け業者に最初に連絡することになっている場合、この要素の値は「sub」でなければなりません。下請業者が働いているプロバイダーが最初に連絡されることになっているならば、この要素は値「メイン」を持たなければなりません。
Reason for Need: Inform the call taker whom to contact first, if support is needed.
必要性の理由：サポートが必要な場合は、最初に誰に連絡するかを担当者に伝えます。
How Used by Call Taker: To decide which entity to contact first if assistance is needed.
Call Takerによる使用方法：支援が必要な場合に最初に連絡するエンティティを決定します。
<?xml version="1.0" encoding="UTF-8"?>
<ad:EmergencyCallData.ProviderInfo
xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<ad:DataProviderReference>string0987654321@example.org
</ad:DataProviderReference>
<ad:DataProviderString>Example VoIP Provider
</ad:DataProviderString>
<ad:ProviderID>urn:nena:companyid:ID123</ad:ProviderID>
<ad:ProviderIDSeries>NENA</ad:ProviderIDSeries>
<ad:TypeOfProvider>Telecom Provider</ad:TypeOfProvider>
<ad:ContactURI>tel:+1-201-555-0123</ad:ContactURI>
<ad:Language>en</ad:Language>
<ad:DataProviderContact
xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Hannes Tschofenig</text></fn>
<n>
<surname>Hannes</surname>
<given>Tschofenig</given>
<additional/>
<prefix/>
<suffix>Dipl. Ing.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>de</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<org>
<parameters><type><text>work</text></type>
</parameters>
<text>Example VoIP Provider</text>
</org>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Hannes Tschofenig
Linnoitustie 6
Espoo , Finland
02600</text></label>
</parameters>
<pobox/>
<ext/>
<street>Linnoitustie 6</street>
<locality>Espoo</locality>
<region>Uusimaa</region>
<code>02600</code>
<country>Finland</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 4871445</uri>
</tel>
<tel>
<parameters>
<type>
<text>work</text>
<text>main-number</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 5050505</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>hannes.tschofenig@nsn.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:60.210796,24.812924</uri>
</geo>
<key>
<parameters><type><text>home</text></type>
</parameters>
<uri>
http://www.example.com/key.asc
</uri>
</key>
<tz><text>Finland/Helsinki</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://www.tschofenig.priv.at</uri>
</url>
</vcard>
</ad:DataProviderContact>
</ad:EmergencyCallData.ProviderInfo>
Figure 3: EmergencyCallData.ProviderInfo Example
図3：EmergencyCallData.ProviderInfoの例
This block describes the service that the service provider provides to the caller. It SHOULD be included by all service providers in the path of the call. The MIME media type is 'application/ EmergencyCallData.ServiceInfo+xml'.
このブロックは、サービスプロバイダーが発信者に提供するサービスを記述します。すべてのサービスプロバイダーがコールのパスに含める必要があります。 MIMEメディアタイプは「application / EmergencyCallData.ServiceInfo + xml」です。
Data Element: Service Environment
データ要素：サービス環境
Use: Conditional. Required unless the 'ServiceType' value is 'wireless'.
使用：条件付き。 「ServiceType」値が「wireless」でない限り、必須です。
XML Element: <ServiceEnvironment>
Description: This element indicates whether a call is from a business or residence. Currently, the only valid entries are 'Business', 'Residence', and 'Unknown', as shown in Figure 4. New values can be defined via the registry created in Section 11.1.2.
説明：この要素は、通話が会社または住宅からのものかどうかを示します。現在、有効なエントリは、「ビジネス」、「居住地」、「不明」のみです。図4を参照してください。新しい値は、セクション11.1.2で作成したレジストリを介して定義できます。
Reason for Need: To provide context and a hint when determining equipment and manpower requirements.
必要性の理由：設備と人員の要件を決定するときにコンテキストとヒントを提供するため。
How Used by Call Taker: Information can be used to provide context and a hint to assist in determining equipment and manpower requirements for emergency responders. This is non-authoritative; there are situations where the service provider does not know the type of service (e.g., anonymous prepaid service). The type of service does not necessarily reflect the nature of the premises (e.g., a business line installed in a residence or cellular service). The registry does not contain all possible values for all situations. Hence, this is at best advisory information, but since it mimics a similar capability in some current emergency calling systems (e.g., a field in the Automatic Location Information (ALI) used with legacy North American wireline systems), it is known to be valuable to PSAPs. The service provider uses its best information (such as a rate plan, facilities used to deliver service, or a service description) to determine the information and is not responsible for determining the actual characteristics of the location from which the call originated. Because the usefulness is unknown (and less clear) for cellular, this element is OPTIONAL for commercial mobile radio services (e.g., cellular) and REQUIRED otherwise.
Call Takerによる使用方法：情報を使用して、緊急応答者の機器と人員の要件を決定するのに役立つコンテキストとヒントを提供できます。これは権限がありません。サービスプロバイダーがサービスの種類を知らない状況があります（匿名の前払いサービスなど）。サービスのタイプは、必ずしも施設の性質を反映しているわけではありません（たとえば、住宅または携帯電話サービスに設置されたビジネスライン）。レジストリには、すべての状況で考えられるすべての値が含まれているわけではありません。したがって、これはせいぜい助言情報ですが、一部の現在の緊急通報システム（たとえば、従来の北米の有線システムで使用される自動位置情報（ALI）のフィールド）で同様の機能を模倣しているため、価値があることが知られていますPSAPに。サービスプロバイダーは、最適な情報（料金プラン、サービスの提供に使用される施設、サービスの説明など）を使用して情報を決定しますが、通話の発信元の場所の実際の特性を決定する責任はありません。セルラーの有用性は不明（そしてあまり明確ではない）であるため、この要素は商用のモバイルラジオサービス（セルラーなど）のオプションであり、それ以外の場合は必須です。
+-----------+--------------------------+
| Token | Description |
+-----------+--------------------------+
| Business | Business service |
| | |
| Residence | Residential service |
| | |
| Unknown | Type of service unknown |
| | (e.g., anonymous pre- |
| | paid service) |
+-----------+--------------------------+
Figure 4: Service Environment Registry
図4：サービス環境レジストリ
Data Element: Service Delivered by Provider to End User
データ要素：プロバイダーによってエンドユーザーに提供されるサービス
Use: Required
使用：必須
XML Element: <ServiceType>
Description: This defines the type of service over which the call is placed (similar to the Class of Service delivered with legacy emergency calls in some regions). The implied mobility of this service cannot be relied upon. A registry is created in Section 11.1.3. The initial set of values is shown in Figure 5. More than one value MAY be returned. For example, a VoIP inmate telephone service is a reasonable combination.
説明：これは、コールが発信されるサービスのタイプを定義します（一部の地域でレガシー緊急コールで提供されるサービスクラスと同様）。このサービスの暗黙のモビリティは信頼できません。レジストリはセクション11.1.3で作成されます。値の初期セットを図5に示します。複数の値が返される場合があります。たとえば、VoIP収容電話サービスは合理的な組み合わせです。
Reason for Need: Knowing the type of service can assist the PSAP in the handling of the call.
必要性の理由：サービスのタイプを知ることは、PSAPがコールを処理するのに役立ちます。
How Used by Call Taker: Call takers often use this information to determine what kinds of questions to ask callers and how much to rely on supportive information. As the information is not always available, and the registry is not all encompassing, this is at best advisory information, but since it mimics a similar capability in some legacy emergency calling systems, it is known to be valuable.
コールテイカーの使用方法：コールテイカーは、この情報を使用して、発信者に尋ねる質問の種類と、サポート情報にどれだけ依存するかを決定します。情報は常に利用可能であるわけではなく、レジストリもすべて網羅しているわけではないため、これはせいぜい勧告的な情報ですが、一部のレガシー緊急呼び出しシステムの同様の機能を模倣しているため、貴重であることがわかっています。
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| wireless | Wireless Telephone Service: Includes |
| | CDMA, GSM, Wi-Fi, WiMAX, and LTE |
| | (but not satellite) |
| | |
| coin | Fixed public pay/coin telephones: Any |
| | device operated by coin or credit card |
| | |
| one-way | One-way outbound service |
| | |
| temp | Soft dial tone/quick service/warm |
| | disconnect/suspended |
| | |
| MLTS-hosted | Hosted multi-line telephone system |
| | such as Centrex |
| | |
| MLTS-local | Local multi-line telephone system, |
| | including all PBXs, key systems, and |
| | Shared Tenant Services |
| | |
| sensor- | These are devices that generate DATA |
| unattended | ONLY. This is a one-way information |
| | transmit without interactive media. |
| | |
| sensor- | Devices that are supported by a |
| attended | monitoring service provider or that |
| | are capable of supporting interactive |
| | media |
| | |
| POTS | Wireline: Plain Old Telephone Service |
| | |
| OTT | An over-the-top service that provides |
| | communication over arbitrary Internet |
| | access (fixed, nomadic, mobile) |
| | |
| digital | Wireline non-OTT digital phone service |
| | |
| OPX | Off-premise extension |
| | |
| relay | A service where a human third-party |
| | agent provides additional assistance. |
| | This includes sign language relay/ |
| | interpretation, telematics services |
| | that provide a human on the call, |
| | and similar services. |
+--------------+------------------------------------------+
Figure 5: Service Delivered by Provider to End User Registry
図5：プロバイダーがエンドユーザーレジストリに提供するサービス
The initial set of values has been collected from sources of currently used systems, including [NENA-02-010], [nc911], [NANP], and [LERG].
初期値のセットは、[NENA-02-010]、[nc911]、[NANP]、[LERG]など、現在使用されているシステムのソースから収集されています。
Data Element: Service Mobility Environment
データ要素：サービスモビリティ環境
Use: Required
使用：必須
XML Element: <ServiceMobility>
Description: This provides the service provider's view of the mobility of the caller's device. As the service provider might not know the characteristics of the actual device or access network used, the value should be treated as advisory and not be relied upon. A registry is created in Section 11.1.4 with the initial valid entries shown in Figure 6.
説明：これは、発信者のデバイスのモビリティに関するサービスプロバイダーのビューを提供します。サービスプロバイダーは、使用される実際のデバイスまたはアクセスネットワークの特性を知らない可能性があるため、値は助言として取り扱われ、信頼されるべきではありません。レジストリはセクション11.1.4で作成され、図6に示す初期の有効なエントリが含まれています。
Reason for Need: Knowing the service provider's belief of mobility can assist the PSAP with the handling of the call.
理由：サービスプロバイダーのモビリティに対する信念を理解していると、PSAPがコールを処理するのに役立ちます。
How Used by Call Taker: To determine whether to assume the location of the caller might change.
Call Takerによる使用方法：発信者の場所が変わる可能性があると想定するかどうかを決定する。
+-----------+----------------------------+
| Token | Description |
+-----------+----------------------------+
| Mobile | The device is able to move |
| | at any time |
| | |
| Fixed | The device is not expected |
| | to move unless the |
| | service is relocated |
| | |
| Nomadic | The device is not expected |
| | to change its point of |
| | attachment while on a |
| | call |
| | |
| Unknown | No information is known |
| | about the service |
| | mobility environment for |
| | the device |
+-----------+----------------------------+
Figure 6: Service Mobility Registry
図6：サービスモビリティレジストリ
<?xml version="1.0" encoding="UTF-8"?>
<svc:EmergencyCallData.ServiceInfo
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo">
<svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org
</svc:DataProviderReference>
<svc:ServiceEnvironment>Business</svc:ServiceEnvironment>
<svc:ServiceType>MLTS-hosted</svc:ServiceType>
<svc:ServiceMobility>Fixed</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo>
Figure 7: EmergencyCallData.ServiceInfo Example
図7：EmergencyCallData.ServiceInfoの例
This block provides information about the device used to place the call. It SHOULD be provided by any service provider that knows what device is being used and by the device itself. The MIME media type is 'application/EmergencyCallData.DeviceInfo+xml'.
このブロックは、電話をかけるために使用されるデバイスに関する情報を提供します。どのデバイスが使用されているかを知っている任意のサービスプロバイダーとデバイス自体によって提供される必要があります。 MIMEメディアタイプは「application / EmergencyCallData.DeviceInfo + xml」です。
Data Element: Device Classification
データ要素：デバイス分類
Use: Optional
使用：オプション
XML Element: <DeviceClassification>
Description: This data element defines the kind of device making the emergency call. If the device provides the data structure, the device information SHOULD be provided. If the service provider provides the structure and it knows what the device is, the service provider SHOULD provide the device information. Often the carrier does not know what the device is. It is possible to receive two Device Information blocks: one provided by the device and one from the service provider. This information describes the device, not how it is being used. This data element defines the kind of device making the emergency call. A registry is created in Section 11.1.6 with the initial set of values as shown in Figure 8.
説明：このデータ要素は、緊急通話を行うデバイスの種類を定義します。デバイスがデータ構造を提供する場合、デバイス情報を提供する必要があります（SHOULD）。サービスプロバイダーが構造を提供し、デバイスが何であるかを知っている場合、サービスプロバイダーはデバイス情報を提供する必要があります（SHOULD）。多くの場合、キャリアはデバイスが何であるかを知りません。 2つのデバイス情報ブロックを受信することが可能です。1つはデバイスによって提供され、もう1つはサービスプロバイダーから提供されます。この情報は、デバイスの使用方法ではなく、デバイスの説明です。このデータ要素は、緊急コールを発信するデバイスの種類を定義します。レジストリはセクション11.1.6で作成され、図8に示すように初期値のセットが含まれます。
Reason for Need: The device classification implies the capability of the calling device and assists in identifying the meaning of the emergency call location information that is being presented. For example, does the device require human intervention to initiate a call, or is this call the result of programmed instructions? Does the calling device have the ability to update location or condition changes? Is this device interactive or a one-way reporting device?
必要性の理由：デバイスの分類は、発信側デバイスの機能を意味し、提示されている緊急コールのロケーション情報の意味を特定するのに役立ちます。たとえば、デバイスは通話を開始するために人間の介入を必要としますか、それともこの通話はプログラムされた命令の結果ですか？発信側デバイスには、場所や状態の変更を更新する機能がありますか？このデバイスはインタラクティブですか、それとも一方向のレポートデバイスですか？
How Used by Call Taker: Can provide the call taker context regarding the caller, the capabilities of the calling device, or the environment in which the device is being used and can assist in understanding the location information and capabilities of the calling device. For example, a cordless handset might be outside or next door.
コールテイカーによる使用方法：発信者、発信側デバイスの機能、またはデバイスが使用されている環境に関するコールテイカーコンテキストを提供でき、発信側デバイスのロケーション情報と機能の理解に役立ちます。たとえば、コードレスハンドセットは、屋外または隣にあります。
+---------------+----------------------------------------+
| Token | Description |
+---------------+----------------------------------------+
|cordless | Cordless handset |
|fixed | Fixed phone |
|satellite | Satellite phone |
|sensor-fixed | Fixed (non-mobile) sensor/alarm device |
|desktop | Soft client on desktop PC |
|laptop | Soft client on laptop-type device |
|tablet | Soft client on tablet-type device |
|alarm-monitored| Alarm system |
|sensor-mobile | Mobile sensor device |
|aircraft | Aircraft telematics device |
|automobile | Automobile/cycle/off-road telematics |
|truck | Truck/construction telematics |
|farm | Farm equipment telematics |
|marine | Marine telematics |
|personal | Personal telematics device |
|feature-phone | Cellular feature phone (not smartphone)|
|smart-phone | Cellular smartphone (native) |
|smart-phone-app| Soft client app on smartphone |
|unknown-device | Soft client on unknown device type |
|game | Gaming console |
|text-only | Other text device |
|NA | Not Available |
+---------------+----------------------------------------+
Figure 8: Device Classification Registry Initial Values
図8：デバイス分類レジストリの初期値
Data Element: Device Manufacturer
データ要素：デバイスメーカー
Use: Optional
使用：オプション
XML Element: <DeviceMfgr> Description: The plain language name of the manufacturer of the device.
XML要素：<DeviceMfgr>説明：デバイスの製造元のわかりやすい言語名。
Reason for Need: Used by PSAP management for post-mortem investigation/resolution.
理由：死後の調査/解決のためにPSAP管理によって使用されます。
How Used by Call Taker: Probably not used by the call taker but by PSAP management.
コールテイカーによる使用方法：おそらくコールテイカーではなく、PSAP管理によって使用されます。
Data Element: Device Model Number
データ要素：デバイスモデル番号
Use: Optional
使用：オプション
XML Element: <DeviceModelNr>
Description: Model number of the device.
説明：デバイスのモデル番号。
Reason for Need: Used by PSAP management for after-action investigation/resolution.
必要性の理由：PSAP管理者による、事後調査/解決のために使用されます。
How Used by Call Taker: Probably not used by the call taker but by PSAP management.
コールテイカーによる使用方法：おそらくコールテイカーではなく、PSAP管理によって使用されます。
Data Element: Unique Device Identifier
データ要素：一意のデバイス識別子
Use: Optional
使用：オプション
XML Element: <UniqueDeviceID>
XML Attribute: <TypeOfDeviceID>
Description: A string that identifies the specific device (or the device's current Subscriber Identification Module (SIM)) making the call or creating an event. Note that more than one <UniqueDeviceID> can be present to supply more than one of the identifying values.
説明：呼び出しまたはイベントを作成している特定のデバイス（またはデバイスの現在の加入者識別モジュール（SIM））を識別する文字列。複数の<UniqueDeviceID>が存在して、複数の識別値を提供できることに注意してください。
The <TypeOfDeviceID> attribute identifies the type of device identifier. A registry is created in Section 11.1.7 with an initial set of values shown in Figure 9.
<TypeOfDeviceID>属性は、デバイス識別子のタイプを識別します。レジストリはセクション11.1.7で作成され、初期値のセットが図9に示されています。
Reason for Need: Uniquely identifies the device (or, in the case of International Mobile Subscriber Identity (IMSI), a SIM), independent of any signaling identifiers present in the call signaling stream.
理由：コールシグナリングストリームに存在するシグナリング識別子とは無関係に、デバイス（または国際モバイル加入者識別（IMSI）の場合はSIM）を一意に識別します。
How Used by Call Taker: Probably not used by the call taker; might be used by PSAP management during an investigation. (For example, if a PSAP experiences repeated false/accidental calls and there is no callback number or it isn't usable, the PSAP might need to try to track down the device using various means, e.g., contacting service providers in the area.) In the case of handsets without current service, it might be possible to determine who last had service. Another example might be a disconnected call where the call taker believes there is a need for assistance but was not able to obtain a location or other information.
通話係による使用方法：通話係によって使用されていない可能性があります。調査中にPSAP管理によって使用される場合があります。 （たとえば、PSAPで誤ったコールや偶発的なコールが繰り返し発生し、コールバック番号がない場合や使用できない場合、PSAPは、エリア内のサービスプロバイダーに連絡するなど、さまざまな手段を使用してデバイスを追跡する必要がある場合があります。 ）現在のサービスを受けていない携帯電話の場合、だれが最後にサービスを受けたのかを特定できる可能性があります。別の例としては、通話の切断者がサポートの必要性を認識しているが、場所やその他の情報を取得できなかった場合の通話の切断があります。
Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID>
+--------+------------------------------------------+
| Token | Description |
+--------+------------------------------------------+
| MEID | Mobile Equipment Identifier (CDMA) |
| ESN | Electronic Serial Number (GSM) |
| MAC | Media Access Control Address (IEEE) |
| WiMAX | Device Certificate Unique ID |
| IMEI | International Mobile Equipment ID (GSM) |
| IMSI | International Mobile Subscriber ID (GSM) |
| UDI | Unique Device Identifier |
| RFID | Radio Frequency Identification |
| SN | Manufacturer Serial Number |
+--------+------------------------------------------+
Figure 9: Registry of Device Identifier Types
図9：デバイス識別子タイプのレジストリ
Data Element: Device/service-specific additional data structure
データ要素：デバイス/サービス固有の追加データ構造
Use: Optional
使用：オプション
XML Element: <DeviceSpecificData>
Description: A URI representing additional data whose schema is specific to the device or service that created it. (For example, a medical device or medical device monitoring service might have a defined set of medical data.) The URI, when dereferenced, MUST yield a data structure defined by the device/service-specific additional data type value. Different data can be created by each classification, e.g., a data set created by a medical device.
説明：スキーマがそのデータを作成したデバイスまたはサービスに固有の追加データを表すURI。 （たとえば、医療機器または医療機器監視サービスには、定義された医療データのセットがある場合があります。）URIが逆参照されると、デバイス/サービス固有の追加のデータ型値によって定義されたデータ構造を生成する必要があります。医療機器によって作成されたデータセットなど、分類ごとに異なるデータを作成できます。
Reason for Need: Provides device/service-specific data that can be used by the call taker and/or responders.
理由の理由：呼び出し担当者や応答者が使用できるデバイス/サービス固有のデータを提供します。
How Used by Call Taker: Provide information to guide call takers to select appropriate responders, give appropriate pre-arrival instructions to callers, and advise responders of what to be prepared for. May be used by responders to guide assistance provided.
コールテイカーによる使用方法：適切なレスポンダを選択するためのコールテイクをガイドする情報を提供し、発信者に適切な到着前の指示を与え、準備するものについてレスポンダにアドバイスします。レスポンダーが提供された支援をガイドするために使用できます。
Data Element: Type of device/service-specific additional data structure
データ要素：デバイス/サービス固有の追加データ構造のタイプ
Use: Conditional. MUST be provided when a device/service-specific additional data URI is provided.
使用：条件付き。デバイス/サービス固有の追加データURIを提供する場合は、提供する必要があります。
XML Element: <DeviceSpecificType>
Description: A value from the registry defined in Section 11.1.8 to describe the type of data located at the device/service-specific additional data structure. The initial values shown in Figure 10 currently only include IEEE 1512, which is the United States Department of Transportation (USDoT) model for traffic incidents.
説明：デバイス/サービス固有の追加データ構造にあるデータのタイプを説明するためにセクション11.1.8で定義されたレジストリからの値。図10に示す初期値には、現在、交通事故の米国運輸省（USDoT）モデルであるIEEE 1512のみが含まれています。
Reason for Need: This data element allows identification of externally defined schemas, which might have additional data that can assist in emergency response.
理由：このデータ要素を使用すると、外部で定義されたスキーマを識別できます。スキーマには、緊急応答に役立つ追加のデータが含まれている場合があります。
How Used by Call Taker: This data element allows the end user (call taker or first responder) to know what type of additional data is available to aid in providing the needed emergency services.
コールテイカーによる使用方法：このデータ要素により、エンドユーザー（コールテイカーまたはファーストレスポンダー）は、必要な緊急サービスの提供を支援するために利用できる追加データのタイプを知ることができます。
Note: This mechanism is not appropriate for information specific to a location or a caller (person).
注：このメカニズムは、場所または発信者（個人）に固有の情報には適していません。
+---------+---------------------------+--------------------------+
| Token | Description | Specification |
+---------+---------------------------+--------------------------+
|IEEE1512 |Common Incident Management | IEEE 1512-2006 |
| | Message Set (USDoT model | |
| | for traffic incidents) | |
+---------+---------------------------+--------------------------+
Figure 10: Device/Service Data Type Registry
図10：デバイス/サービスデータタイプレジストリ
The IEEE 1512-2006 specifications can be found at [IEEE-1512-2006].
IEEE 1512-2006仕様は、[IEEE-1512-2006]にあります。
<?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo
xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference>d4b3072df.201409182208075@example.org
</dev:DataProviderReference>
<dev:DeviceClassification>fixed</dev:DeviceClassification>
<dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
<dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104
</dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo>
Figure 11: EmergencyCallData.DeviceInfo Example
図11：EmergencyCallData.DeviceInfoの例
This block describes the owner of the device (if provided by the device) or the subscriber information (if provided by a service provider). The contact location is not necessarily the location of the caller or incident but is rather the nominal contact address. The MIME media type is 'application/ EmergencyCallData.SubscriberInfo+xml'.
このブロックは、デバイスの所有者（デバイスによって提供される場合）またはサブスクライバー情報（サービスプロバイダーによって提供される場合）を記述します。連絡先の場所は、必ずしも発信者またはインシデントの場所ではなく、名目上の連絡先アドレスです。 MIMEメディアタイプは「application / EmergencyCallData.SubscriberInfo + xml」です。
In some jurisdictions, some or all parts of the subscriber-specific information are subject to privacy constraints. These constraints vary but dictate which information can be displayed and logged. A general privacy indicator expressing a desire for privacy by the subscriber is provided. The interpretation of how this is applied is left to the receiving jurisdiction as the custodians of the local regulatory requirements. This matches an equivalent privacy flag provided in some legacy emergency call systems.
一部の法域では、加入者固有の情報の一部またはすべての部分がプライバシーの制約の対象となります。これらの制約はさまざまですが、どの情報を表示およびログできるかを決定します。加入者によるプライバシーの欲求を表す一般的なプライバシー指標が提供されます。これがどのように適用されるかの解釈は、現地の規制要件の管理者として受取り管轄に委ねられています。これは、一部のレガシー緊急コールシステムで提供されている同等のプライバシーフラグと一致します。
Attribute: 'privacyRequested', Boolean.
属性： 'privacyRequested'、ブール。
Use: Conditional. This attribute MUST be provided if the owner/ subscriber information block is not empty.
使用：条件付き。この属性は、所有者/サブスクライバー情報ブロックが空でない場合に提供する必要があります。
Description: The subscriber data privacy indicator specifically expresses the subscriber's desire for privacy. In some jurisdictions, subscriber services can have a specific "Type of Service" that prohibits information, such as the name of the subscriber, from being displayed. This attribute is provided to explicitly indicate whether the subscriber service includes such constraints. The interpretation of this indicator is left to each jurisdiction (in keeping with the semantics of the privacy indicator provided in some legacy emergency call systems). Because the interpretation of this indicator varies based on local regulations, this document cannot describe the exact semantics nor indicate which fields are affected (the application of this indicator might affect the display of data contained in any of the blocks).
説明：サブスクライバーデータプライバシーインジケーターは、プライバシーに対するサブスクライバーの要望を具体的に表します。一部の管轄区域では、サブスクライバーサービスに、サブスクライバーの名前などの情報の表示を禁止する特定の "サービスの種類"を設定できます。この属性は、サブスクライバーサービスにそのような制約が含まれているかどうかを明示的に示すために提供されます。このインジケーターの解釈は各管轄区域に任されています（一部のレガシー緊急呼び出しシステムで提供されるプライバシーインジケーターのセマンティクスに合わせて）。このインジケーターの解釈は地域の規制に基づいて異なるため、このドキュメントでは正確なセマンティクスを説明することも、影響を受けるフィールドを示すこともできません（このインジケーターのアプリケーションは、ブロックのいずれかに含まれるデータの表示に影響する可能性があります）。
Reason for Need: Some jurisdictions require subscriber privacy to be observed when processing emergency calls.
必要性の理由：管轄区域によっては、緊急通話を処理するときに加入者のプライバシーを守る必要があります。
How Used by Call Taker: Where privacy is indicated, the call taker might not have access to some aspects of the subscriber information.
Call Takerによる使用方法：プライバシーが示されている場合、Call Takerはサブスクライバー情報の一部の側面にアクセスできない場合があります。
Data Element: xCard for Subscriber's Data
データ要素：サブスクライバーのデータのxCard
Use: Conditional. Subscriber data MUST be provided unless it is not available. Some services, such as prepaid phones, non-initialized phones, etc., do not have information about the subscriber.
使用：条件付き。加入者データが利用できない場合を除き、提供する必要があります。プリペイド電話、初期化されていない電話などの一部のサービスには、加入者に関する情報がありません。
XML Element: <SubscriberData>
Description: Information known by the service provider or device about the subscriber, e.g., Name, Address, Individual Telephone Number, Main Telephone Number, and any other data. <n>, <org> (if appropriate), <adr>, <tel>, and <email> are suggested at a minimum. If more than one <tel> property is provided, a parameter from the "vCard Property Values" registry MUST be specified on each <tel>. While some data (such as <anniversary>) might not seem obviously relevant for emergency services, any data is potentially useful in some emergency circumstances.
説明：名前、住所、個人の電話番号、メインの電話番号、およびその他のデータなど、サービスプロバイダーまたはデバイスが加入者について知っている情報。 <n>、<org>（該当する場合）、<adr>、<tel>、および<email>が最低限推奨されます。複数の<tel>プロパティを指定する場合は、「vCardプロパティ値」レジストリのパラメーターを各<tel>で指定する必要があります。一部のデータ（<記念日>など）は緊急サービスに明らかに関連していないように見える場合がありますが、緊急事態ではデータが役立つ可能性があります。
Reason for Need: When the caller is unable to provide information, this data can be used to obtain it.
理由：発信者が情報を提供できない場合、このデータを使用して情報を取得できます。
How Used by Call Taker: Obtaining critical information about the caller and possibly the location when it is not able to be obtained otherwise. While the location here is not necessarily that of a caller, in some circumstances it can be helpful in locating the caller when other means have failed.
Call Takerによる使用方法：発信者に関する重要な情報を取得し、他の方法では取得できない場合は場所を取得します。ここでの場所は必ずしも発信者の場所ではありませんが、状況によっては、他の手段が失敗したときに発信者を見つけるのに役立つ場合があります。
<?xml version="1.0" encoding="UTF-8"?>
<sub:EmergencyCallData.SubscriberInfo
xmlns:sub=
"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
privacyRequested="false">
<sub:DataProviderReference>FEABFECD901@example.org
</sub:DataProviderReference>
<sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Simon Perreault</text></fn>
<n>
<surname>Perreault</surname>
<given>Simon</given>
<additional/>
<prefix/>
<suffix>ing. jr</suffix>
<suffix>M.Sc.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>fr</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<org>
<parameters><type><text>work</text></type>
</parameters>
<text>Viagenie</text>
</org>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Simon Perreault
2875 boul. Laurier, suite D2-630
Quebec, QC, Canada
G1V 2M2</text></label>
</parameters>
<pobox/>
<ext/>
<street>2875 boul. Laurier,
suite D2-630</street>
<locality>Quebec</locality>
<region>QC</region>
<code>G1V 2M2</code>
<country>Canada</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+1-418-656-9254;ext=102</uri>
</tel>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
<text>main-number</text>
</type>
</parameters>
<uri>tel:+1-418-555-0000</uri>
</tel>
<tel>
<parameters>
<type>
<text>work</text>
<text>text</text>
<text>voice</text>
<text>cell</text>
<text>video</text>
</type>
</parameters>
<uri>tel:+1-418-262-6501</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>simon.perreault@viagenie.ca</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:46.766336,-71.28955</uri>
</geo>
<key>
<parameters><type><text>work</text></type>
</parameters>
<uri>
http://www.viagenie.ca/simon.perreault/simon.asc
</uri>
</key>
<tz><text>America/Montreal</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://nomis80.org</uri>
</url>
</vcard>
</sub:SubscriberData>
</sub:EmergencyCallData.SubscriberInfo>
Figure 12: EmergencyCallData.SubscriberInfo Example
図12：EmergencyCallData.SubscriberInfoの例
This block provides a mechanism for the data provider to supply extra, human-readable information to the PSAP. It is not intended for a general purpose extension mechanism nor does it aim to provide machine-readable content. The MIME media type is 'application/ EmergencyCallData.Comment+xml'.
このブロックは、データプロバイダーがPSAPに人間が読める追加情報を提供するメカニズムを提供します。これは、汎用の拡張メカニズムを対象としたものではなく、機械で読み取り可能なコンテンツを提供することも目的としていません。 MIMEメディアタイプは「application / EmergencyCallData.Comment + xml」です。
Data Element: EmergencyCallData.Comment
データ要素：EmergencyCallData.Comment
Use: Optional
使用：オプション
XML Element: <Comment>
Description: Human-readable text providing additional information to the PSAP staff.
説明：PSAPスタッフに追加情報を提供する人間が読めるテキスト。
Reason for Need: Explanatory information for values in the data structure.
理由：データ構造の値の説明情報。
How Used by Call Taker: To interpret the data provided.
Call Takerによる使用方法：提供されたデータを解釈します。
<?xml version="1.0" encoding="UTF-8"?>
<com:EmergencyCallData.Comment
xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment">
<com:DataProviderReference>string0987654321@example.org
</com:DataProviderReference>
<com:Comment xml:lang="en">This is an example text.</com:Comment>
</com:EmergencyCallData.Comment>
Figure 13: EmergencyCallData.Comment Example
図13：EmergencyCallData.Commentの例
This document describes two mechanisms that allow extension of the kind of data provided with an emergency call: define a new block or define a new device/service-specific additional data URL for the DeviceInfo block (Section 4.3.5). While defining new data types and getting a new device or application to send the new data might be easy, getting PSAPs and responders to actually retrieve the data and use it will be difficult. New mechanism providers should understand that acquiring and using new forms of data usually require software upgrades at the PSAP and/or responders, as well as training of call takers and responders in how to interpret and use the information. Legal and operational review might also be needed. Overwhelming a call taker or responder with too much information is highly discouraged. Thus, the barrier to supporting new data is quite high.
このドキュメントでは、緊急呼び出しで提供される種類のデータの拡張を可能にする2つのメカニズムについて説明します。新しいブロックを定義するか、DeviceInfoブロックの新しいデバイス/サービス固有の追加データURLを定義します（4.3.5項）。新しいデータタイプを定義し、新しいデバイスまたはアプリケーションで新しいデータを送信することは簡単ですが、PSAPとレスポンダーが実際にデータを取得して使用することは困難です。新しいメカニズムプロバイダーは、新しい形式のデータを取得して使用するには、通常、PSAPまたはレスポンダー、あるいはその両方でのソフトウェアのアップグレード、および情報の解釈と使用方法に関する呼び出し担当者とレスポンダーのトレーニングが必要であることを理解する必要があります。法的および運用上のレビューも必要になる場合があります。情報量が多すぎて、コールテイカーまたはレスポンダを圧倒することは、お勧めできません。したがって、新しいデータをサポートするための障壁は非常に高くなります。
The mechanisms this document describes are meant to encourage development of widely supported, common data formats for classes of devices. If all manufacturers of a class of device use the same format, and the data can be shown to improve outcomes, then PSAPs and responders can be encouraged to upgrade their systems and train their staff to use the data. Variations, however well intentioned, are unlikely to be supported.
このドキュメントで説明するメカニズムは、デバイスのクラスで広くサポートされている一般的なデータ形式の開発を促進することを目的としています。デバイスのクラスのすべての製造元が同じ形式を使用し、データを表示して結果を改善できる場合、PSAPと応答者はシステムをアップグレードし、データを使用するようにスタッフをトレーニングすることを奨励できます。バリエーションは、どのように意図されていても、サポートされる可能性は低いです。
Implementors should consider that data from sensor-based devices in some cases might not be useful to call takers or PSAPs (and privacy, liability, or other considerations might preclude the PSAP from accessing or handling the data) but might be of use to responders. Each data item provided with the call in conformance with this document can be accessed by responders or other entities in the emergency services, whether or not the data is accessed by the PSAP.
実装者は、場合によってはセンサーベースのデバイスからのデータが通話者やPSAPに役立たない場合があり（プライバシー、責任、またはその他の考慮事項により、PSAPがデータにアクセスまたは処理できない場合がある）、応答者にとって役立つ場合があることを考慮する必要があります。 PSAPがデータにアクセスするかどうかに関係なく、このドキュメントに準拠してコールで提供される各データアイテムには、緊急サービスの応答者または他のエンティティがアクセスできます。
5.1. Choosing between Defining a New Type of Block or a New Type of Device/Service-Specific Additional Data
5.1. 新しいタイプのブロックを定義するか、新しいタイプのデバイス/サービス固有の追加データを定義するかの選択
For devices that have device- or service-specific data, there are two choices to carry it. A new block can be defined, or the device/ service-specific additional data URL in the DeviceInfo block can be used and a new type defined for it. The data passed would likely be the same in either case. Considerations for choosing the mechanism under which to register include:
デバイス固有またはサービス固有のデータを持つデバイスの場合、それを実行するには2つの選択肢があります。新しいブロックを定義するか、DeviceInfoブロックのデバイス/サービス固有の追加データURLを使用して、新しいタイプを定義できます。渡されるデータは、どちらの場合も同じになる可能性があります。登録するメカニズムを選択する際の考慮事項は次のとおりです。
Applicability: Information that will be supported by many kinds of devices or services are more appropriately defined as separate blocks.
適用性：多くの種類のデバイスまたはサービスでサポートされる情報は、個別のブロックとしてより適切に定義されます。
Privacy: Information sent as a device/service-specific additional data URL in the DeviceInfo block is by reference (not by value), which inherently provides some additional privacy protection (since the requester needs to supply a certificate which is verified by the supplier).
プライバシー：DeviceInfoブロックのデバイス/サービス固有の追加データURLとして送信される情報は参照によるもので（値ではなく）、本質的にいくつかの追加のプライバシー保護を提供します（リクエスターはサプライヤーによって検証された証明書を提供する必要があるため） 。
Size: Information that can be very large might be better sent in the DeviceInfo block, rather than in a new block, so that implementations are unable to send the data by value. Conversely, data that is small might best be sent in a separate block so that it can be sent by value.
サイズ：非常に大きくなる可能性のある情報は、新しいブロックではなくDeviceInfoブロックで送信する方がよい場合があります。これにより、実装は値でデータを送信できなくなります。逆に、小さいデータは別のブロックで送信して、値で送信できるようにするのが最適です。
Availability of a server: Providing the data via the DeviceInfo block requires that a server be available from which to retrieve the data. Providing the data via a new block allows it to be sent by value.
サーバーの可用性：DeviceInfoブロックを介してデータを提供するには、データを取得するサーバーを利用できる必要があります。新しいブロックを介してデータを提供すると、値で送信できます。
This section defines how to convey additional data to an emergency service provider. Two different means are specified: the first uses call signaling; the second uses the <provided-by> element of a PIDF-LO [RFC4119].
このセクションでは、緊急サービスプロバイダーに追加データを伝達する方法を定義します。 2つの異なる手段が指定されています。最初の手段はコールシグナリングを使用します。 2つ目は、PIDF-LO [RFC4119]の<provided-by>要素を使用します。
1. First, the ability to embed a Uniform Resource Identifier (URI) in an existing SIP header field, the Call-Info header field, is defined. The URI points to the additional data structure. The Call-Info header field is specified in Section 20.9 of [RFC3261].
1. まず、既存のSIPヘッダーフィールドであるCall-InfoヘッダーフィールドにURI（Uniform Resource Identifier）を埋め込む機能が定義されています。 URIは追加のデータ構造を指します。 Call-Infoヘッダーフィールドは、[RFC3261]のセクション20.9で指定されています。
This document adds a new compound token starting with the value 'EmergencyCallData' for the Call-Info 'purpose' parameter. If the 'purpose' parameter is set to a value starting with 'EmergencyCallData', then the Call-Info header field contains either an HTTPS URL pointing to an external resource or a Content Indirection (CID) URI that allows the data structure to be placed in the body of the SIP message. The 'purpose' parameter also indicates the kind of data (by its MIME media subtype) that is available at the URI.
このドキュメントでは、Call-Infoの「purpose」パラメータの値が「EmergencyCallData」で始まる新しい複合トークンを追加します。 「purpose」パラメータが「EmergencyCallData」で始まる値に設定されている場合、Call-Infoヘッダーフィールドには、外部リソースを指すHTTPS URLまたはデータ構造を配置できるコンテンツインダイレクション（CID）URIが含まれますSIPメッセージの本文。 「目的」パラメーターは、URIで利用可能なデータの種類（MIMEメディアサブタイプ別）も示します。
As the data is conveyed using a URI in the SIP signaling, the data itself can reside on an external resource or can be contained within the body of the SIP message. When the URI refers to data at an external resource, the data is said to be passed by reference. When the URI refers to data contained within the body of the SIP message, the data is said to be passed by value. A PSAP or emergency responder is able to examine the type of data provided and selectively access the data it is interested in, while forwarding all of it (the values or references) to downstream entities.
データはSIPシグナリングのURIを使用して伝達されるため、データ自体を外部リソースに置くことも、SIPメッセージの本文に含めることもできます。 URIが外部リソースのデータを参照する場合、そのデータは参照渡しされるといいます。 URIがSIPメッセージの本文に含まれるデータを参照する場合、データは値で渡されると言います。 PSAPまたは緊急応答者は、提供されたデータのタイプを検査し、関心のあるデータに選択的にアクセスしながら、そのすべて（値または参照）をダウンストリームエンティティに転送できます。
To be conveyed in a SIP body, additional data about a call is defined as a series of MIME objects (also referred to as a "block" of data). Each block defined in this document is an XML data structure identified by its MIME media type. (Blocks defined by others can be encoded in XML or not, as identified by their MIME registration.) As usual, whenever more than one MIME part is included in the body of a message, MIME multipart (i.e., 'multipart/mixed') encloses them all.
SIPボディで伝達されるために、コールに関する追加のデータは、一連のMIMEオブジェクトとして定義されます（データの「ブロック」とも呼ばれます）。このドキュメントで定義されている各ブロックは、MIMEメディアタイプで識別されるXMLデータ構造です。 （他のユーザーが定義したブロックは、MIME登録で識別されるように、XMLでエンコードすることもしないこともできます。）通常どおり、メッセージの本文に複数のMIMEパートが含まれる場合は常に、MIMEマルチパート（つまり、 'multipart / mixed'）それらをすべて囲みます。
This document defines a set of XML schemas and MIME media types used for each block defined here. When additional data is passed by value in the SIP signaling, each CID URL points to one block in the body. Multiple URIs are used within a Call-Info header field (or multiple Call-Info header fields) to point to multiple blocks. When additional data is provided by reference (in SIP signaling or the <provided-by> element of a PIDF-LO), each HTTPS URL references one block; the data is retrieved with an HTTPS GET operation, which returns the block as an object (the blocks defined here are returned as XML objects).
このドキュメントは、ここで定義された各ブロックに使用されるXMLスキーマとMIMEメディアタイプのセットを定義します。追加のデータがSIPシグナリングで値によって渡される場合、各CID URLは本体の1つのブロックを指します。複数のURIは、複数のブロックを指すためにCall-Infoヘッダーフィールド（または複数のCall-Infoヘッダーフィールド）内で使用されます。追加データが参照によって提供される場合（SIPシグナリングまたはPIDF-LOの<provided-by>要素で）、各HTTPS URLは1つのブロックを参照します。データは、ブロックをオブジェクトとして返すHTTPS GET操作で取得されます（ここで定義されたブロックはXMLオブジェクトとして返されます）。
2. Second, the ability to embed additional data structures in the <provided-by> element of a PIDF-LO [RFC4119] is defined.
2. 次に、PIDF-LO [RFC4119]の<provided-by>要素に追加のデータ構造を埋め込む機能が定義されています。
In addition to service providers in the call path, the access network provider generally has similar information that can be valuable to the PSAP. When the access network provider and service provider are separate entities, the access network does not participate in the application-layer signaling (and hence cannot add a Call-Info header field to the SIP message) but can provide location information in a PIDF-LO. When the access network provider supplies location information in the form of a PIDF-LO from a location server via a location configuration protocol, it has the ability to add the data structures defined in this document (or references to them) within the PIDF-LO.
コールパス内のサービスプロバイダーに加えて、アクセスネットワークプロバイダーは一般に、PSAPにとって価値のある同様の情報を持っています。アクセスネットワークプロバイダーとサービスプロバイダーが別々のエンティティである場合、アクセスネットワークはアプリケーション層のシグナリングに参加しないため（SIPメッセージにCall-Infoヘッダーフィールドを追加できません）、PIDF-LOで位置情報を提供できます。 。アクセスネットワークプロバイダーがロケーション構成プロトコルを介してロケーションサーバーからPIDF-LOの形式でロケーション情報を提供する場合、このドキュメントで定義されたデータ構造（またはそれらへの参照）をPIDF-LO内に追加できます。 。
The data in these data structures is not specific to the location itself, but rather provides descriptive information having to do with the immediate circumstances about the provider's provision of the location (e.g., the identity of the access network provider, how to contact that entity, what kind of service the access network provides, subscriber information, etc.). This data is similar in nearly every respect to the data known by service providers in the path of the call. The <provided-by> element of the PIDF-LO is a mechanism for the access network provider to supply the information. This document describes a namespace per [RFC4119] for inclusion in the <provided-by> element of a PIDF-LO for adding information known to the access network provider. The access network provider SHOULD provide additional data within a <provided-by> element of a PIDF-LO it returns for emergency use (e.g., if requested with an HTTP-Enabled Location Delivery (HELD) 'responseTime' attribute of 'emergencyRouting' or 'emergencyDispatch' [RFC5985]).
これらのデータ構造のデータは、場所自体に固有のものではなく、場所のプロバイダーの提供に関する当面の状況に関連する説明情報を提供します（たとえば、アクセスネットワークプロバイダーのID、エンティティへの連絡方法、アクセスネットワークが提供するサービスの種類、加入者情報など）。このデータは、ほぼすべての点で、コールの経路でサービスプロバイダーが知っているデータと似ています。 PIDF-LOの<provided-by>要素は、アクセスネットワークプロバイダーが情報を提供するためのメカニズムです。このドキュメントは、アクセスネットワークプロバイダーに既知の情報を追加するためにPIDF-LOの<provided-by>要素に含めるための[RFC4119]ごとの名前空間について説明します。アクセスネットワークプロバイダーは、緊急用に返すPIDF-LOの<provided-by>要素内に追加データを提供する必要があります（たとえば、HTTP対応のロケーションデリバリー（HELD）の 'responseTime'属性に 'emergencyRouting'を指定して要求された場合、または'emergencyDispatch' [RFC5985]）。
One or more blocks of data registered in the "Emergency Call Additional Data" registry, as defined in Section 11.1.9, can be included or referenced in the SIP signaling (using the Call-Info header field) or in the <provided-by> element of a PIDF-LO. For interoperability, only blocks in the registry are permitted to be sent using the mechanisms specified in this document. Since multiple entities are expected to provide sets of data, the data itself needs information describing the source. Consequently, each entity adding additional data MUST supply a 'Data Provider' block. All other blocks are optional, but each entity SHOULD supply all blocks where it has at least some of the information in the block.
セクション11.1.9で定義されているように、「緊急コールの追加データ」レジストリに登録されている1つ以上のデータブロックは、SIPシグナリング（Call-Infoヘッダーフィールドを使用）または<provided-by > PIDF-LOの要素。相互運用性のため、このドキュメントで指定されたメカニズムを使用して送信できるのは、レジストリ内のブロックのみです。複数のエンティティがデータのセットを提供することが期待されているため、データ自体にソースを説明する情報が必要です。したがって、追加のデータを追加する各エンティティは、「データプロバイダー」ブロックを提供する必要があります。他のすべてのブロックはオプションですが、各エンティティは、ブロック内に少なくとも一部の情報があるすべてのブロックを提供する必要があります。
Note that, as with any mechanism, failures are possible. For example, a block (provided by value or by reference) might not be the type indicated by the 'purpose' parameter, or might be badly formed, etc. The general principle that applies to emergency calls is that it is more important for the call to go through than for everything to be correct. Thus, most PSAPs will process a call if at all possible, even if data is missing or other failures occur.
他のメカニズムと同様に、障害が発生する可能性があることに注意してください。たとえば、（値または参照によって提供される）ブロックは、「目的」パラメーターによって示されるタイプではない場合や、形式が正しくない場合があります。緊急呼び出しに適用される一般的な原則は、すべてが正しいことよりも通過するように電話してください。したがって、ほとんどのPSAPは、データが欠落している場合やその他の障害が発生した場合でも、可能な限りコールを処理します。
A URI to a block MAY be inserted in any SIP request or response method (most often INVITE or MESSAGE), using a Call-Info header field containing a 'purpose' value starting with 'EmergencyCallData', a dot ('.'), and the type of data available at the URI. The type of data is denoted by including the root of the MIME media subtype (the 'EmergencyCallData' prefix is not repeated), omitting any suffix such as '+xml'. For example, when referencing a block with MIME media type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set to 'EmergencyCallData.ProviderInfo'. An example Call-Info header field for this would be:
「EmergencyCallData」で始まる「目的」の値を含むCall-Infoヘッダーフィールド、ドット（「。」）を使用して、ブロックへのURIをSIPリクエストまたは応答メソッド（ほとんどの場合、INVITEまたはMESSAGE）に挿入できます。 URIで利用可能なデータのタイプ。データのタイプは、MIMEメディアサブタイプのルートを含めて示されます（「EmergencyCallData」接頭辞は繰り返されません）。「+ xml」などの接尾辞は省略します。たとえば、MIMEメディアタイプが 'application / EmergencyCallData.ProviderInfo + xml'のブロックを参照する場合、 'purpose'パラメータは 'EmergencyCallData.ProviderInfo'に設定されます。この例のCall-Infoヘッダーフィールドは次のようになります。
Call-Info: https://www.example.com/23sedde3;
purpose="EmergencyCallData.ProviderInfo"
A Call-Info header field with a 'purpose' value starting with 'EmergencyCallData' only has meaning in the context of an emergency call (as ascertained by the presence of an emergency service URN in a Request-URI header field of a SIP message), test emergency calls (using an appropriate service URN), and some private-use calls where the endpoints have a preexisting relationship and privacy concerns do not apply because of the relationship; use in other contexts is undefined and is likely to unnecessarily expose confidential data.
「EmergencyCallData」で始まる「目的」値を持つCall-Infoヘッダーフィールドは、緊急コールのコンテキストでのみ意味があります（SIPメッセージのRequest-URIヘッダーフィールドに緊急サービスのURNが存在することで確認できます） 、緊急コール（適切なサービスURNを使用）、およびエンドポイントに既存の関係があり、その関係のためにプライバシーの懸念が適用されない一部の私的使用のコールをテストします。他のコンテキストでの使用は定義されておらず、機密データを不必要に公開する可能性があります。
If the data is provided by reference, an HTTPS URI MUST be included, and consequently, Transport Layer Security (TLS) protection is used during the retrieval of the information.
データが参照によって提供される場合、HTTPS URIが含まれている必要があり、その結果、情報の取得中にトランスポート層セキュリティ（TLS）保護が使用されます。
The data can also be supplied by value in any SIP request or response method that is permitted to contain a body (i.e., not a BYE request) [RFC3261]. In this case, CID [RFC2392] is used, with the CID URL referencing the MIME body part containing the data. Note that [RFC3261] forbids proxies from altering message bodies, so entities in the call path that add blocks by value need to do so using an appropriate SIP entity (e.g., a back-to-back user agent).
データは、本文を含めることが許可されている任意のSIP要求または応答メソッド（つまり、BYE要求ではない）で値によって提供することもできます[RFC3261]。この場合、CID [RFC2392]が使用され、CID URLはデータを含むMIME本文部分を参照します。 [RFC3261]はプロキシがメッセージ本文を変更することを禁止しているため、値によってブロックを追加する呼び出しパスのエンティティは、適切なSIPエンティティ（バックツーバックユーザーエージェントなど）を使用してそうする必要があります。
Transmitting data by value is especially useful in certain cases, such as when the data exists in or is generated by the originating device but is not intended for very large data blocks. Additional security and privacy considerations apply to data transmitted by value, as discussed in Sections 9 and 10, respectively.
値によるデータの送信は、データが元のデバイスに存在または生成されているが、非常に大きなデータブロックを対象としていない場合など、特定の場合に特に役立ちます。追加のセキュリティとプライバシーに関する考慮事項は、それぞれセクション9と10で説明されているように、値によって送信されるデータに適用されます。
More than one Call-Info header field with a 'purpose' value starting with 'EmergencyCallData' can be expected, but at least one MUST be provided. The device MUST provide one unless it knows that a service provider is in the path of the call. The device MAY insert one if it uses a service provider. Each service provider in the path of an emergency call MUST insert its own. For example, a device, a telematics service provider in the call path, as well as the mobile carrier handling the call will each provide one. There might be circumstances where there is a service provider who is unaware that the call is an emergency call and cannot reasonably be expected to determine that it is an emergency call. In that case, that service provider is not expected to provide EmergencyCallData.
「EmergencyCallData」で始まる「目的」値を持つ複数のCall-Infoヘッダーフィールドが期待できますが、少なくとも1つは提供する必要があります。デバイスは、サービスプロバイダーがコールのパスにいることを認識していない限り、デバイスを提供する必要があります。デバイスは、サービスプロバイダーを使用する場合は1つを挿入できます。緊急コールのパスにある各サービスプロバイダーは、独自のプロバイダーを挿入する必要があります。たとえば、デバイス、通話パスのテレマティクスサービスプロバイダー、および通話を処理するモバイルキャリアがそれぞれ1つ提供します。緊急コールであることを知らないサービスプロバイダーがいて、緊急コールであると判断することを合理的に期待できない場合があります。その場合、そのサービスプロバイダーはEmergencyCallDataを提供することは想定されていません。
When blocks are transmitted by value, the 'purpose' parameter in a Call-Info header field identifies the data, and the CID URL points to the data block in the body (which has a matching Content-ID body part header field). When a data block is carried in a signed or encrypted body part, the enclosing multipart (e.g., 'multipart/signed' or 'multipart/encrypted') has the same Content-ID as the data part. This allows an entity to identify and access the data blocks it is interested in without having to dive deeply into the message structure or decrypt parts it is not interested in.
ブロックが値によって送信される場合、Call-Infoヘッダーフィールドの「purpose」パラメーターはデータを識別し、CID URLは本文のデータブロックを指します（一致するContent-IDの本文部分のヘッダーフィールドがあります）。データブロックが署名または暗号化されたボディパートで運ばれる場合、囲んでいるマルチパート（「multipart / signed」または「multipart / encrypted」など）は、データパートと同じContent-IDを持ちます。これにより、エンティティは、関心のあるデータブロックを識別してアクセスすることができ、メッセージ構造を深く掘り下げたり、関心のない部分を復号化したりする必要はありません。
The <EmergencyCallDataReference> element is used to transmit an additional data block by reference within a <provided-by> element of a PIDF-LO. The <EmergencyCallDataReference> element has two attributes: 'ref' to specify the URL and 'purpose' to indicate the type of data block referenced. The value of 'ref' is an HTTPS URL that resolves to a data structure with information about the call. The value of 'purpose' is the same as used in a Call-Info header field (as specified in Section 6.1).
<EmergencyCallDataReference>要素は、PIDF-LOの<provided-by>要素内の参照によって追加のデータブロックを送信するために使用されます。 <EmergencyCallDataReference>要素には、URLを指定する「ref」と、参照されるデータブロックのタイプを示す「目的」の2つの属性があります。 'ref'の値は、呼び出しに関する情報を含むデータ構造に解決されるHTTPS URLです。 'purpose'の値は、Call-Infoヘッダーフィールドで使用されるものと同じです（6.1節で指定）。
For example, to reference a block with MIME media type 'application/ EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set to 'EmergencyCallData.ProviderInfo'. An example <EmergencyCallDataReference> element for this would be:
たとえば、MIMEメディアタイプが 'application / EmergencyCallData.ProviderInfo + xml'のブロックを参照するには、 'purpose'パラメータを 'EmergencyCallData.ProviderInfo'に設定します。このための<EmergencyCallDataReference>要素の例は次のとおりです。
<EmergencyCallDataReference ref="https://www.example.com/23sedde3"
purpose="EmergencyCallData.ProviderInfo"/>
The <EmergencyCallDataReference> element transmits one data block; multiple data blocks are transmitted by using multiple <EmergencyCallDataReference> elements. Multiple <EmergencyCallDataReference> elements MAY be included as child elements inside the <provided-by> element.
<EmergencyCallDataReference>要素は1つのデータブロックを送信します。複数の<EmergencyCallDataReference>要素を使用して、複数のデータブロックが送信されます。複数の<EmergencyCallDataReference>要素が、<provided-by>要素内の子要素として含まれる場合があります。
The following is a simplified example:
以下は簡単な例です。
<provided-by>
<EmergencyCallDataReference
purpose="EmergencyCallData.ServiceInfo"
ref="https://example.com/ref2" />
<EmergencyCallDataReference
purpose="EmergencyCallData.ProviderInfo"
ref="https://example.com/ref3" />
<EmergencyCallDataReference
purpose="EmergencyCallData.Comment"
ref="https://example.com/ref4" />
</provided-by>
Example <provided-by> by Reference
参照による例<provided-by>
For an example in context, Figure 18 shows a PIDF-LO example with an <EmergencyCallDataReference> element pointing to an EmergencyCallData.ServiceInfo data block with the URL in the 'ref' attribute and the 'purpose' attribute set to 'EmergencyCallData.ServiceInfo'.
コンテキスト内の例として、図18は、 'EmergencyCallDataReference>要素が' ref '属性のURLと' purpose '属性が' EmergencyCallData.ServiceInfo 'に設定されたEmergencyCallData.ServiceInfoデータブロックを指すPIDF-LOの例を示しています。 。
It is RECOMMENDED that access networks supply the data specified in this document by reference, because PIDF-LOs can be fetched by a client or other entity and stored locally, so providing the data by value risks exposing private information to a larger audience.
PIDF-LOはクライアントまたは他のエンティティによってフェッチされ、ローカルに格納されるため、アクセスネットワークがこのドキュメントで指定されたデータを参照によって提供することをお勧めします。そのため、値によってデータを提供すると、個人情報がより多くの対象者に公開されるリスクがあります。
The <EmergencyCallDataValue> element is used to transmit one or more additional data blocks by value within a <provided-by> element of a PIDF-LO. Each block being transmitted is placed (as a child element) inside the <EmergencyCallDataValue> element. (The same XML structure as would be contained in the corresponding MIME media type body part is placed inside the <EmergencyCallDataValue> element.) Multiple <EmergencyCallDataValue> elements MAY be included as child elements in the <provided-by> element.
<EmergencyCallDataValue>要素は、PIDF-LOの<provided-by>要素内の値によって1つ以上の追加のデータブロックを送信するために使用されます。送信される各ブロックは、<EmergencyCallDataValue>要素内に（子要素として）配置されます。 （対応するMIMEメディアタイプのボディパーツに含まれるのと同じXML構造が<EmergencyCallDataValue>要素内に配置されます。）複数の<EmergencyCallDataValue>要素が<provided-by>要素の子要素として含まれる場合があります。
The following is a simplified example:
以下は簡単な例です。
<provided-by>
<提供者>
<EmergencyCallDataValue>
<EmergencyCallDataValue>
<EmergencyCallData.ProviderInfo
xmlns=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<DataProviderReference>flurbit735@es.example.com
</DataProviderReference>
<DataProviderString>Access Network Examples, Inc.
</DataProviderString>
<ProviderID>urn:nena:companyid:Test</ProviderID>
<ProviderIDSeries>NENA</ProviderIDSeries>
<TypeOfProvider>Access Network Provider
</TypeOfProvider>
<ContactURI>tel:+1-555-555-0897</ContactURI>
<Language>en</Language>
</EmergencyCallData.ProviderInfo>
<EmergencyCallData.Comment
xmlns=
"urn:ietf:params:xml:ns:EmergencyCallData:Comment">
<DataProviderReference>flurbit735@es.example.com
</DataProviderReference>
<Comment xml:lang="en">This is an example text.
</Comment>
</EmergencyCallData.Comment>
</EmergencyCallDataValue>
</provided-by>
Example <provided-by> by Value
値による<provided-by>の例
For an example in context, Figure 18 shows a PIDF-LO example that contains a <provided-by> element with the <EmergencyCallData.ProviderInfo> and the <EmergencyCallData.Comment> elements as child elements of an <EmergencyCallDataValue> element.
コンテキスト内の例として、図18は、<EmergencyCallData.ProviderInfo>要素と<EmergencyCallData.Comment>要素を含む<provided-by>要素を<EmergencyCallDataValue>要素の子要素として含むPIDF-LOの例を示しています。
RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. It updates and clarifies handling originally defined in RFC 3261 [RFC3261] based on implementation experience. While RFC 3261 did not mandate support for 'multipart' message bodies, 'multipart/mixed' MIME bodies are used by many extensions (including this document) today. For example, adding a PIDF-LO, a Session Description Protocol (SDP), and additional data in the body of a SIP message requires a 'multipart' message body.
RFC 5621 [RFC5621]は、SIPでのメッセージ本文の処理について説明しています。実装経験に基づいて、RFC 3261 [RFC3261]で最初に定義された処理を更新および明確化します。 RFC 3261は「マルチパート」メッセージ本文のサポートを義務付けていませんでしたが、「マルチパート/混合」MIME本文は、今日多くの拡張機能（このドキュメントを含む）で使用されています。たとえば、PIDF-LO、Session Description Protocol（SDP）、およびSIPメッセージの本文に追加のデータを追加するには、「マルチパート」メッセージ本文が必要です。
RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' parameter for the Content-Disposition header field. These RFCs describe how a User Agent Server (UAS) reacts if it receives a message body whose content type or disposition type it does not understand. If the 'handling' parameter has the value 'optional', the UAS ignores the message body. If the 'handling' parameter has the value 'required', the UAS returns a 415 (Unsupported Media Type) response. The 'by-reference' disposition type of RFC 5621 [RFC5621] allows a SIP message to contain a reference to the body part, and the SIP User Agent (UA) processes the body part according to the reference. This is the case for a Call-Info header field containing a CID URL.
RFC 3204 [RFC3204]およびRFC 3459 [RFC3459]は、Content-Dispositionヘッダーフィールドの「処理」パラメータを定義しています。これらのRFCは、ユーザーエージェントサーバー（UAS）が、コンテンツタイプまたは処理タイプが理解できないメッセージ本文を受信した場合の反応を説明しています。 「処理」パラメータの値が「オプション」の場合、UASはメッセージ本文を無視します。 「処理」パラメータの値が「必須」の場合、UASは415（サポートされていないメディアタイプ）応答を返します。 RFC 5621 [RFC5621]の「参照による」後処理タイプにより、SIPメッセージに本文部分への参照を含めることができ、SIPユーザーエージェント（UA）は参照に従って本文部分を処理します。これは、CID URLを含むCall-Infoヘッダーフィールドの場合です。
As an example, a SIP message indicates the 'Content-Disposition' parameter in the body of the SIP message as shown in Figure 14.
例として、SIPメッセージは、図14に示すように、SIPメッセージの本文の「Content-Disposition」パラメーターを示します。
Content-Type: application/sdp
...Omit Content-Disposition here; defaults are ok
...SDP goes in here
... SDPがここに入ります
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
...PIDF-LO goes in here
... PIDF-LOがここに入ります
--boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference; handling=optional
...Data provider information data goes in here
...ここにデータプロバイダー情報データが入ります
--boundary1--
--boundary1--
Figure 14: Example for Use of the Content-Disposition Parameter in SIP
図14：SIPでのContent-Dispositionパラメーターの使用例
This section illustrates a longer and more complex example, as shown in Figure 15. In this example, additional data is added by the end device, included by the VoIP provider, and provided by the access network provider (via the PIDF-LO).
このセクションでは、図15に示すように、より長く複雑な例を示します。この例では、エンドデバイスによって追加のデータが追加され、VoIPプロバイダーによって含まれ、アクセスネットワークプロバイダーによって（PIDF-LOを介して）提供されます。
O +----+ [============] [=============]
/|\ | UA | [ Access ] [ VoIP ]
| +----+ [ Network ] [ Provider ]
/ \ [ Provider ] [ example.org ]
[ ] [ ]
(1) [ ] (2) [ ]
Emergency Call [ ] Emergency Call [ ]
------------------------------------------------------> ]
+Device Info [ ] +Device Info [ ]
+Data Prov. Info [ ^ ] +Data Provider Info [ | ]
+Location URI [=======.====] +Location URI [====|========]
. |
. |
+Location . [==============] |
+Owner/Subscriber Info . [ ] (3) |
+Device Info . (4) [ <------------+
+Data Provider Info #3 ..........> ] Emergency Call
[ ] +Device Info
[ PSAP ] +Data Prov. Info #2
[ ] +Location URI
[==============]
Legend:
伝説：
--- Emergency Call Setup Procedure
... Location Retrieval/Response
Figure 15: Additional Data Example Flow
図15：追加のデータ例のフロー
The example scenario starts with the end device itself adding device information, owner/subscriber information, a location URI, and data provider information to the outgoing emergency call setup message (see step #1 in Figure 15). The SIP INVITE example is shown in Figure 16.
シナリオの例は、エンドデバイス自体がデバイス情報、所有者/加入者情報、ロケーションURI、およびデータプロバイダー情報を発信緊急コールセットアップメッセージに追加することから始まります（図15のステップ＃1を参照）。 SIP INVITEの例を図16に示します。
INVITE urn:service:sos SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg>
;purpose=icon,
<http://www.example.com/hannes/> ;purpose=info,
<cid:1234567890@atlanta.example.com>
;purpose=EmergencyCallData.ProviderInfo,
<cid:0123456789@atlanta.example.com>
;purpose=EmergencyCallData.DeviceInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml,
application/EmergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE
Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP goes here
... SDPがここに入ります
--boundary1
Content-Type: application/EmergencyCallData.DeviceInfo+xml
Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo
xmlns:dev=
"urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference>
d4b3072df09876543@[93.184.216.119]
</dev:DataProviderReference>
<dev:DeviceClassification>laptop</dev:DeviceClassification>
<dev:UniqueDeviceID
TypeOfDeviceID="MAC">00-0d-4b-30-72-df
</dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo>
--boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo
xmlns:pi=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
</pi:DataProviderReference>
<pi:DataProviderString>Hannes Tschofenig</pi:DataProviderString>
<pi:TypeOfProvider>Client</pi:TypeOfProvider>
<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
<pi:Language>en</pi:Language>
<pi:DataProviderContact
xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Hannes Tschofenig</text></fn>
<n>
<surname>Hannes</surname>
<given>Tschofenig</given>
<additional/>
<prefix/>
<suffix>Dipl. Ing.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>de</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Hannes Tschofenig
Linnoitustie 6
Espoo, Finland
02600</text></label>
</parameters>
<pobox/>
<ext/>
<street>Linnoitustie 6</street>
<locality>Espoo</locality>
<region>Uusimaa</region>
<code>02600</code>
<country>Finland</country>
</adr>
<adr>
<parameters>
<type><text>home</text></type>
<label><text>Hannes Tschofenig
c/o Hotel DuPont
42 W 11th St
Wilmington, DE 19801
USA</text></label>
</parameters>
<pobox/>
<ext/>
<street>42 W 11th St</street>
<locality>Wilmington</locality>
<region>DE</region>
<code>19801</code>
<country>USA</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 4871445</uri>
</tel>
<tel>
<parameters>
<type>
<text>home</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+1-555-555-0123</uri>
</tel>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
<text>main-number</text>
</type>
</parameters>
<uri>tel:+1-302-594-3100</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>hannes.tschofenig@nsn.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:60.210796,24.812924</uri>
</geo>
<geo>
<parameters><type><text>home</text></type>
</parameters>
<uri>geo:39.746537,-75.548027</uri>
</geo>
<key>
<parameters>
<type><text>home</text></type>
</parameters>
<uri>https://www.example.com/key.asc</uri>
</key>
<tz><text>Finland/Helsinki</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://example.com/hannes.tschofenig
</uri>
</url>
</vcard>
</pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1--
Figure 16: End Device Sending SIP INVITE with Additional Data
図16：追加データを含むSIP INVITEを送信するエンドデバイス
In this example, information available to the access network provider is included in the call setup message only indirectly via the use of the location reference. The PSAP has to retrieve it via a separate lookup step. Since the access network provider and the VoIP service provider are two independent entities in this scenario, the access network provider is not involved in application-layer exchanges; the SIP INVITE transits the access network transparently, as illustrated in steps #1 and #2 (the access network does not alter the SIP INVITE).
この例では、アクセスネットワークプロバイダーが使用できる情報は、ロケーション参照を使用して間接的にのみコールセットアップメッセージに含まれています。 PSAPは、別のルックアップステップを介してそれを取得する必要があります。このシナリオでは、アクセスネットワークプロバイダーとVoIPサービスプロバイダーが2つの独立したエンティティであるため、アクセスネットワークプロバイダーはアプリケーション層の交換に関与していません。 SIP INVITEは、ステップ＃1および＃2に示すように、アクセスネットワークを透過的に通過します（アクセスネットワークはSIP INVITEを変更しません）。
The VoIP service provider receives the message and determines, based on the service URN, that the incoming request is an emergency call. It performs typical emergency-services-related tasks (such as location-based routing) and adds additional data, namely service and subscriber information as well as data provider information #2, to the outgoing message. For the example, we assume a VoIP service provider deploys a back-to-back user agent allowing additional data to be included in the body of the SIP message (rather than by reference), which allows us to illustrate the use of multiple data provider info blocks. The resulting message is shown in Figure 17. The SIP INVITE is sent to the PSAP in step #3.
VoIPサービスプロバイダーはメッセージを受信し、サービスのURNに基づいて、着信要求が緊急コールであると判断します。これは、典型的な緊急サービス関連のタスク（位置ベースのルーティングなど）を実行し、追加のデータ、つまりサービスと加入者の情報、およびデータプロバイダー情報＃2を送信メッセージに追加します。この例では、VoIPサービスプロバイダーがバックツーバックのユーザーエージェントを展開し、SIPメッセージの本文に（参照ではなく）追加のデータを含めることができると想定しています。これにより、複数のデータプロバイダーの使用を説明できます。情報ブロック。結果のメッセージを図17に示します。SIPINVITEは、ステップ＃3でPSAPに送信されます。
INVITE sips:psap@example.org SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg>;
purpose=icon,
<http://www.example.com/hannes/>; purpose=info,
<cid:1234567890@atlanta.example.com>;
purpose=EmergencyCallData.ProviderInfo
<cid:0123456789@atlanta.example.com>;
purpose=EmergencyCallData.DeviceInfo
Call-Info: <cid:bloorpyhex@atlanta.example.com>;
purpose=EmergencyCallData.ServiceInfo
Call-Info: <cid:aaabbb@atlanta.example.com>;
purpose=EmergencyCallData.ProviderInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml,
application/EmergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE
Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP goes here
... SDPがここに入ります
--boundary1
Content-Type: application/EmergencyCallData.DeviceInfo+xml
Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo
xmlns:dev=
"urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference>d4b3072df09876543@[93.184.216.119]
</dev:DataProviderReference>
<dev:DeviceClassification>laptop</dev:DeviceClassification>
<dev:UniqueDeviceID
TypeOfDeviceID="MAC">00-0d-4b-30-72-df</dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo>
--boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo
xmlns:pi=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
</pi:DataProviderReference>
<pi:DataProviderString>Hannes Tschofenig
</pi:DataProviderString>
<pi:TypeOfProvider>Client</pi:TypeOfProvider>
<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
<pi:Language>en</pi:Language>
<pi:DataProviderContact
xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Hannes Tschofenig</text></fn>
<n>
<surname>Hannes</surname>
<given>Tschofenig</given>
<additional/>
<prefix/>
<suffix>Dipl. Ing.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>de</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Hannes Tschofenig
Linnoitustie 6
Espoo, Finland
02600</text></label>
</parameters>
<pobox/>
<ext/>
<street>Linnoitustie 6</street>
<locality>Espoo</locality>
<region>Uusimaa</region>
<code>02600</code>
<country>Finland</country>
</adr>
<adr>
<parameters>
<type><text>home</text></type>
<label><text>Hannes Tschofenig
c/o Hotel DuPont
42 W 11th St
Wilmington, DE 19801
USA</text></label>
</parameters>
<pobox/>
<ext/>
<street>42 W 11th St</street>
<locality>Wilmington</locality>
<region>DE</region>
<code>19801</code>
<country>USA</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 4871445</uri>
</tel>
<tel>
<parameters>
<type>
<text>home</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+1-555-555-0123</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>hannes.tschofenig@nsn.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:60.210796,24.812924</uri>
</geo>
<geo>
<parameters><type><text>home</text></type>
</parameters>
<uri>geo:39.746537,-75.548027</uri>
</geo>
<key>
<parameters>
<type><text>home</text></type>
</parameters>
<uri>https://www.example.com/key.asc</uri>
</key>
<tz><text>Finland/Helsinki</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://example.com/hannes.tschofenig</uri>
</url>
</vcard>
</pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1
Content-Type: application/EmergencyCallData.ServiceInfo+xml
Content-ID: <bloorpyhex@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<svc:EmergencyCallData.ServiceInfo
xmlns:svc=
"urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo">
<svc:DataProviderReference>string0987654321@example.org
</svc:DataProviderReference>
<svc:ServiceEnvironment>Residence</svc:ServiceEnvironment>
<svc:ServiceType>VOIP</svc:ServiceType>
<svc:ServiceMobility>Unknown</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo>
--boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <aaabbb@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo
xmlns:pi=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<pi:DataProviderReference>string0987654321@example.org
</pi:DataProviderReference>
<pi:DataProviderString>Exemplar VoIP Provider
</pi:DataProviderString>
<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>
<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>
<pi:Language>en</pi:Language>
<pi:DataProviderContact
xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>John Doe</text></fn>
<n>
<surname>John</surname>
<given>Doe</given>
<additional/>
<prefix/>
<suffix/>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<org>
<parameters><type><text>work</text></type>
</parameters>
<text>Exemplar VoIP Provider</text>
</org>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>John Doe
123 Middle Street
The Sticks, IA 50055</text></label>
</parameters>
<pobox/>
<ext/>
<street>123 Middle Street</street>
<locality>The Sticks</locality>
<region>IA</region>
<code>50055</code>
<country>USA</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
<text>main-number</text>
</type>
</parameters>
<uri>sips:john.doe@example.com</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>john.doe@example.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:41.761838,-92.963268</uri>
</geo>
<tz><text>America/Chicago</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://www.example.com/john.doe</uri>
</url>
</vcard>
</pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1--
Figure 17: VoIP Provider Sending SIP INVITE with Additional Data
図17：追加データを含むSIP INVITEを送信するVoIPプロバイダー
Finally, the PSAP requests location information from the access network provider. The response is shown in Figure 18. Along with the location information, additional data is provided in the <provided-by> element of the PIDF-LO. This request and response is step #4.
最後に、PSAPはアクセスネットワークプロバイダーに位置情報を要求します。応答は図18に示されています。ロケーション情報とともに、PIDF-LOの<provided-by>要素に追加データが提供されます。この要求と応答はステップ4です。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>DE</A1>
<A3>Wilmington</A3>
<PRD>W</PRD>
<RD>11th</RD>
<STS>Street</STS>
<HNO>42</HNO>
<NAM>The Hotel DuPont</NAM>
<PC>19801</PC>
</civicAddress>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>true
</gbp:retransmission-allowed>
<gbp:retention-expiry>2013-12-10T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
<gp:provided-by
xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
<EmergencyCallDataReference
purpose="EmergencyCallData.ServiceInfo"
ref="https://example.com/ref2" />
<EmergencyCallDataValue>
<EmergencyCallData.ProviderInfo
xmlns=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<DataProviderReference>88QV4FpfZ976T@example.com
</DataProviderReference>
<DataProviderString>Diamond State Exemplar
</DataProviderString>
<ProviderID>urn:nena:companyid:diamond</ProviderID>
<ProviderIDSeries>NENA</ProviderIDSeries>
<TypeOfProvider>Access Network Provider</TypeOfProvider>
<ContactURI>tel:+1-302-555-0000</ContactURI>
<Language>en</Language>
</EmergencyCallData.ProviderInfo>
<EmergencyCallData.Comment
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:Comment">
<DataProviderReference>88QV4FpfZ976T@example.com
</DataProviderReference>
<Comment xml:lang="en">This is an example text.</Comment>
</EmergencyCallData.Comment>
</EmergencyCallDataValue>
</gp:provided-by>
</gp:geopriv>
<dm:deviceID>mac:00-0d-4b-30-72-df</dm:deviceID>
<dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
Figure 18: Access Network Provider Returning PIDF-LO with Additional Data
図18：PIDF-LOと追加のデータを返すアクセスネットワークプロバイダー
This section defines the XML schemas of the five data blocks. Additionally, the provided-by schema is specified.
このセクションでは、5つのデータブロックのXMLスキーマを定義します。さらに、提供者スキーマが指定されています。
<?xml version="1.0"?>
<xs:schema
targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation="vcard.xsd"/>
<xs:element
name="EmergencyCallData.ProviderInfo"
type="pi:ProviderInfoType"/>
<xs:simpleType name="SubcontractorPriorityType">
<xs:restriction base="xs:string">
<xs:enumeration value="sub"/>
<xs:enumeration value="main"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ProviderInfoType">
<xs:sequence>
<xs:element name="DataProviderReference"
type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="DataProviderString"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="ProviderID"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ProviderIDSeries"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="TypeOfProvider"
type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="ContactURI" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="Language" minOccurs="1" maxOccurs="unbounded">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern
value="([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})
(-[a-z]{4})?(-([a-z]{2}|\d{3}))?(-([0-9a-z]{5,8}|
\d[0-9a-z]{3}))*(-[0-9a-wyz](-[0-9a-z]{2,8})+)*
(-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|[a-z]{1,3}
(-[0-9a-z]{2,8}){1,2}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="DataProviderContact"
minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
maxOccurs="unbounded" ref="xc:vcard"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SubcontractorPrincipal"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="SubcontractorPriority"
type="pi:SubcontractorPriorityType"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Figure 19: EmergencyCallData.ProviderInfo XML Schema
図19：EmergencyCallData.ProviderInfo XMLスキーマ
<?xml version="1.0"?>
<xs:schema
targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="EmergencyCallData.ServiceInfo"
type="svc:ServiceInfoType"/>
<xs:complexType name="ServiceInfoType">
<xs:sequence>
<xs:element name="DataProviderReference"
type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="ServiceEnvironment"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ServiceType"
type="xs:string" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="ServiceMobility"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Figure 20: EmergencyCallData.ServiceInfo XML Schema
図20：EmergencyCallData.ServiceInfo XMLスキーマ
<?xml version="1.0"?>
<xs:schema
targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="EmergencyCallData.DeviceInfo"
type="dev:DeviceInfoType"/>
<xs:complexType name="DeviceInfoType">
<xs:sequence>
<xs:element name="DataProviderReference"
type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="DeviceClassification"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceMfgr"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceModelNr"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="UniqueDeviceID" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="TypeOfDeviceID"
type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="DeviceSpecificData"
type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceSpecificType"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Figure 21: EmergencyCallData.DeviceInfo XML Schema
図21：EmergencyCallData.DeviceInfo XMLスキーマ
<?xml version="1.0"?>
<xs:schema
targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sub=
"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation="vcard.xsd"/>
<xs:element name="EmergencyCallData.SubscriberInfo"
type="sub:SubscriberInfoType"/>
<xs:complexType name="SubscriberInfoType">
<xs:sequence>
<xs:element name="DataProviderReference" type="xs:token"
minOccurs="1" maxOccurs="1"/>
<xs:element name="SubscriberData">
<xs:complexType>
<xs:sequence>
<xs:element ref="xc:vcard"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="privacyRequested"
type="xs:boolean" use="required"/>
</xs:complexType>
</xs:schema>
Figure 22: EmergencyCallData.SubscriberInfo XML Schema
図22：EmergencyCallData.SubscriberInfo XMLスキーマ
<?xml version="1.0"?>
<xs:schema
targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData:Comment"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="EmergencyCallData.Comment"
type="com:CommentType"/>
<xs:complexType name="CommentType">
<xs:sequence>
<xs:element name="DataProviderReference"
type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="Comment"
type="com:CommentSubType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CommentSubType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Figure 23: EmergencyCallData.Comment XML Schema
図23：EmergencyCallData.Comment XMLスキーマ
This section defines the provided-by schema.
このセクションでは、提供者スキーマを定義します。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
xmlns:sub="urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
schemaLocation="ProviderInfo.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
schemaLocation="ServiceInfo.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
schemaLocation="DeviceInfo.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
schemaLocation="SubscriberInfo.xsd"/>
<xs:import
namespace="urn:ietf:params:xml:ns:EmergencyCallData:Comment"
schemaLocation="Comment.xsd"/>
<xs:element name="EmergencyCallDataReference" type="ad:ByRefType"/>
<xs:element name="EmergencyCallDataValue"
type="ad:EmergencyCallDataValueType"/>
<!-- Additional Data By Reference -->
<xs:complexType name="ByRefType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="purpose" type="xs:token" use="required"/>
<xs:attribute name="ref" type="xs:anyURI" use="required"/>
</xs:complexType>
<!-- Additional Data By Value -->
<xs:complexType name="EmergencyCallDataValueType">
<xs:sequence>
<xs:element ref="pi:EmergencyCallData.ProviderInfo"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="svc:EmergencyCallData.ServiceInfo"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="dev:EmergencyCallData.DeviceInfo"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="sub:EmergencyCallData.SubscriberInfo"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="com:EmergencyCallData.Comment"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Figure 24: provided-by XML Schema
図24：XMLスキーマ提供
The data structures described in this document contain information usually considered private. When information is provided by value, entities that are a party to the SIP signaling (such as proxy servers and back-to-back user agents) will have access to it and need to protect it against inappropriate disclosure. An entity that is able to eavesdrop on the SIP signaling will also have access. Some Internet access types (such as in-the-clear Wi-Fi) are more vulnerable than others (such as 3G or 4G cellular data traffic) to eavesdropping. Mechanisms that protect against eavesdropping (such as TLS version 1.2 or later) SHOULD be preferentially used whenever feasible. (This requirement is not a "MUST" because there is an existing deployed base of clear-text SIP, and also because, as an emergency call, it is more important for the call to go through than for it to be protected; for example, the call MUST proceed even if the TLS negotiation or certificate verification fails for whatever reason.) When information is provided by reference, TLS mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for dereferencing, the requester MUST use a client certificate to authenticate the HTTP request, and the provider of the information is REQUIRED to validate the credentials provided by the requester. While the creation of a public key infrastructure (PKI) that has global scope might be difficult, the alternatives to creating devices and services that can provide critical information securely are more daunting. The provider of the information MAY enforce any policy it wishes to use, but PSAPs and responder agencies are strongly advised to deploy a PKI so that providers of additional data can check the certificate of the client (the requester) and decide the appropriate policy to enforce based on that certificate.
このドキュメントで説明するデータ構造には、通常プライベートと見なされる情報が含まれています。情報が価値によって提供される場合、SIPシグナリングの当事者であるエンティティ（プロキシサーバーやバックツーバックユーザーエージェントなど）はその情報にアクセスでき、不適切な開示から情報を保護する必要があります。 SIPシグナリングを傍受できるエンティティもアクセスできます。一部のインターネットアクセスタイプ（透明なWi-Fiなど）は、他のタイプ（3Gまたは4Gセルラーデータトラフィックなど）よりも盗聴に対して脆弱です。盗聴から保護するメカニズム（TLSバージョン1.2以降など）は、可能な限り優先的に使用する必要があります（SHOULD）。 （この要件は「必須」ではありません。クリアテキストSIPの既存の展開済みベースがあり、緊急コールとして、コールを保護するよりもコールを通過させる方が重要であるためです。たとえば、 、何らかの理由でTLSネゴシエーションまたは証明書の検証が失敗した場合でも、呼び出しを続行する必要があります。）参照によって情報が提供される場合、TLS相互認証が必要です。つまり、逆参照にはHTTPSが必要であり、リクエスターはHTTPリクエストを認証するためにクライアント証明書を使用する必要があり、情報のプロバイダーはリクエスターによって提供される資格情報を検証する必要があります。グローバルスコープを持つ公開キーインフラストラクチャ（PKI）の作成は難しい場合がありますが、重要な情報を安全に提供できるデバイスとサービスを作成する代わりの方法はさらに困難です。情報の提供者は、使用したいあらゆるポリシーを施行することができますが、追加データの提供者がクライアント（リクエスター）の証明書を確認し、施行する適切なポリシーを決定できるように、PSAPおよびレスポンダー機関はPKIを導入することを強くお勧めしますその証明書に基づいています。
TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cipher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC) and to follow the recommendations in BCP 195 [RFC7525].
TLSはバージョン1.2以降でなければなりません。 Perfect Forward Secrecy（PFS）を提供し、Cipher Block Chaining（CBC）を回避する暗号スイートのみを使用し、BCP 195 [RFC7525]の推奨事項に従うことをお勧めします。
Ideally, the PSAP and emergency responders will be given credentials signed by an authority trusted by the data provider. In most circumstances, nationally recognized credentials are sufficient; the emergency services community within a country can arrange a PKI, data providers can be provisioned with the root Certification Authority (CA) public key for the country. Some nations are developing a PKI for this and related purposes. Since calls could be made from devices where the device and/or the service provider(s) is not local to the emergency services authorities, globally recognized credentials are useful. This might be accomplished by extending the notion of the "forest guide" described in [RFC5582] to allow the forest guide to provide the credential of the PKI root for areas for which it has coverage information, but standards for such a mechanism are not yet available. In its absence, the data provider needs to obtain by out-of-band means the root CA credentials for any areas to which it is willing to provide additional data. With the credential of the root CA for a national emergency services PKI, the data provider server can validate the credentials of an entity requesting additional data by reference.
理想的には、PSAPおよび緊急応答者には、データプロバイダーによって信頼された機関によって署名された資格情報が与えられます。ほとんどの状況では、全国的に認められている資格情報で十分です。国内の緊急サービスコミュニティはPKIを手配でき、データプロバイダーはその国のルート認証局（CA）公開鍵をプロビジョニングできます。一部の国では、この目的と関連する目的でPKIを開発しています。デバイスやサービスプロバイダーが緊急サービス機関の近くにないデバイスから電話をかけることができるため、グローバルに認識された資格情報が役立ちます。これは、[RFC5582]で説明されている「フォレストガイド」の概念を拡張して、フォレストガイドがカバレッジ情報を持つエリアのPKIルートの資格情報を提供できるようにすることで実現できますが、そのようなメカニズムの標準はまだありません。利用可能です。データプロバイダーが存在しない場合、帯域外でデータプロバイダーが取得する必要があるのは、追加のデータを提供しようとするすべての領域のルートCA資格情報です。全国緊急サービスPKIのルートCAの資格情報を使用すると、データプロバイダーサーバーは、参照により追加データを要求するエンティティの資格情報を検証できます。
The data provider also needs a credential that can be verified by the emergency services to know that it is receiving data from an authorized server. The emergency services authorities could provide credentials, distinguishable from credentials provided to emergency responders and PSAPs, which could be used to validate data providers. Such credentials would have to be acceptable to any PSAP or responder that could receive a call with additional data supplied by that provider. This would be extensible to global credential validation using the forest guide as mentioned above. In the absence of such credentials, the emergency services authorities could maintain a list of local data providers' credentials as provided to them out of band. At a minimum, the emergency services authorities could obtain a credential from the DNS entry of the domain in the additional data URI (e.g., using DNS-Based Authentication of Named Entities (DANE) [RFC6698]) to at least validate that the server is known to the domain providing the URI.
また、データプロバイダーは、許可されたサーバーからデータを受信していることを知るために、緊急サービスによって検証できる資格情報も必要です。緊急サービス当局は、緊急応答者およびPSAPに提供される資格情報と区別可能な資格情報を提供でき、データプロバイダーの検証に使用できます。このような資格情報は、そのプロバイダーから提供された追加データを含む呼び出しを受信できるPSAPまたはレスポンダーに受け入れられる必要があります。これは、前述のフォレストガイドを使用したグローバルな資格情報検証に拡張できます。そのような資格情報がない場合、緊急サービス当局は、帯域外に提供されたローカルデータプロバイダーの資格情報のリストを維持できます。少なくとも、緊急サービス当局は、追加データURIのドメインのDNSエントリから資格情報を取得して（たとえば、名前付きエンティティのDNSベースの認証（DANE）[RFC6698]を使用して）、少なくともサーバーがURIを提供するドメインに知られています。
When devices provide data by reference, the credential validation issues are similar to when service providers do so, and while the solutions are the same, the challenges of doing so for every device are obviously more difficult, especially when considering root certificate updates, revocation lists, etc. However, in general, devices are not expected to provide data directly by reference, but rather to either provide data by value or upload the data to a server that can more reliably make it available and more easily enforce security policy. Devices that do provide data directly by reference, which might include fixed-location sensors, will need to be capable of handling this.
デバイスが参照によってデータを提供する場合、資格情報の検証の問題はサービスプロバイダーが提供する場合と同様であり、ソリューションは同じですが、特にルート証明書の更新、失効リストを検討する場合、すべてのデバイスに対して提供する課題は明らかに困難です。など。ただし、一般に、デバイスは参照によってデータを直接提供するのではなく、値でデータを提供するか、データをサーバーにアップロードして、より確実に使用可能にし、セキュリティポリシーをより簡単に適用できるようにします。固定位置センサーを含む可能性がある参照によってデータを直接提供するデバイスは、これを処理できる必要があります。
Neither service providers nor devices will supply private information unless the call is recognized as an emergency call. In cellular telephony systems (such as those using 3GPP IMS), there are different procedures for an originating device to place an emergency call versus a normal call. If a call that is really an emergency call is initiated as a normal call and the cellular service provider recognizes this, 3GPP IMS permits the service provider to either accept the call anyway or reject it with a specific code that instructs the device to retry the call as an emergency call. Service providers ought to choose the latter, otherwise the device will not include the information specified in this document (since the device didn't recognize the call as being an emergency call).
コールが緊急コールとして認識されない限り、サービスプロバイダーもデバイスも個人情報を提供しません。セルラーテレフォニーシステム（3GPP IMSを使用するシステムなど）では、発信側デバイスが緊急コールと通常のコールを発信するためのさまざまな手順があります。本当に緊急コールであるコールが通常のコールとして開始され、セルラーサービスプロバイダーがこれを認識した場合、3GPP IMSはサービスプロバイダーがコールを受け入れるか、デバイスにコールを再試行するように指示する特定のコードで拒否することを許可します緊急電話として。サービスプロバイダーは後者を選択する必要があります。そうしないと、デバイスにこのドキュメントで指定された情報が含まれません（デバイスが通話を緊急通話として認識しなかったため）。
This document enables functionality for conveying additional information about the caller and the caller's device and service to the callee. Some of this information is personal data and therefore privacy concerns arise. An explicit privacy indicator for information directly relating to the caller's identity is defined and use is mandatory. However, observance of this request for privacy and which information it relates to is determined by the destination jurisdiction (which replicates functionality provided in some legacy emergency services systems).
このドキュメントは、発信者と発信者のデバイスおよびサービスに関する追加情報を着信者に伝達する機能を有効にします。この情報の一部は個人データであるため、プライバシーに関する懸念が生じます。発信者のIDに直接関連する情報の明示的なプライバシーインジケータが定義され、使用は必須です。ただし、このプライバシー要求の遵守とそれに関連する情報は、送信先の管轄区域（一部のレガシー緊急サービスシステムで提供される機能を複製する）によって決定されます。
There are a number of privacy concerns with non-emergency real-time communication services that are also applicable to emergency calling. Data protection regulation worldwide has, however, decided to create exceptions for emergency services since the drawbacks of disclosing personal data are outweighed by the benefit for the emergency caller. Hence, the data protection rights of individuals are commonly waived for emergency situations. There are, however, still various countries that offer some degree of anonymity for the caller towards PSAP call takers.
緊急通話にも適用される非緊急リアルタイム通信サービスには、プライバシーに関する多くの懸念があります。ただし、個人データを開示することの欠点は、緊急呼び出し元の利点よりも重要であるため、世界中のデータ保護規制は緊急サービスの例外を作成することを決定しました。したがって、個人のデータ保護権は一般的に緊急事態に対して免除されます。ただし、PSAPコールテイカーに対して発信者にある程度の匿名性を提供する国はまだいくつかあります。
The functionality defined in this document far exceeds the amount of information sharing available in the legacy POTS system. For this reason, there are additional privacy threats to consider, which are described in more detail in [RFC6973].
このドキュメントで定義されている機能は、レガシーPOTSシステムで利用できる情報共有の量をはるかに超えています。このため、[RFC6973]で詳細に説明されている、考慮すべきプライバシーの脅威が他にもあります。
Stored Data Compromise: There is an increased risk of stored data compromise since additional data is collected and stored in databases. Without adequate measures to secure stored data from unauthorized or inappropriate access at access network providers, service providers, end devices, as well as PSAPs, individuals are exposed to potential financial, reputational, or physical harm.
保存データの侵害：追加のデータが収集されてデータベースに保存されるため、保存データの侵害のリスクが高まります。アクセスネットワークプロバイダー、サービスプロバイダー、エンドデバイス、およびPSAPでの不正または不適切なアクセスから保存データを保護する適切な手段がない場合、個人は潜在的な金銭的、評判的、または物理的な危害にさらされます。
Misattribution: If the personal data collected and conveyed is incorrect or inaccurate, then this can lead to misattribution. Misattribution occurs when data or communications related to one individual are attributed to another.
誤帰属：収集および伝達された個人データが不正確または不正確である場合、誤帰属につながる可能性があります。誤配は、ある個人に関連するデータまたは通信が別の個人に起因する場合に発生します。
Identification: By the nature of the additional data and its capability to provide much richer information about the caller, the call, and the location, the calling party is identified in a much better way. Some users could feel uncomfortable with this degree of information sharing even in emergency services situations.
識別：発信者、通話、および場所に関するはるかに豊富な情報を提供する追加データとその機能の性質により、発呼者ははるかに優れた方法で識別されます。一部のユーザーは、緊急サービス状況でも、この程度の情報共有に不快に感じる場合があります。
Secondary Use: There is a risk of secondary use, which is the use of collected information about an individual without the individual's consent for a purpose different from that for which the information was collected. The stated purpose of the additional data is for emergency services purposes, but theoretically the same information could be used for any other call as well. Additionally, parties involved in the emergency call could retain the obtained information and reuse it for other, non-emergency services purposes. While technical measures are not in place to prevent such secondary reuse, policy, legal, regulatory, and other non-technical approaches can be effective.
二次利用：二次利用のリスクがあります。これは、個人の同意を得ずに収集した情報を、情報を収集した目的とは異なる目的で使用することです。追加データの明記された目的は緊急サービスの目的ですが、理論的には同じ情報を他の通話にも使用できます。さらに、緊急電話に関与した当事者は、取得した情報を保持し、緊急でない他のサービスの目的で再利用できます。このような二次的な再利用を防ぐための技術的な対策は講じられていませんが、ポリシー、法的、規制、およびその他の非技術的なアプローチは効果的です。
Disclosure: When the data defined in this document is not properly protected (while in transit with traditional communication security techniques and while stored using access control mechanisms), there is the risk of disclosure, which is the revelation of private information about an individual.
開示：このドキュメントで定義されているデータが適切に保護されていない場合（従来の通信セキュリティ技術を使用して転送されている間、およびアクセス制御メカニズムを使用して保存されている場合）、開示のリスクがあります。これは、個人に関する個人情報の暴露です。
To mitigate these privacy risks, the following countermeasures can be taken:
これらのプライバシーリスクを軽減するために、次の対策を講じることができます。
In regions where callers can elect to suppress certain personally identifying information, network or PSAP functionality can inspect privacy flags within the SIP headers to determine what information can be passed, stored, or displayed to comply with local policy or law. RFC 3325 [RFC3325] defines the 'id' priv-value token. The presence of this privacy type in a Privacy header field indicates that the user would like the network asserted identity to be kept private with respect to SIP entities outside the trust domain with which the user authenticated, including the PSAP.
発信者が特定の個人識別情報を抑制するように選択できる地域では、ネットワークまたはPSAP機能はSIPヘッダー内のプライバシーフラグを検査して、ローカルポリシーまたは法律に準拠するために渡される、保存される、または表示される情報を決定できます。 RFC 3325 [RFC3325]は、「id」priv-valueトークンを定義しています。プライバシーヘッダーフィールドにこのプライバシータイプが存在することは、ユーザーがPSAPを含め、ユーザーが認証した信頼ドメイン外のSIPエンティティに関して、ネットワークがアサートしたIDをプライベートに保つことを望んでいることを示します。
This document defines various data structures that contain privacy-sensitive data such as, for example, identifiers for the device (e.g., serial number and MAC address) or account/SIM (e.g., IMSI), contact information for the user, and location of the caller. Local regulations may govern which data is provided in emergency calls, but in general, the emergency call system is aided by the information described in this document. There is a trade-off between the privacy considerations and the utility of the data. For protection, this specification requires all retrieval of data passed by reference to be protected against eavesdropping and alteration via communication security techniques (namely TLS). Furthermore, security safeguards are required to prevent unauthorized access to stored data. Various security incidents over at least the past few decades have shown that data breaches are not uncommon and are often caused by lack of proper access control frameworks, software bugs (such as buffer overflows), or missing input parsing (such as SQL injection attacks). The risks of data breaches have increased with the obligation for emergency services to retain emergency-call-related data for extended periods (e.g., several years are the norm).
このドキュメントでは、デバイスの識別子（シリアル番号やMACアドレスなど）またはアカウント/ SIM（IMSIなど）、ユーザーの連絡先情報、場所など、プライバシーに関わるデータを含むさまざまなデータ構造を定義しています呼び出し側。地域の規制により、緊急通話で提供されるデータが管理される場合がありますが、一般的に、緊急通話システムは、このドキュメントに記載されている情報によって支援されます。プライバシーに関する考慮事項とデータの有用性の間にはトレードオフがあります。保護のために、この仕様では、参照によって渡されたデータのすべての取得を、通信セキュリティ技術（つまりTLS）による盗聴や改ざんから保護する必要があります。さらに、保存されたデータへの不正アクセスを防止するためのセキュリティ保護策が必要です。少なくとも過去数十年にわたるさまざまなセキュリティインシデントにより、データ侵害は珍しいことではなく、適切なアクセス制御フレームワークの不足、ソフトウェアのバグ（バッファオーバーフローなど）、または入力解析の欠落（SQLインジェクション攻撃など）が原因であることが多いことが示されています。緊急電話に関連するデータを長期間保持するという緊急サービスの義務により、データ侵害のリスクが高まっています（たとえば、数年は当たり前です）。
Finally, it is also worth highlighting the nature of the SIP communication architecture, which introduces additional complications for privacy. Some forms of data can be sent by value in the SIP signaling or by reference (a URL in the SIP signaling). When data is sent by value, all intermediaries have access to the data. As such, these intermediaries could also introduce additional privacy risk. Therefore, in situations where the conveyed information is privacy sensitive and intermediaries are involved, transmitting by reference might be appropriate, assuming the source of the data can operate a sufficient dereferencing infrastructure and that proper access control policies are available for distinguishing the different entities dereferencing the reference. Without access control policies, any party in possession of the reference is able to resolve the reference and to obtain the data, including intermediaries.
最後に、SIP通信アーキテクチャの性質を強調することも価値があります。これにより、プライバシーの複雑さが増します。一部の形式のデータは、SIPシグナリングの値または参照（SIPシグナリングのURL）で送信できます。データが値で送信される場合、すべての仲介者がデータにアクセスできます。そのため、これらの仲介者はプライバシーのリスクをさらに高める可能性があります。したがって、伝達される情報がプライバシーに敏感で、仲介者が関与する状況では、データのソースが十分な逆参照インフラストラクチャを操作でき、適切なアクセス制御ポリシーが、参照。アクセス制御ポリシーがなければ、参照を所持しているすべての当事者は、参照を解決し、仲介者を含むデータを取得できます。
This document creates a new registry called 'Emergency Call Additional Data' with a number of sub-registries.
このドキュメントでは、いくつかのサブレジストリを含む「緊急コールの追加データ」という新しいレジストリを作成します。
For several of the sub-registries, "Expert Review" is the criteria for adding new entries. As discussed in Section 5, it can be counterproductive to register new types of data, and as discussed in Section 10, data sent as part of an emergency call can be very privacy sensitive. In some cases, it is anticipated that various standards bodies dealing with emergency services might need to register new values, and in those cases, text below advises the designed expert to verify that the entity requesting the registration is relevant (e.g., a recognized emergency-services-related Standards Development Organization (SDO)). In other cases, especially those where the trade-off between the potential benefit versus danger of new registrations is more conservative (such as Section 11.1.9), "Specification Required" is the criteria, which is a higher hurdle and also implicitly includes an "Expert Review".
一部のサブレジストリでは、「エキスパートレビュー」が新しいエントリを追加するための基準です。セクション5で説明したように、新しいタイプのデータを登録することは逆効果になる可能性があり、セクション10で説明したように、緊急通話の一部として送信されるデータはプライバシーに非常に敏感になる可能性があります。場合によっては、緊急サービスを扱うさまざまな標準化団体が新しい値を登録する必要があることが予想されます。そのような場合、以下のテキストは、登録を要求するエンティティが関連していることを確認するように設計された専門家に助言します（たとえば、認識された緊急事態-サービス関連の標準開発機構（SDO））。その他の場合、特に新規登録の潜在的なメリットと危険性の間のトレードオフがより保守的である場合（セクション11.1.9など）、「必要な仕様」が基準であり、より高いハードルであり、暗黙的に「エキスパートレビュー」。
The following sub-registries are created for this registry.
このレジストリ用に次のサブレジストリが作成されます。
This document creates a new sub-registry called "Provider ID Series". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is a legitimate issuer of service provider IDs suitable for use in Additional Call Data.
このドキュメントは、「プロバイダーIDシリーズ」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。専門家は、新しい値を要求するエンティティが、追加の呼び出しデータでの使用に適したサービスプロバイダーIDの正当な発行者であると判断する必要があります。
Private entities issuing or using internally generated IDs are encouraged to register here and to ensure that all IDs they issue or use are unique. This guarantees that IDs issued or used by the entity are globally unique and distinguishable from other IDs issued or used by the same or a different entity. (Some organizations, such as NENA, issue IDs that are unique among all IDs they issue, so an entity using a combination of its NENA ID and the fact that it is from NENA is globally unique. Other entities might not have an ID issued by an organization such as NENA, so they are permitted to use their domain name, but if so, it needs to be unique.)
内部で生成されたIDを発行または使用するプライベートエンティティは、ここに登録し、発行または使用するすべてのIDが一意であることを確認することをお勧めします。これにより、エンティティによって発行または使用されるIDがグローバルに一意であり、同じまたは異なるエンティティによって発行または使用される他のIDと区別できることが保証されます。 （NENAなどの一部の組織は、発行するすべてのIDの中で一意のIDを発行するため、そのNENA IDとそれがNENAからのものであるという事実を組み合わせて使用するエンティティは、グローバルに一意です。他のエンティティは、 NENAなどの組織であるため、ドメイン名の使用が許可されていますが、そうである場合は、一意である必要があります。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Name: An identifier to be used in the 'ProviderIDSeries' element.
名前：「ProviderIDSeries」要素で使用される識別子。
Source: The full name of the organization issuing the identifiers.
出典：識別子を発行する組織の完全な名前。
URL: A URL to the organization for further information.
URL：詳細については、組織へのURL。
The initial set of values is listed in Figure 1.
値の初期セットを図1に示します。
This document creates a new sub-registry called "Service Environment". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the new value is distinct from existing values, and its use is unambiguous.
このドキュメントは、「サービス環境」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。専門家は、新しい値を要求しているエンティティがこのサービス要素（たとえば、認識されている緊急サービス関連のSDO）に関連しており、新しい値が既存の値とは異なり、その使用が明確であることを判断する必要があります。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The value to be used in the <ServiceEnvironment> element.
トークン：<ServiceEnvironment>要素で使用される値。
Description: A short description of the value.
説明：値の短い説明。
The initial set of values is listed in Figure 4.
値の初期セットを図4に示します。
This document creates a new sub-registry called "Service Type". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the requested value is clearly distinct from other values so that there is no ambiguity as to when the value is to be used or which value is to be used.
このドキュメントは、「サービスタイプ」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。エキスパートは、新しい値を要求しているエンティティがこのサービス要素（たとえば、認識されている緊急サービス関連のSDO）に関連していること、および要求された値が他の値と明確に区別されていることを確認する必要があります。使用する値または使用する値。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Name: The value to be used in the <ServiceType> element.
名前：<ServiceType>要素で使用される値。
Description: A short description of the value.
説明：値の短い説明。
The initial set of values is listed in Figure 5.
値の初期セットを図5に示します。
This document creates a new sub-registry called "Service Mobility". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency-services-related SDO) and that the requested value is clearly distinct from other values so that there is no ambiguity as to when the value is to be used or which value is to be used.
このドキュメントは、「Service Mobility」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。エキスパートは、新しい値を要求しているエンティティがこのサービス要素（たとえば、認識されている緊急サービス関連のSDO）に関連していること、および要求された値が他の値と明確に区別されていることを確認する必要があります。使用する値または使用する値。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The value used in the <ServiceMobility> element.
トークン：<ServiceMobility>要素で使用される値。
Description: A short description of the value.
説明：値の短い説明。
The initial set of values is listed in Figure 6.
値の初期セットを図6に示します。
This document creates a new sub-registry called "Type of Provider". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed new value is distinct from existing values and appropriate for use in the <TypeOfServicerProvider> element
このドキュメントは、「プロバイダーのタイプ」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。専門家は、提案された新しい値が既存の値とは異なり、<TypeOfServicerProvider>要素での使用に適していると判断する必要があります
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The value used in the <TypeOfProvider> element.
トークン：<TypeOfProvider>要素で使用される値。
Description: A short description of the type of service provider.
Description: A short description of the type of service provider.
The initial set of values is defined in Figure 2.
値の初期セットは、図2で定義されています。
This document creates a new sub-registry called "Device Classification". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should consider whether the proposed class is unique from existing classes, and the definition of the class will be clear to implementors and PSAPs/responders.
This document creates a new sub-registry called "Device Classification". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should consider whether the proposed class is unique from existing classes, and the definition of the class will be clear to implementors and PSAPs/responders.
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: Value used in the <DeviceClassification> element.
トークン：<DeviceClassification>要素で使用される値。
Description: Short description identifying the device type.
説明：デバイスタイプを識別する簡単な説明。
The initial set of values is defined in Figure 8.
値の初期セットは、図8で定義されています。
This document creates a new sub-registry called "Device ID Type". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should ascertain that the proposed type is well understood and provides information that PSAPs and responders are able to use to uniquely identify a device. (For example, a biometric fingerprint used to authenticate a device would not normally be used by a PSAP or responder to identify a device.)
このドキュメントは、「デバイスIDタイプ」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは「エキスパートレビュー」ルールの下で動作します。専門家は、提案されたタイプがよく理解されていることを確認し、PSAPと応答者がデバイスを一意に識別するために使用できる情報を提供する必要があります。 （たとえば、デバイスの認証に使用される生体認証指紋は、通常、PSAPまたはレスポンダーがデバイスを識別するために使用することはありません。）
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The value to be placed in the <TypeOfDeviceID> element.
トークン：<TypeOfDeviceID>要素に配置される値。
Description: Short description identifying the type of the device ID.
説明：デバイスIDのタイプを識別する短い説明。
The initial set of values is defined in Figure 9.
値の初期セットは、図9で定義されています。
This document creates a new sub-registry called "Device/Service Data Type". As defined in [RFC5226], this registry operates under "Specification Required" rules, which include an explicit "Expert Review". The designated expert should ascertain that the proposed type is well understood and provides information useful to PSAPs and responders. The specification must contain a complete description of the data and a precise format specification suitable to allow interoperable implementations.
このドキュメントは、「デバイス/サービスデータタイプ」と呼ばれる新しいサブレジストリを作成します。 [RFC5226]で定義されているように、このレジストリは、明示的な「エキスパートレビュー」を含む「指定が必要」のルールの下で動作します。指定された専門家は、提案されたタイプがよく理解されていることを確認し、PSAPおよび応答者に役立つ情報を提供する必要があります。仕様には、データの完全な説明と、相互運用可能な実装を可能にするのに適した正確なフォーマット仕様が含まれている必要があります。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The value to be placed in the <DeviceSpecificType> element.
トークン：<DeviceSpecificType>要素に配置される値。
Description: Short description identifying the data.
Description: Short description identifying the data.
Specification: Citation for the specification of the data.
Specification: Citation for the specification of the data.
The initial set of values is listed in Figure 10.
値の初期セットを図10に示します。
This document creates a new sub-registry called "Emergency Call Data Types". As defined in [RFC5226], this registry operates under "Specification Required" rules, which include an explicit "Expert Review". The expert is responsible for verifying that the document contains a complete and clear specification, and the proposed functionality does not obviously duplicate existing functionality. The expert is also responsible for verifying that the block is correctly categorized per the description of the categories in Section 1.
This document creates a new sub-registry called "Emergency Call Data Types". As defined in [RFC5226], this registry operates under "Specification Required" rules, which include an explicit "Expert Review". The expert is responsible for verifying that the document contains a complete and clear specification, and the proposed functionality does not obviously duplicate existing functionality. The expert is also responsible for verifying that the block is correctly categorized per the description of the categories in Section 1.
The registry contains an entry for every data block that can be sent with an emergency call using the mechanisms as specified in this document. Each data block is identified by the 'root' of its MIME media subtype (which is the part after 'EmergencyCallData.'). If the MIME media subtype does not start with 'EmergencyCallData.', then it cannot be registered here nor used in a Call-Info header field as specified in this document. The subtype MAY exist under any MIME media type (although most commonly under 'application/', this is NOT REQUIRED); however, to be added to the registry, the 'root' needs to be unique regardless of the MIME media type.
レジストリには、このドキュメントで指定されているメカニズムを使用して緊急コールで送信できるすべてのデータブロックのエントリが含まれています。各データブロックは、MIMEメディアサブタイプの「ルート」（「EmergencyCallData。」の後の部分）によって識別されます。 MIMEメディアサブタイプが「EmergencyCallData。」で始まっていない場合、ここに登録することも、このドキュメントで指定されているCall-Infoヘッダーフィールドで使用することもできません。サブタイプは、任意のMIMEメディアタイプの下に存在する場合があります（最も一般的には「application /」の下にありますが、これは必須ではありません）。ただし、レジストリに追加するには、「ルート」はMIMEメディアタイプに関係なく一意である必要があります。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Token: The root of the data's MIME media subtype (not including the 'EmergencyCallData' prefix and any suffix such as '+xml').
Token: The root of the data's MIME media subtype (not including the 'EmergencyCallData' prefix and any suffix such as '+xml').
Data About: A hint as to if the block is considered descriptive of the call, the caller, or the location (or is applicable to more than one), which can help PSAPs and other entities determine if they wish to process the block. Note that this is only a hint; entities need to consider the block's contents, not just this field, when determining if they wish to process the block (which is why the field only exists in the registry and is not contained within the block). The value MUST be either 'The Call', 'The Caller', 'The Location', or 'Multiple'. New values are created by extending this registry in a subsequent RFC.
Data About: A hint as to if the block is considered descriptive of the call, the caller, or the location (or is applicable to more than one), which can help PSAPs and other entities determine if they wish to process the block. Note that this is only a hint; entities need to consider the block's contents, not just this field, when determining if they wish to process the block (which is why the field only exists in the registry and is not contained within the block). The value MUST be either 'The Call', 'The Caller', 'The Location', or 'Multiple'. New values are created by extending this registry in a subsequent RFC.
Reference: The document that describes the data object.
Reference: The document that describes the data object.
Note that the tokens in this registry are part of the 'EmergencyCallData' compound value; when used as a value of the 'purpose' parameter of a Call-Info header field, the values listed in this registry are prefixed by 'EmergencyCallData.' per the 'EmergencyCallData' registration; see Section 11.2.
Note that the tokens in this registry are part of the 'EmergencyCallData' compound value; when used as a value of the 'purpose' parameter of a Call-Info header field, the values listed in this registry are prefixed by 'EmergencyCallData.' per the 'EmergencyCallData' registration; see Section 11.2.
The initial set of values is listed in Figure 25.
値の初期セットは、図25にリストされています。
+----------------+--------------+------------+
| Token | Data About | Reference |
+----------------+--------------+------------+
| ProviderInfo | The Call | RFC 7852 |
| ServiceInfo | The Call | RFC 7852 |
| DeviceInfo | The Call | RFC 7852 |
| SubscriberInfo | The Call | RFC 7852 |
| Comment | The Call | RFC 7852 |
+----------------+--------------+------------+
Figure 25: Additional Data Blocks Registry
図25：追加のデータブロックレジストリ
This document defines the 'EmergencyCallData' value for the 'purpose' parameter of the Call-Info header field [RFC3261]. IANA has added this document to the list of references for the 'purpose' value of Call-Info in the "Header Field Parameters and Parameter Values" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry. Note that 'EmergencyCallData' is a compound value; when used as a value of the 'purpose' parameter of a Call-Info header field, 'EmergencyCallData' is immediately followed by a dot ('.') and a value from the "Emergency Call Data Types" registry; see Section 11.1.9.
このドキュメントでは、Call-Infoヘッダーフィールド[RFC3261]の「purpose」パラメータの「EmergencyCallData」値を定義しています。 IANAは、このドキュメントを、「Session Initiation Protocol（SIP）Parameters」レジストリの「Header Field Parameters and Parameter Values」サブレジストリにあるCall-Infoの「目的」値の参照リストに追加しました。 「EmergencyCallData」は複合値であることに注意してください。 Call-Infoヘッダーフィールドの「purpose」パラメータの値として使用すると、「EmergencyCallData」の直後にドット（「。」）と「緊急コールデータタイプ」レジストリの値が続きます。セクション11.1.9を参照してください。
This section registers the namespace specified in Section 11.5.1 in the provided-by registry established by RFC 4119, for usage within the <provided-by> element of a PIDF-LO.
このセクションでは、PIDF-LOの<provided-by>要素内で使用するために、セクション11.5.1で指定された名前空間をRFC 4119によって確立された提供者レジストリに登録します。
The schema for the <provided-by> element used by this document is specified in Section 8.6.
このドキュメントで使用される<provided-by>要素のスキーマは、セクション8.6で指定されています。
11.4.1. MIME Content-Type Registration for 'application/ EmergencyCallData.ProviderInfo+xml'
11.4.1. 「application / EmergencyCallData.ProviderInfo + xml」のMIMEコンテンツタイプ登録
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
この仕様は、RFC 6838 [RFC6838]の手順とRFC 7303 [RFC7303]のガイドラインに従って、新しいMIMEメディアタイプの登録を要求します。
Type name: application
タイプ名：アプリケーション
Subtype name: EmergencyCallData.ProviderInfo+xml
Subtype name: EmergencyCallData.ProviderInfo+xml
Mandatory parameters: N/A
必須パラメーター：N / A
Optional parameters: charset (indicates the character encoding of the contents)
オプションのパラメーター：charset（内容の文字エンコードを示します）
Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
エンコーディングに関する考慮事項：文字エンコーディングに応じて、8ビット文字を含むことができるXMLを使用します。 RFC 7303 [RFC7303]のセクション3.2をご覧ください。
Security considerations: This content type is designed to carry the data provider information, which is a sub-category of additional data about an emergency call. Since this data can contain personal information, appropriate precautions are needed to limit unauthorized access, inappropriate disclosure, and eavesdropping of personal information. Please refer to Sections 9 and 10 for more information.
セキュリティに関する考慮事項：このコンテンツタイプは、緊急通報に関する追加データのサブカテゴリであるデータプロバイダー情報を伝達するように設計されています。このデータには個人情報が含まれる可能性があるため、不正アクセス、不適切な開示、個人情報の盗聴を制限するための適切な予防策が必要です。詳細については、セクション9および10を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 7852
公開された仕様：RFC 7852
Applications that use this media type: Emergency Services
このメディアタイプを使用するアプリケーション：緊急サービス
Additional information:
追加情報：
Magic Number: N/A
マジックナンバー：N / A
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード： 'TEXT'
Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
詳細情報の人とメールアドレス：Hannes Tschofenig、Hannes.Tschofenig @ gmx.net
Intended usage: LIMITED USE
使用目的：限定使用
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、IETF ECRITワーキンググループの作業項目であり、メーリングリストのアドレスは<ecrit@ietf.org>です。
Change controller: The IESG <iesg@ietf.org>
11.4.2. MIME Content-Type Registration for 'application/ EmergencyCallData.ServiceInfo+xml'
11.4.2. 「application / EmergencyCallData.ServiceInfo + xml」のMIMEコンテンツタイプ登録
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
Type name: application
タイプ名：アプリケーション
Subtype name: EmergencyCallData.ServiceInfo+xml
サブタイプ名：EmergencyCallData.ServiceInfo + xml
Mandatory parameters: N/A
必須パラメーター：N / A
Optional parameters: charset (indicates the character encoding of the contents)
オプションのパラメーター：charset（内容の文字エンコードを示します）
Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
エンコーディングに関する考慮事項：文字エンコーディングに応じて、8ビット文字を含むことができるXMLを使用します。 RFC 7303 [RFC7303]のセクション3.2をご覧ください。
Security considerations: This content type is designed to carry the service information, which is a sub-category of additional data about an emergency call. Since this data can contain personal information, appropriate precautions are needed to limit unauthorized access, inappropriate disclosure, and eavesdropping of personal information. Please refer to Sections 9 and 10 for more information.
セキュリティに関する考慮事項：このコンテンツタイプは、緊急通話に関する追加データのサブカテゴリであるサービス情報を伝達するように設計されています。このデータには個人情報が含まれる可能性があるため、不正アクセス、不適切な開示、個人情報の盗聴を制限するための適切な予防策が必要です。詳細については、セクション9および10を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 7852
公開された仕様：RFC 7852
Applications that use this media type: Emergency Services
このメディアタイプを使用するアプリケーション：緊急サービス
Additional information:
追加情報：
Magic Number: N/A
マジックナンバー：N / A
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード： 'TEXT'
Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
詳細情報の人とメールアドレス：Hannes Tschofenig、Hannes.Tschofenig @ gmx.net
Intended usage: LIMITED USE
使用目的：限定使用
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、IETF ECRITワーキンググループの作業項目であり、メーリングリストのアドレスは<ecrit@ietf.org>です。
Change controller: The IESG <iesg@ietf.org>
11.4.3. MIME Content-Type Registration for 'application/ EmergencyCallData.DeviceInfo+xml'
11.4.3. 「application / EmergencyCallData.DeviceInfo + xml」のMIMEコンテンツタイプ登録
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
この仕様は、RFC 6838 [RFC6838]の手順とRFC 7303 [RFC7303]のガイドラインに従って、新しいMIMEメディアタイプの登録を要求します。
Type name: application
タイプ名：アプリケーション
Subtype name: EmergencyCallData.DeviceInfo+xml
Subtype name: EmergencyCallData.DeviceInfo+xml
Mandatory parameters: N/A
必須パラメーター：N / A
Optional parameters: charset (indicates the character encoding of the contents) Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
オプションのパラメーター：charset（コンテンツの文字エンコードを示します）エンコードの考慮事項：文字エンコードに応じて、8ビット文字を含むことができるXMLを使用します。 RFC 7303 [RFC7303]のセクション3.2をご覧ください。
Security considerations: This content type is designed to carry device information, which is a sub-category of additional data about an emergency call. Since this data contains personal information, appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Please refer to Sections 9 and 10 for more information.
セキュリティに関する考慮事項：このコンテンツタイプは、緊急通話に関する追加データのサブカテゴリであるデバイス情報を伝達するように設計されています。このデータには個人情報が含まれているため、不正アクセス、第三者への不適切な開示、およびこの情報の盗聴を制限するために適切な予防策を講じる必要があります。詳細については、セクション9および10を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 7852
Published specification: RFC 7852
Applications that use this media type: Emergency Services
このメディアタイプを使用するアプリケーション：緊急サービス
Additional information:
追加情報：
Magic Number: N/A
マジックナンバー：N / A
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード： 'TEXT'
Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
詳細情報の人とメールアドレス：Hannes Tschofenig、Hannes.Tschofenig @ gmx.net
Intended usage: LIMITED USE
使用目的：限定使用
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、IETF ECRITワーキンググループの作業項目であり、メーリングリストのアドレスは<ecrit@ietf.org>です。
Change controller: The IESG <iesg@ietf.org>
11.4.4. MIME Content-Type Registration for 'application/ EmergencyCallData.SubscriberInfo+xml'
11.4.4. 「application / EmergencyCallData.SubscriberInfo + xml」のMIMEコンテンツタイプ登録
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
この仕様は、RFC 6838 [RFC6838]の手順とRFC 7303 [RFC7303]のガイドラインに従って、新しいMIMEメディアタイプの登録を要求します。
Type name: application
タイプ名：アプリケーション
Subtype name: EmergencyCallData.SubscriberInfo+xml
サブタイプ名：EmergencyCallData.SubscriberInfo + xml
Mandatory parameters: N/A Optional parameters: charset (indicates the character encoding of the contents)
必須パラメーター：N / Aオプションパラメーター：charset（コンテンツの文字エンコードを示します）
Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
エンコーディングに関する考慮事項：文字エンコーディングに応じて、8ビット文字を含むことができるXMLを使用します。 RFC 7303 [RFC7303]のセクション3.2をご覧ください。
Security considerations: This content type is designed to carry owner/subscriber information, which is a sub-category of additional data about an emergency call. Since this data contains personal information, appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Please refer to Sections 9 and 10 for more information.
セキュリティに関する考慮事項：このコンテンツタイプは、所有者/加入者情報を運ぶように設計されています。これは、緊急通話に関する追加データのサブカテゴリです。このデータには個人情報が含まれているため、不正アクセス、第三者への不適切な開示、およびこの情報の盗聴を制限するために適切な予防策を講じる必要があります。詳細については、セクション9および10を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 7852
公開された仕様：RFC 7852
Applications that use this media type: Emergency Services
このメディアタイプを使用するアプリケーション：緊急サービス
Additional information:
追加情報：
Magic Number: N/A
マジックナンバー：N / A
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード： 'TEXT'
Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
詳細情報の人とメールアドレス：Hannes Tschofenig、Hannes.Tschofenig @ gmx.net
Intended usage: LIMITED USE
使用目的：限定使用
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、IETF ECRITワーキンググループの作業項目であり、メーリングリストのアドレスは<ecrit@ietf.org>です。
Change controller: The IESG <iesg@ietf.org>
11.4.5. MIME Content-Type Registration for 'application/ EmergencyCallData.Comment+xml'
11.4.5. 「application / EmergencyCallData.Comment + xml」のMIMEコンテンツタイプ登録
This specification requests the registration of a new MIME media type according to the procedures of RFC 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303].
この仕様は、RFC 6838 [RFC6838]の手順とRFC 7303 [RFC7303]のガイドラインに従って、新しいMIMEメディアタイプの登録を要求します。
Type name: application Subtype name: EmergencyCallData.Comment+xml
タイプ名：アプリケーションサブタイプ名：EmergencyCallData.Comment + xml
Mandatory parameters: N/A
必須パラメーター：N / A
Optional parameters: charset (indicates the character encoding of the contents)
オプションのパラメーター：charset（内容の文字エンコードを示します）
Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
エンコーディングに関する考慮事項：文字エンコーディングに応じて、8ビット文字を含むことができるXMLを使用します。 RFC 7303 [RFC7303]のセクション3.2をご覧ください。
Security considerations: This content type is designed to carry a comment, which is a sub-category of additional data about an emergency call. This data can contain personal information. Appropriate precautions are needed to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Please refer to Sections 9 and 10 for more information.
セキュリティに関する考慮事項：このコンテンツタイプはコメントを伝えるように設計されています。コメントは、緊急通話に関する追加データのサブカテゴリです。このデータには個人情報を含めることができます。不正アクセス、第三者への不適切な開示、およびこの情報の盗聴を制限するには、適切な予防策が必要です。詳細については、セクション9および10を参照してください。
Interoperability considerations: N/A
相互運用性に関する考慮事項：N / A
Published specification: RFC 7852
公開された仕様：RFC 7852
Applications that use this media type: Emergency Services
このメディアタイプを使用するアプリケーション：緊急サービス
Additional information:
追加情報：
Magic Number: N/A
マジックナンバー：N / A
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード： 'TEXT'
Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
詳細情報の人とメールアドレス：Hannes Tschofenig、Hannes.Tschofenig @ gmx.net
Intended usage: LIMITED USE
使用目的：限定使用
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、IETF ECRITワーキンググループの作業項目であり、メーリングリストのアドレスは<ecrit@ietf.org>です。
Change controller: The IESG <iesg@ietf.org>
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.2. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Data Provider Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Data Provider Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Service Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Service Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Device Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2>Device Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:
Owner/Subscriber Information</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2> Owner/Subscriber Information</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
11.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment
This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:EmergencyCallData:Comment
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
登録者の連絡先：IESG <iesg@ietf.org>から委任されたIETF、ECRITワーキンググループ、<ecrit@ietf.org>。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for Additional Emergency Call Data:Comment
</title>
</head>
<body>
<h1>Namespace for Additional Data Related to an Emergency Call
</h1>
<h2> Comment</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7852.txt">
RFC 7852</a>.</p>
</body>
</html>
END
This specification registers the following schemas, as per the guidelines in RFC 3688 [RFC3688].
この仕様は、RFC 3688 [RFC3688]のガイドラインに従って、次のスキーマを登録します。
ID: EmergencyCallData URI: urn:ietf:params:xml:schema:EmergencyCallData Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Section 8.6.
ID：EmergencyCallData URI：urn：ietf：params：xml：schema：EmergencyCallData登録者の連絡先：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマはセクション8.6にあります。
ID: EmergencyCallData:ProviderInfo URI: urn:ietf:params:xml:schema:EmergencyCallData:ProviderInfo Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Figure 19.
ID：EmergencyCallData：ProviderInfo URI：urn：ietf：params：xml：schema：EmergencyCallData：ProviderInfo登録者の連絡先：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマは図19にあります。
ID: EmergencyCallData:ServiceInfo URI: urn:ietf:params:xml:schema:EmergencyCallData:ServiceInfo Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Figure 20.
ID：EmergencyCallData：ServiceInfo URI：urn：ietf：params：xml：schema：EmergencyCallData：ServiceInfo登録者の連絡先：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマは図20にあります。
ID: EmergencyCallData:DeviceInfo URI: urn:ietf:params:xml:schema:EmergencyCallData:DeviceInfo Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org).
ID：EmergencyCallData：DeviceInfo URI：urn：ietf：params：xml：schema：EmergencyCallData：DeviceInfo Registrant Contact：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。
XML: The XML schema can be found in Figure 21.
XML：XMLスキーマは図21にあります。
ID: EmergencyCallData:SubscriberInfo URI: urn:ietf:params:xml:schema:EmergencyCallData:SubscriberInfo Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Section 8.4.
ID：EmergencyCallData：SubscriberInfo URI：urn：ietf：params：xml：schema：EmergencyCallData：SubscriberInfo登録者の連絡先：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマはセクション8.4にあります。
ID: EmergencyCallData:Comment URI: urn:ietf:params:xml:schema:EmergencyCallData:Comment Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Section 8.5.
ID：EmergencyCallData：Comment URI：urn：ietf：params：xml：schema：EmergencyCallData：Comment Registrant Contact：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマはセクション8.5にあります。
ID: vcard-4.0 URI: urn:ietf:params:xml:ns:vcard-4.0 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML schema can be found in Appendix A.
ID：vcard-4.0 URI：urn：ietf：params：xml：ns：vcard-4.0登録者の連絡先：IETF、ECRITワーキンググループ（ecrit@ietf.org）、IESG（iesg@ietf.org）から委任されたもの。 XML：XMLスキーマは付録Aにあります。
This document registers a new value in the "vCard Parameter Values" registry as defined by [RFC6350] with the following template:
このドキュメントは、[RFC6350]で定義されている「vCardパラメータ値」レジストリに、次のテンプレートを使用して新しい値を登録します。
Value: main-number
値：メイン番号
Purpose: The main telephone number, typically of an enterprise, as opposed to a direct-dial number of an individual employee
目的：個々の従業員の直通電話番号ではなく、通常は企業の主要電話番号
Conformance: This value can be used with the 'TYPE' parameter applied on the 'TEL' property
適合性：この値は、「TEL」プロパティに適用された「TYPE」パラメータで使用できます。
Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90
00
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <http://www.rfc-editor.org/info/rfc2392>.
[RFC2392] Levinson、E。、「Content-ID and Message-ID Uniform Resource Locators」、RFC 2392、DOI 10.17487 / RFC2392、1998年8月、<http://www.rfc-editor.org/info/rfc2392>。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, DOI 10.17487/RFC3204, December 2001, <http://www.rfc-editor.org/info/rfc3204>.
[RFC3204] Zimmerer、E.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M。、およびM. Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC 3204、DOI 10.17487 / RFC3204、2001年12月、<http://www.rfc-editor.org/info/rfc3204>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, DOI 10.17487/RFC3459, January 2003, <http://www.rfc-editor.org/info/rfc3459>.
[RFC3459]バーガー、E。、「重要なコンテンツの多目的インターネットメール拡張（MIME）パラメータ」、RFC 3459、DOI 10.17487 / RFC3459、2003年1月、<http://www.rfc-editor.org/info/rfc3459 >。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H.、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, <http://www.rfc-editor.org/info/rfc4119>.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、DOI 10.17487 / RFC4119、2005年12月、<http://www.rfc-editor.org/info/rfc4119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, DOI 10.17487/RFC5621, September 2009, <http://www.rfc-editor.org/info/rfc5621>.
[RFC5621]カマリロ、G。、「セッション開始プロトコル（SIP）でのメッセージ本文の処理」、RFC 5621、DOI 10.17487 / RFC5621、2009年9月、<http://www.rfc-editor.org/info/rfc5621> 。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<http://www.rfc-editor.org/info/rfc5646>。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <http://www.rfc-editor.org/info/rfc6350>.
[RFC6350] Perreault、S。、「vCard Format Specification」、RFC 6350、DOI 10.17487 / RFC6350、2011年8月、<http://www.rfc-editor.org/info/rfc6350>。
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, <http://www.rfc-editor.org/info/rfc6351>.
[RFC6351] Perreault、S。、「xCard：vCard XML表現」、RFC 6351、DOI 10.17487 / RFC6351、2011年8月、<http://www.rfc-editor.org/info/rfc6351>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <http://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H。およびC. Lilley、「XML Media Types」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<http://www.rfc-editor.org/info/rfc7303>。
[ECRIT-WG-wiki] IETF ECRIT WG Wiki, "Additional Data Examples", July 2015, <http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/ WikiStart/additional-data-examples.zip>.
[ECRIT-WG-wiki] IETF ECRIT WG Wiki、「追加データの例」、2015年7月、<http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/ WikiStart / additional-data-examples。 zip>。
[Err3047] RFC Errata, Erratum ID 3047, RFC 6351.
[Err3047] RFC Errata、Erratum ID 3047、RFC 6351。
[HUMAN-LANG] Gellens, R., "Negotiating Human Language in Real-Time Communications", Work in Progress, draft-ietf-slim-negotiating-human-language-04, July 2016.
[HUMAN-LANG] Gellens、R。、「リアルタイムコミュニケーションにおける人間の言語の交渉」、進行中の作業、draft-ietf-slim-negotiating-human-language-04、2016年7月。
[IANA-XML-Schemas] IANA, "IETF XML Registry", <http://www.iana.org/assignments/xml-registry>.
[ΙΑΝΑ-ΧΜΛ-Σχέμας]ΙΑΝΑ、 "ΙΕΤΦΧΜΛΡείγιστρυ"、
[IEEE-1512-2006] IEEE, "IEEE Standard for Common Incident Management Message Sets for Use by Emergency Management Centers", IEEE Std 1512-2006, DOI 10.1109/IEEESTD.2006.224678, August 2006, <https://standards.ieee.org/findstds/ standard/1512-2006.html>.
[IEEE-1512-2006] IEEE、「緊急管理センターが使用する一般的なインシデント管理メッセージセットのIEEE規格」、IEEE Std 1512-2006、DOI 10.1109 / IEEESTD.2006.224678、2006年8月、<https://standards.ieee .org / findstds / standard / 1512-2006.html>。
[LanguageSubtagRegistry] IANA, "Language Subtag Registry", <http://www.iana.org/assignments/ language-subtag-registry>.
[LanguageSubtagRegistry] IANA、「Language Subtag Registry」、<http://www.iana.org/assignments/ language-subtag-registry>。
[LERG] Telcordia Technologies, Inc., "LERG Routing Guide", ANI II Digits Definitions, June 2015.
[LERG] Telcordia Technologies、Inc。、「LERG Routing Guide」、ANI II Digits Definitions、2015年6月。
[NANP] North American Numbering Plan Administration (NANPA), "ANI II Digits Assignments", September 2015, <http://nanpa.com/number_resource_info/ ani_ii_assignments.html>.
[NANP]北米番号計画管理（NANPA）、「ANI II Digits Assignments」、2015年9月、<http://nanpa.com/number_resource_info/ ani_ii_assignments.html>。
[nc911] North Carolina 911 Board, "Wireless 911 for Telecommunicators", January 2009, <https://www.nc911.nc.gov/pdf/ A_TelecommunicatorReference.pdf>.
[nc911]ノースカロライナ911ボード、「ワイヤレスコミュニケーター用911」、2009年1月、<https://www.nc911.nc.gov/pdf/ A_TelecommunicatorReference.pdf>。
[NENA-02-010] National Emergency Number Association (NENA), "NENA Standard Data Formats for 9-1-1 Data Exchange & GIS Mapping", NENA-02-010, Version 9, December 2010, <http://www.nena.org>.
[NENA-02-010] National Emergency Number Association（NENA）、「NENA Standard Data Formats for 9-1-1 Data Exchange＆GIS Mapping」、NENA-02-010、Version 9、2010年12月、<http：// www.nena.org>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, DOI 10.17487/RFC5012, January 2008, <http://www.rfc-editor.org/info/rfc5012>.
[RFC5012] Schulzrinne、H。およびR. Marshall、編、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、DOI 10.17487 / RFC5012、2008年1月、<http://www.rfc-editor.org/ info / rfc5012>。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, February 2008, <http://www.rfc-editor.org/info/rfc5139>.
[RFC5139] Thomson、M.およびJ. Winterbottom、「Resive Civic Location Format for Presence Information Data Format Location Object（PIDF-LO）」、RFC 5139、DOI 10.17487 / RFC5139、2008年2月、<http：//www.rfc -editor.org/info/rfc5139>。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, <http://www.rfc-editor.org/info/rfc5491>.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、DOI 10.17487 / RFC5491、2009年3月、<http://www.rfc-editor.org/info/rfc5491>。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, DOI 10.17487/RFC5582, September 2009, <http://www.rfc-editor.org/info/rfc5582>.
[RFC5582] Schulzrinne、H。、「Location-to-URL Mapping Architecture and Framework」、RFC 5582、DOI 10.17487 / RFC5582、2009年9月、<http://www.rfc-editor.org/info/rfc5582>。
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, DOI 10.17487/RFC5962, September 2010, <http://www.rfc-editor.org/info/rfc5962>.
[RFC5962] Schulzrinne、H.、Singh、V.、Tschofenig、H。、およびM. Thomson、「Presence Information Data Format Location Object（PIDF-LO）への動的拡張」、RFC 5962、DOI 10.17487 / RFC5962、9月2010、<http://www.rfc-editor.org/info/rfc5962>。
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, DOI 10.17487/RFC5985, September 2010, <http://www.rfc-editor.org/info/rfc5985>.
[RFC5985] Barnes、M。、編、「HTTP対応ロケーション配信（HELD）」、RFC 5985、DOI 10.17487 / RFC5985、2010年9月、<http://www.rfc-editor.org/info/rfc5985> 。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6443] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、RFC 6443、DOI 10.17487 / RFC6443、2011年12月、<http：// www .rfc-editor.org / info / rfc6443>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and R. George, "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, <http://www.rfc-editor.org/info/rfc6848>.
[RFC6848] Winterbottom、J.、Thomson、M.、Barnes、R.、Rosen、B。、およびR. George、「Presence Information Data Format Location Object（PIDF-LO）でのCivicアドレス拡張の指定」、RFC 6848 、DOI 10.17487 / RFC6848、2013年1月、<http://www.rfc-editor.org/info/rfc6848>。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <http://www.rfc-editor.org/info/rfc6881>.
[RFC6881]ローゼン、B。およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、BCP 181、RFC 6881、DOI 10.17487 / RFC6881、2013年3月、<http：//www.rfc-editor .org / info / rfc6881>。
[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, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. Thomson, "Relative Location Representation", RFC 7035, DOI 10.17487/RFC7035, October 2013, <http://www.rfc-editor.org/info/rfc7035>.
[RFC7035] Thomson、M.、Rosen、B.、Stanley、D.、Bajko、G。、およびA. Thomson、「Relative Location Representation」、RFC 7035、DOI 10.17487 / RFC7035、2013年10月、<http：// www.rfc-editor.org/info/rfc7035>。
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, DOI 10.17487/RFC7090, April 2014, <http://www.rfc-editor.org/info/rfc7090>.
[RFC7090] Schulzrinne、H.、Tschofenig、H.、Holmberg、C。、およびM. Patel、「Public Safety Answering Point（PSAP）Callback」、RFC 7090、DOI 10.17487 / RFC7090、April 2014、<http：// www.rfc-editor.org/info/rfc7090>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
Appendix A. XML Schema for vCard/xCard
付録A. vCard / xCardのXMLスキーマ
This section contains the vCard/xCard XML schema version of the Relax NG schema defined in RFC 6351 [RFC6351] for use with the XML schemas defined in this document. In addition to mapping the Relax NG schema to an XML schema, this specification applies an erratum raised for RFC 6351 regarding the type definition; see RFC Erratum ID 3047 [Err3047].
このセクションには、RFC 6351 [RFC6351]で定義されているRelax NGスキーマのvCard / xCard XMLスキーマバージョンが含まれており、このドキュメントで定義されているXMLスキーマで使用できます。この仕様は、Relax NGスキーマをXMLスキーマにマッピングすることに加えて、型定義に関してRFC 6351に対して提起された正誤表を適用します。 RFC Erratum ID 3047 [Err3047]を参照してください。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ns1="urn:ietf:params:xml:ns:vcard-4.0"
elementFormDefault="qualified">
<!--
3.3
iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" }
x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" }
-->
<xs:simpleType name="iana-token">
<xs:annotation>
<xs:documentation>Section 3.3: vCard Format Specification
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="x-name">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!--
4.1
-->
<xs:element name="text" type="xs:string"/>
<xs:group name="value-text-list">
<xs:sequence>
<xs:element ref="ns1:text" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<!-- 4.2 -->
<xs:element name="uri" type="xs:anyURI"/>
<!-- 4.3.1 -->
<xs:element name="date"
substitutionGroup="ns1:value-date-and-or-time">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern
value="\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- 4.3.2 -->
<xs:element name="time"
substitutionGroup="ns1:value-date-and-or-time">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value=
"(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)(Z|[+\-]\d\d(\d\d)?)?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- 4.3.3 -->
<xs:element name="date-time"
substitutionGroup="ns1:value-date-and-or-time">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value=
"(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?(Z|[+\-]\d\d(\d\d)?)?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- 4.3.4 -->
<xs:element name="value-date-and-or-time" abstract="true"/>
<!-- 4.3.5 -->
<xs:complexType name="value-timestamp">
<xs:sequence>
<xs:element ref="ns1:timestamp"/>
</xs:sequence>
</xs:complexType>
<xs:element name="timestamp">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- 4.4 -->
<xs:element name="boolean" type="xs:boolean"/>
<!-- 4.5 -->
<xs:element name="integer" type="xs:integer"/>
<!-- 4.6 -->
<xs:element name="float" type="xs:float"/>
<!-- 4.7 -->
<xs:element name="utc-offset">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[+\-]\d\d(\d\d)?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- 4.8 -->
<xs:element name="language-tag">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value=
"([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})(-[a-z]{4})?
(-([a-z]{2}|\d{3}))?(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*
(-[0-9a-wyz](-[0-9a-z]{2,8})+)*(-x(-[0-9a-z]{1,8})+)?
|x(-[0-9a-z]{1,8})+|[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!--
5.1
-->
<xs:group name="param-language">
<xs:annotation>
<xs:documentation>Section 5: Parameters</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="ns1:language" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="language">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:language-tag"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.2 -->
<xs:group name="param-pref">
<xs:sequence>
<xs:element ref="ns1:pref" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="pref">
<xs:complexType>
<xs:sequence>
<xs:element name="integer">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.4 -->
<xs:group name="param-altid">
<xs:sequence>
<xs:element ref="ns1:altid" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="altid">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.5 -->
<xs:group name="param-pid">
<xs:sequence>
<xs:element ref="ns1:pid" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="pid">
<xs:complexType>
<xs:sequence>
<xs:element name="text" maxOccurs="unbounded">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\d+(\.\d+)?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.6 -->
<xs:group name="param-type">
<xs:sequence>
<xs:element ref="ns1:type" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="type">
<xs:complexType>
<xs:sequence>
<xs:element name="text" maxOccurs="unbounded">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="work"/>
<xs:enumeration value="home"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.7 -->
<xs:group name="param-mediatype">
<xs:sequence>
<xs:element ref="ns1:mediatype" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="mediatype">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.8 -->
<xs:group name="param-calscale">
<xs:sequence>
<xs:element ref="ns1:calscale" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="calscale">
<xs:complexType>
<xs:sequence>
<xs:element name="text">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="gregorian"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.9 -->
<xs:group name="param-sort-as">
<xs:sequence>
<xs:element ref="ns1:sort-as" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="sort-as">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:text" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 5.10 -->
<xs:group name="param-geo">
<xs:sequence>
<xs:element name="geo" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
<!-- 5.11 -->
<xs:group name="param-tz">
<xs:sequence>
<xs:element name="tz" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element ref="ns1:text"/>
<xs:element ref="ns1:uri"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
<!--
6.1.3
-->
<xs:element name="source">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.1.4 -->
<xs:element name="kind">
<xs:complexType>
<xs:sequence>
<xs:annotation>
<xs:documentation>
The text value must be one of: individual, group, org,
location or a ns1:x-name or a ns1:iana-token value
</xs:documentation>
</xs:annotation>
<xs:element name="text" type="xs:token"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.1 -->
<xs:element name="fn">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.2 -->
<xs:element name="n">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-sort-as"/>
<xs:group ref="ns1:param-altid"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:surname"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:given"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:additional"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:prefix"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:suffix"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="surname" type="xs:string"/>
<xs:element name="given" type="xs:string"/>
<xs:element name="additional" type="xs:string"/>
<xs:element name="prefix" type="xs:string"/>
<xs:element name="suffix" type="xs:string"/>
<!-- 6.2.3 -->
<xs:element name="nickname">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group ref="ns1:value-text-list"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.4 -->
<xs:element name="photo">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.5 -->
<xs:element name="bday">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-calscale"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:value-date-and-or-time"/>
<xs:element ref="ns1:text"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.6 -->
<xs:element name="anniversary">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-calscale"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:value-date-and-or-time"/>
<xs:element ref="ns1:text"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.2.7 -->
<xs:element name="gender">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:sex"/>
<xs:element ref="ns1:identity" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="sex">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value=""/>
<xs:enumeration value="M"/>
<xs:enumeration value="F"/>
<xs:enumeration value="O"/>
<xs:enumeration value="N"/>
<xs:enumeration value="U"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="identity" type="xs:string"/>
<!-- 6.3.1 -->
<xs:group name="param-label">
<xs:sequence>
<xs:element ref="ns1:label" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="label">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="adr">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-geo"/>
<xs:group ref="ns1:param-tz"/>
<xs:group ref="ns1:param-label"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:pobox"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:ext"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:street"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:locality"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:region"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:code"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ns1:country"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="pobox" type="xs:string"/>
<xs:element name="ext" type="xs:string"/>
<xs:element name="street" type="xs:string"/>
<xs:element name="locality" type="xs:string"/>
<xs:element name="region" type="xs:string"/>
<xs:element name="code" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
<!-- 6.4.1 -->
<xs:element name="tel">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"
minOccurs="0"/>
<xs:group ref="ns1:param-pid"
minOccurs="0"/>
<xs:group ref="ns1:param-pref"
minOccurs="0"/>
<xs:element name="type" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="text"
type="xs:string"
maxOccurs="unbounded">
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:text"/>
<xs:element ref="ns1:uri"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.4.2 -->
<xs:element name="email">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.4.3 -->
<xs:element name="impp">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.4.4 -->
<xs:element name="lang">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:language-tag"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.5.1 -->
<xs:group name="property-tz">
<xs:sequence>
<xs:element name="tz">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group
ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:text"/>
<xs:element ref="ns1:uri"/>
<xs:element ref="ns1:utc-offset"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
<!-- 6.5.2 -->
<xs:group name="property-geo">
<xs:sequence>
<xs:element name="geo">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group
ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
<!-- 6.6.1 -->
<xs:element name="title">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.6.2 -->
<xs:element name="role">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.6.3 -->
<xs:element name="logo">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.6.4 -->
<xs:element name="org">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-sort-as"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group ref="ns1:value-text-list"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.6.5 -->
<xs:element name="member">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.6.6 -->
<xs:element name="related">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:element name="type" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="text" maxOccurs="unbounded">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="work"/>
<xs:enumeration value="home"/>
<xs:enumeration value="contact"/>
<xs:enumeration value="acquaintance"/>
<xs:enumeration value="friend"/>
<xs:enumeration value="met"/>
<xs:enumeration value="co-worker"/>
<xs:enumeration value="colleague"/>
<xs:enumeration value="co-resident"/>
<xs:enumeration value="neighbor"/>
<xs:enumeration value="child"/>
<xs:enumeration value="parent"/>
<xs:enumeration value="sibling"/>
<xs:enumeration value="spouse"/>
<xs:enumeration value="kin"/>
<xs:enumeration value="muse"/>
<xs:enumeration value="crush"/>
<xs:enumeration value="date"/>
<xs:enumeration value="sweetheart"/>
<xs:enumeration value="me"/>
<xs:enumeration value="agent"/>
<xs:enumeration value="emergency"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:uri"/>
<xs:element ref="ns1:text"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.1 -->
<xs:element name="categories">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group ref="ns1:value-text-list"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.2 -->
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.3 -->
<xs:element name="prodid">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:text"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.4 -->
<xs:element name="rev" type="ns1:value-timestamp"/>
<!-- 6.7.5 -->
<xs:element name="sound">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-language"/>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.6 -->
<xs:element name="uid">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.7.7 -->
<xs:element name="clientpidmap">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:sourceid"/>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="sourceid" type="xs:positiveInteger"/>
<!-- 6.7.8 -->
<xs:element name="url">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.8.1 -->
<xs:element name="key">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element ref="ns1:uri"/>
<xs:element ref="ns1:text"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.9.1 -->
<xs:element name="fburl">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.9.2 -->
<xs:element name="caladruri">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- 6.9.3 -->
<xs:element name="caluri">
<xs:complexType>
<xs:sequence>
<xs:element name="parameters" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/>
<xs:group ref="ns1:param-type"/>
<xs:group ref="ns1:param-mediatype"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ns1:uri"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Top-level grammar -->
<xs:group name="property">
<xs:sequence>
<xs:element ref="ns1:adr" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:anniversary" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:bday" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:caladruri" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:caluri" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:categories" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:clientpidmap" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:email" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:fburl" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:fn" minOccurs="1"
maxOccurs="unbounded"/>
<xs:group ref="ns1:property-geo" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:impp" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:key" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:kind" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:lang" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:logo" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:member" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:n" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:nickname" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:org" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:photo" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:prodid" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:related" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:rev" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:role" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:gender" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:sound" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:source" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:tel" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:title" minOccurs="0"
maxOccurs="unbounded"/>
<xs:group ref="ns1:property-tz" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="ns1:uid" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="ns1:url" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:element name="vcards">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns1:vcard" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="vcardType">
<xs:sequence>
<xs:group ref="ns1:property"/>
<xs:element ref="ns1:group" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="vcard" type="ns1:vcardType"/>
<xs:element name="group">
<xs:complexType>
<xs:group ref="ns1:property"/>
<xs:attribute name="name" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
This document defines a number of XML schemas and contains various examples. Extracting the XML and validating the examples against the schemas can be challenging, especially due to the formatting limitations introduced by IETF RFCs. For those readers who copy the XML schemas and examples directly from this document, please consider that errors might be introduced due to line breaks and extra whitespaces in the regular expressions contained in the vCard schema in Appendix A. To validate the PIDF-LO from Figure 18, it is also necessary to consult the referenced RFCs and copy the schemas necessary for successful validation.
このドキュメントでは、いくつかのXMLスキーマを定義し、さまざまな例を紹介しています。 XMLの抽出とスキーマに対する例の検証は、特にIETF RFCによって導入されたフォーマットの制限により、困難な場合があります。このドキュメントからXMLスキーマと例を直接コピーする読者は、付録AのvCardスキーマに含まれる正規表現の改行と余分な空白が原因でエラーが発生する可能性があることを考慮してください。図からPIDF-LOを検証するには18、参照されたRFCを参照し、検証の成功に必要なスキーマをコピーすることも必要です。
The XML schemas found in this document include a 'SchemaLocation' attribute. Depending on the location of the downloaded schema files, you may need to adjust this schema location or configure your XML editor to point to the location.
このドキュメントにあるXMLスキーマには、「SchemaLocation」属性が含まれています。ダウンロードしたスキーマファイルの場所に応じて、このスキーマの場所を調整するか、その場所を指すようにXMLエディターを構成する必要があります。
For the convenience of the reader, the schemas are available at [IANA-XML-Schemas], and the XML examples are available at the IETF ECRIT working group wiki page [ECRIT-WG-wiki].
読者の便宜のために、スキーマは[IANA-XML-Schemas]で入手でき、XMLの例はIETF ECRITワーキンググループのWikiページ[ECRIT-WG-wiki]で入手できます。
Acknowledgments
Acknowledgments
This work was originally started in NENA and has benefited from a large number of participants involved in NENA standardization efforts, originally in the Long Term Definition working group, the Data Technical Committee, and most recently in the Additional Data working group. The authors are grateful for the initial work and extended comments provided by many NENA participants, including Delaine Arnold, Marc Berryman, Guy Caron, Brian Dupras, Mark Fletcher, James Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback regarding the vCard/xCard use in this specification.
This work was originally started in NENA and has benefited from a large number of participants involved in NENA standardization efforts, originally in the Long Term Definition working group, the Data Technical Committee, and most recently in the Additional Data working group. The authors are grateful for the initial work and extended comments provided by many NENA participants, including Delaine Arnold, Marc Berryman, Guy Caron, Brian Dupras, Mark Fletcher, James Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback regarding the vCard/xCard use in this specification.
We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, Amanda Baber, Dan Banks, Andrew Newton, Philip Reichl, and Francis Dupont for their review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry Leiba deserve special mention for their detailed and extensive review comments, which were very helpful and appreciated.
また、Paul Kyzivat、Gunnar Hellstrom、Martin Thomson、Keith Drage、Laura Liess、Chris Santer、Barbara Stark、Chris Santer、Archie Cobbs、Magnus Nystrom、Stephen Farrell、Amanda Baber、Dan Banks、Andrew Newton、Philip Reichlにも感謝します。 、フランシス・デュポンのレビューコメント。アリッサクーパー、ガイキャロン、ベンキャンベル、バリーレイバは、彼らの詳細で広範なレビューコメントについて特別な言及に値します。
Authors' Addresses
Authors' Addresses
Randall Gellens San Diego, CA 92121 United States
Randall Gellensサンディエゴ、CA 92121アメリカ合衆国
Email: rg+ietf@randy.pensive.org
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 United States
Brian Rosen NeuStar 470 Conrad Dr.Mars、PA 16046アメリカ
Phone: +1 724 382 1051
Email: br@brianrosen.net
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060 Austria
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Roger Marshall TeleCommunication Systems, Inc. 2401 Elliott Avenue Seattle, WA 98121 United States
Roger Marshall TeleCommunication Systems、Inc. 2401 Elliott Avenue Seattle、WA 98121 United States
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
James Winterbottom Winterb Consulting Services Gwynneville, NSW 2500 Australia
James Winterbottom Winterbコンサルティングサービスグウィンビル、ニューサウスウェールズ州2500オーストラリア
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com