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
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咨询服务公司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.
当紧急呼叫被发送到公共安全应答点（PSAP）时，发起设备、设备所连接的接入网络提供商以及呼叫路径中的所有服务提供商都有关于呼叫、呼叫者或位置的信息，这有助于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.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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
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的紧急呼叫时，来自多个数据源的丰富数据集被传送到公共安全应答点（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]所述，本文件扩展了与基于会话启动协议（SIP）的紧急呼叫通信的基本数据集，以便携带对处理呼叫的实体或呼叫接受者有用的附加数据。该数据是所用紧急呼叫信号中基本信息的“附加”数据。目的是使用此处描述的机制，每次紧急呼叫都尽可能多地携带此处描述的信息。
This document defines three categories of this additional data that can be transmitted with an emergency call:
本文件定义了可通过紧急呼叫传输的三类附加数据：
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.
与位置相关联的数据：主要位置数据在存在信息数据格式位置对象（PIDF-LO）数据结构中传输，如RFC 4119[RFC4119]中定义，并通过RFC 5139[RFC5139]和RFC 6848[RFC6848]（用于城市位置信息）、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消息体）中携带，但进行呼叫的设备、设备连接到的接入网络以及沿着呼叫路径的服务提供商知道其他数据。这些信息包括服务提供商联系信息、用户身份和联系信息、服务提供商和接入网络提供的服务类型、正在使用的设备类型等。一些数据广泛适用，而其他数据取决于设备或服务的类型。例如，医疗监测设备可能具有传感器数据。本文档中定义的数据结构（数据提供商信息、设备信息和所有者/订户信息）均属于“与呼叫相关的数据”类别。请注意，所有者/订阅者信息包括订阅者的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节定义了数据结构，第6节定义了传输机制（使用SIP和HTTPS）。
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结构，具有关联的多用途Internet邮件扩展（MIME）媒体类型，用于在传输（如SIP和HTTPS）中进行标识。块集是可扩展的。注册被定义为识别可使用的块类型，并允许在紧急呼叫信令中包括块。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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,
本文件还使用了[RFC5012]中的术语。我们使用术语“服务提供商”来指代应用程序服务提供商（ASP）。语音服务提供商（VSP）是一种特殊类型的ASP。术语“接入网络提供商”指的是互联网接入提供商（IAP）和互联网服务提供商（ISP），无需进一步区分这两个实体，因为两者之间的差异与本文件无关。请注意，ASP和access网络提供商的角色可能由单个公司提供。应急服务提供商是直接参与提供应急服务的实体。这包括PSAP，
dispatch, police, fire, emergency medical, other responders, and other similar agencies.
调度、警察、消防、紧急医疗、其他响应人员和其他类似机构。
Within each data block definition (see Section 4), the values for the 'Use:' label are specified as one of the following:
在每个数据块定义中（参见第4节），“Use:”标签的值指定为以下值之一：
'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:
本节定义了以下五种数据结构，每种结构都作为一个数据块。对于每个块，我们定义MIME媒体类型和XML编码。这五种数据结构是：
'Data Provider': This block supplies name and contact information for the entity that created the data. Section 4.1 provides the details.
“数据提供程序”：此块提供创建数据的实体的名称和联系信息。第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.
“所有者/订阅者”：此块提供有关设备所有者或订阅者的信息。详情见第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>元素的目的是将同一数据提供程序添加的所有块关联为一个单元。元素将数据提供程序块与作为一个单元添加的每个其他块相关联。因此，当数据提供程序向紧急呼叫添加额外数据（如设备信息）时，它必须添加关于自身的信息（通过数据提供程序块），并且添加的块在<DataProviderReference>元素中包含相同的值。由单个实体同时添加的所有块必须具有相同的<DataProviderReference>值。（在某些情况下，同一提供程序可能会多次处理调用，可能以不同的角色处理，在这种情况下，每次处理调用时，它都会添加一组新的块，其中包含一个新的<DataProviderReference>值。）<DataProviderReference>元素的值具有相同的语法和属性（特别是世界唯一性）作为RFC 5322[RFC5322]中指定的“消息ID”消息正文标题字段的值，但<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节中三个类别的描述进行分类。有关添加新数据块或数据类型时的其他注意事项，请参见第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
请注意，xCard格式在某些数据结构中被重用，以提供联系信息。在xCard中，无法指定“主要”电话号码（即主要或主要联系人号码，通常是企业的，而不是个人的直接拨号号码）。这些数字对呼叫大型企业的应急响应人员非常有用。此文档将一个名为“main number”的新参数值添加到的“TYPE”参数中
the 'tel' property. It can be used in any xCard in an emergency call additional data block.
“电话”属性。它可以用于紧急呼叫附加数据块中的任何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.
此块旨在由呼叫路径中的任何服务提供商、或接入网络提供商和设备提供。它包括身份和联系信息。该区块必须由提供任何其他区块的任何实体提供；它应该由呼叫路径中的每个服务提供商提供，如果这些实体不添加任何其他块，则应由接入网络提供商提供。设备应使用此块提供识别信息。MIME媒体类型为“application/EmergencyCallData.ProviderInfo+xml”。接入网络提供商应在PIDF-LO的<provided by>元素中通过值或引用提供此块。
Data Element: Data Provider String
数据元素：数据提供程序字符串
Use: Conditional. Optional for blocks supplied by the originating device; mandatory otherwise.
用法：有条件。由始发设备提供的块可选；除非另有规定。
XML Element: <DataProviderString>
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中联系人标头字段的值。
Reason for Need: Inform the call taker of the identity of the entity providing the data.
需要理由：通知电话接线员提供数据的实体的身份。
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>
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').
描述：创建结构的<DataProviderBy>元素中显示的接入网络提供商或服务提供商的特定于辖区的代码或完全限定的域名。注：该值应由适用于辖区的组织分配。在美国，如果供应商在NENA注册，供应商的NENA公司ID必须出现在此处。更多信息可在国家应急号码协会（NENA）公司识别码计划中找到<http://www.nena.org/?page=cid2014>或者NENA公司ID<http://www.nena.org/?page=CompanyID>. NENA公司ID必须采用以下格式的URI格式：urn:NENA:companyid:<NENA Company ID>。如果组织没有向特定管辖区的应急服务注册机构（如NENA）注册的标识符，则该值可能是服务提供商或接入提供商的完全限定域名。设备可以使用其IP地址或完全限定的域名（并将“Data Provider ID Series”元素设置为“domain”）。
Reason for Need: Inform the call taker of the identity of the entity providing the data.
需要理由：通知电话接线员提供数据的实体的身份。
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.
呼叫接受者如何使用：如果辖区有提供者列表，则数据提供者ID提供有关数据源的有用信息。数据提供程序ID唯一标识数据源，特别是在异常情况下和常规日志记录时可能需要该数据源。
Data Element: Data Provider ID Series
数据元素：数据提供程序ID系列
Use: Conditional. Optional for blocks supplied by the originating device; mandatory otherwise.
用法：有条件。由始发设备提供的块可选；除非另有规定。
XML Element: <ProviderIDSeries>
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节中创建的“ProviderID Series”注册表最初包含图1所示的条目。
Reason for Need: Identifies how to interpret the Data Provider ID. The combination of ProviderIDSeries and ProviderID MUST be globally unique.
需要原因：标识如何解释数据提供程序ID。ProviderID和ProviderID的组合必须全局唯一。
How Used by Call Taker: Determines which provider ID registry to consult for more information.
呼叫接受者如何使用：确定要咨询哪个提供者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) | |
+-----------+--------------------------+----------------------+
+-----------+--------------------------+----------------------+
| 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>
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.
接线员如何使用：当需要更多信息时，这些信息在决定联系谁时会很有帮助。
+------------------------------+------------------------------------+
| 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 |
+------------------------------+------------------------------------+
+------------------------------+------------------------------------+
| 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>
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
描述：当由服务提供商或接入网络提供商提供时，该信息应为24/7支持组织的URI，该组织负责为该紧急呼叫提供PSAP支持。由设备提供时，必须是设备用户或所有者的联系信息。（理想情况下，这是设备用户的联系信息，但当
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]).
所有者和用户是分开的（例如，设备所有者是一个组织），这可能是所有者的联系信息。）数据提供商联系URI应该是e.164格式的电话URI[RFC3966]，并用国家代码完全指定。如果tel URI不可用，则可以接受通用SIP URI。请注意，PSAP不会将此联系信息用于回调（来自与最近终止的紧急呼叫直接相关的PSAP的呼叫，由PSAP使用设置为“PSAP回调”的SIP优先级标头字段进行拨打，如[RFC7090]中所述）。
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>
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>
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>元素，但只应提供一个<vcard>元素。如果出现多个，则应使用第一个。xCard中有许多字段，鼓励数据结构的创建者提供所有可用信息。N、 至少建议使用组织、ADR、电话和电子邮件。N应包含支持组或设备所有者的名称（视情况而定）。如果提供了多个TEL属性，则应为每个TEL指定“vCard属性值”注册表中的参数。对于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>
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.
描述：一些供应商将其处理紧急服务方面的义务外包给专业供应商。如果数据提供者是另一提供者的分包商，则此元素包含服务提供者的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>
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”。如果应首先联系分包商工作的提供商，则此元素的值必须为“main”。
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.
呼叫接受者如何使用：如果需要帮助，决定首先联系哪个实体。
<?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">
<?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>
<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>
<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>
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.
描述：此元素指示呼叫是来自企业还是来自住宅。目前，唯一有效的条目是“Business”、“Residence”和“Unknown”，如图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.
接线员如何使用：信息可用于提供上下文和提示，以帮助确定应急响应人员的设备和人力需求。这是非权威性的；有些情况下，服务提供商不知道服务的类型（例如，匿名预付费服务）。服务类型不一定反映房屋的性质（例如，安装在住宅或移动电话服务中的业务线）。注册表不包含所有情况下的所有可能值。因此，这充其量只是咨询信息，但由于它模仿了一些当前紧急呼叫系统中的类似功能（例如，与传统北美有线系统一起使用的自动位置信息（ALI）中的一个字段），因此它对PSAP是有价值的。服务提供商使用其最佳信息（例如费率计划、用于提供服务的设施或服务描述）来确定信息，并且不负责确定呼叫发起地的实际特征。由于蜂窝网络的用途未知（且不太清楚），因此该元素对于商业移动无线电服务（如蜂窝网络）是可选的，否则需要。
+-----------+--------------------------+
| Token | Description |
+-----------+--------------------------+
| Business | Business service |
| | |
| Residence | Residential service |
| | |
| Unknown | Type of service unknown |
| | (e.g., anonymous pre- |
| | paid service) |
+-----------+--------------------------+
+-----------+--------------------------+
| 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>
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) |
| | |
+--------------+------------------------------------------+
| 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. |
+--------------+------------------------------------------+
| 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>
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.
呼叫接受者如何使用：确定是否假设呼叫者的位置可能会改变。
+-----------+----------------------------+
| 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 |
+-----------+----------------------------+
+-----------+----------------------------+
| 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>
<?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>
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.
描述：此数据元素定义了发出紧急呼叫的设备类型。如果设备提供数据结构，则应提供设备信息。如果服务提供商提供了结构，并且知道设备是什么，则服务提供商应提供设备信息。运营商通常不知道该设备是什么。可以接收两个设备信息块：一个由设备提供，另一个来自服务提供商。此信息描述的是设备，而不是设备的使用方式。该数据元素定义了发出紧急呼叫的设备类型。第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 |
+---------------+----------------------------------------+
+---------------+----------------------------------------+
| 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>
XML Element: <DeviceMfgr>
Description: The plain language name of the manufacturer of the device.
描述：设备制造商的普通语言名称。
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>
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 Element: <UniqueDeviceID>
XML Attribute: <TypeOfDeviceID>
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>
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 |
+--------+------------------------------------------+
+--------+------------------------------------------+
| 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>
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
描述：表示其架构特定于创建它的设备或服务的附加数据的URI。（例如，医疗设备或医疗设备监控服务可能有一组已定义的医疗数据。）解除引用时，URI必须生成由特定设备/服务定义的数据结构
additional data type value. Different data can be created by each classification, e.g., a data set created by a medical device.
附加数据类型值。每个分类可以创建不同的数据，例如，医疗设备创建的数据集。
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>
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所示的初始值目前仅包括IEEE 1512，这是美国交通部（USDoT）交通事故模型。
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) | |
+---------+---------------------------+--------------------------+
+---------+---------------------------+--------------------------+
| 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>
<?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.
呼叫接受者如何使用：如果显示隐私，呼叫接受者可能无法访问订户信息的某些方面。
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>
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>属性，则必须在每个<tel>上指定“vCard property Values”注册表中的参数。虽然某些数据（如<周年>）似乎与应急服务无关，但在某些紧急情况下，任何数据都可能有用。
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.
呼叫接受者如何使用：在无法获得呼叫方的关键信息时，获取有关呼叫方的关键信息，可能还有位置信息。虽然此处的位置不一定是呼叫者的位置，但在某些情况下，当其他方法失败时，它有助于定位呼叫者。
<?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>
<?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>
<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>
<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>
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.
接线员如何使用：解释提供的数据。
<?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>
<?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.
本文档描述了允许扩展紧急呼叫提供的数据类型的两种机制：定义新块或为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.
实现者应该考虑，在某些情况下，基于传感器的设备的数据可能对调用者或PSAPs（以及隐私、责任或其他考虑可能排除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:
对于具有特定于设备或服务的数据的设备，有两种选择可以携带该数据。可以定义新块，或者可以使用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].
本节定义了如何向应急服务提供商传达附加数据。指定了两种不同的方式：第一种使用呼叫信令；第二个使用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头字段中嵌入统一资源标识符（URI）的能力，即调用信息头字段。URI指向附加的数据结构。[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
本文档为Call Info“purpose”参数添加了一个新的复合令牌，该令牌以值“EmergencyCallData”开头。如果'purpose'参数设置为以'EmergencyCallData'开头的值，则Call Info标头字段包含指向外部资源或内容的HTTPS URL
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.
间接寻址（CID）URI，允许将数据结构放置在SIP消息体中。“purpose”参数还指示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数据结构。（由其他人定义的块可以用XML编码，也可以不用XML编码，这取决于它们的MIME注册。）通常，每当消息体中包含多个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指向主体中的一个块。在一个Call Info header字段（或多个Call Info header字段）中使用多个URI来指向多个块。当通过引用提供附加数据时（在SIP信令或PIDF-LO的<provided by>元素中），每个HTTPS URL引用一个块；使用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
除了呼叫路径中的服务提供商之外，接入网络提供商通常具有对PSAP有价值的类似信息。当接入网络提供商和服务提供商是单独的实体时，接入网络不参与应用层信令（因此不能将呼叫信息报头字段添加到SIP消息），但可以在PIDF-LO中提供位置信息。当接入网络提供商通过位置配置以PIDF-LO的形式从位置服务器提供位置信息时
protocol, it has the ability to add the data structures defined in this document (or references to them) within the 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]).
这些数据结构中的数据并非特定于位置本身，而是提供与提供商提供位置的直接情况有关的描述性信息（例如，接入网络提供商的身份、如何联系该实体、接入网络提供何种服务、订户信息等）。此数据几乎在所有方面都与服务提供商在呼叫路径中已知的数据相似。PIDF-LO的<provided by>元素是接入网络提供商提供信息的机制。本文档根据[RFC4119]描述了命名空间用于包含在PIDF-LO的<provided by>元素中，以添加接入网络提供商已知的信息。接入网络提供商应在其返回的PIDF-LO的<provided by>元素中提供额外数据以供紧急使用（例如，如果请求使用HTTP启用的位置传递（保留）“emergencyRouting”或“emergencyDispatch”的“responseTime”属性[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节所定义，在“紧急呼叫附加数据”注册表中注册的一个或多个数据块可包括在SIP信令（使用呼叫信息报头字段）或PIDF-LO的<provided by>元素中或引用。为了实现互操作性，仅允许使用本文档中指定的机制发送注册表中的块。由于期望多个实体提供数据集，因此数据本身需要描述源的信息。因此，每个添加额外数据的实体必须提供一个“数据提供者”块。所有其他块都是可选的，但每个实体都应提供其在块中至少包含部分信息的所有块。
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”开头的“purpose”值、点（“.”）和URI处可用数据类型的Call Info标头字段，将块的URI插入任何SIP请求或响应方法（通常为INVITE或MESSAGE）。数据类型通过包含MIME媒体子类型的根（不重复“EmergencyCallData”前缀）来表示，省略任何后缀，如“+xml”。例如，当引用MIME媒体类型为“application/EmergencyCallData.ProviderInfo+xml”的块时，“purpose”参数设置为“EmergencyCallData.ProviderInfo”。这方面的呼叫信息标题字段示例如下：
Call-Info: https://www.example.com/23sedde3;
purpose="EmergencyCallData.ProviderInfo"
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消息的请求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).
数据也可以通过允许包含正文（即，不是BYE请求）的任何SIP请求或响应方法中的值提供[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
可以预期有多个Call Info标头字段的“purpose”值以“EmergencyCallData”开头，但必须至少提供一个。设备必须提供一个，除非它知道服务提供商在呼叫路径中。如果设备使用服务提供商，则可以插入一个。每个服务提供者在
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。
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指向正文中的数据块（具有匹配的内容ID正文部分标头字段）。当在签名或加密的主体部分中携带数据块时，封装的多部分（例如，“multipart/signed”或“multipart/encrypted”）与数据部分具有相同的内容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>元素有两个属性：“ref”用于指定URL，“purpose”用于指示引用的数据块的类型。“ref”的值是一个HTTPS URL，解析为包含调用信息的数据结构。“目的”的值与呼叫信息标题字段中使用的值相同（如第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"/>
<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>元素传输一个数据块；使用多个<EmergencyCallDataReference>元素传输多个数据块。多个<EmergencyCallDataReference>元素可以作为子元素包含在<Providered by>元素中。
The following is a simplified example:
以下是一个简化示例：
<provided-by>
<EmergencyCallDataReference
purpose="EmergencyCallData.ServiceInfo"
ref="https://example.com/ref2" />
<provided-by>
<EmergencyCallDataReference
purpose="EmergencyCallData.ServiceInfo"
ref="https://example.com/ref2" />
<EmergencyCallDataReference
purpose="EmergencyCallData.ProviderInfo"
ref="https://example.com/ref3" />
<EmergencyCallDataReference
purpose="EmergencyCallData.ProviderInfo"
ref="https://example.com/ref3" />
<EmergencyCallDataReference
purpose="EmergencyCallData.Comment"
ref="https://example.com/ref4" />
</provided-by>
<EmergencyCallDataReference
purpose="EmergencyCallData.Comment"
ref="https://example.com/ref4" />
</provided-by>
Example <provided-by> by Reference
示例<由>提供>参考
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显示了一个PIDF-LO示例，其中一个<EmergencyCallDataReference>元素指向一个EmergencyCallData.ServiceInfo数据块，URL位于'ref'属性中，而'purpose'属性设置为'EmergencyCallData.ServiceInfo'。
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 LOs可由客户端或其他实体获取并存储在本地，因此按值提供数据可能会将私人信息暴露给更多的受众。
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>元素内按值传输一个或多个附加数据块。正在传输的每个块（作为子元素）都放置在<EmergencyCallDataValue>元素中。（与相应MIME媒体类型主体部分中包含的XML结构相同的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.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>
<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>
</EmergencyCallDataValue>
</provided-by>
</provided-by>
Example <provided-by> by Value
示例<由>提供>按值
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显示了一个PIDF-LO示例，该示例包含一个<provided by>元素，其中<EmergencyCallData.ProviderInfo>和<EmergencyCallData.Comment>元素作为<EmergencyCallDataValue>元素的子元素。
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)
RFC 5621[RFC5621]讨论了SIP中消息体的处理。它根据实施经验更新并澄清了RFC 3261[RFC3261]中最初定义的处理。虽然RFC3261没有强制要求支持“多部分”消息体，但许多扩展（包括本文档）都使用“多部分/混合”MIME体
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.
今天例如，在SIP消息体中添加PIDF-LO、会话描述协议（SDP）和其他数据需要“多部分”消息体。
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]定义内容处置标头字段的“处理”参数。这些RFC描述了当用户代理服务器（UAS）接收到其不了解其内容类型或处置类型的消息正文时，该服务器如何作出反应。如果“handling”参数的值为“optional”，UAS将忽略消息正文。如果“handling”参数的值为“required”，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消息指示SIP消息主体中的“Content Disposition”参数，如图14所示。
Content-Type: application/sdp
...Omit Content-Disposition here; defaults are ok
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
--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
--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--
--边界1--
Figure 14: Example for Use of the Content-Disposition Parameter in SIP
图14:SIP中内容配置参数的使用示例
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
[==============]
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
--- 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: ...
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
--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
--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
<?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>
</dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo>
--boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
--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
<?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>
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--
<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
在此示例中，接入网络提供商可用的信息仅通过使用位置参考间接地包括在呼叫设置消息中。PSAP必须通过单独的查找步骤检索它。由于接入网提供商和VoIP服务
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).
在这种情况下，提供商是两个独立的实体，接入网提供商不参与应用层交换；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所示。SIP INVITE在步骤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: ...
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
--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
--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>
<?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
--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>
<?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>
<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>
</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
--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>
<?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
--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>
<?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>
<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--
</vcard>
</pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1--
Figure 17: VoIP Provider Sending SIP INVITE with Additional Data
图17:VoIP提供商发送带有附加数据的SIP INVITE
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>
<?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">
<gp:provided-by
xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
<EmergencyCallDataReference
purpose="EmergencyCallData.ServiceInfo"
ref="https://example.com/ref2" />
<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>
<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>
<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>
</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>
</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.
本节定义了五个数据块的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">
<?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="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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation="vcard.xsd"/>
<xs:element
name="EmergencyCallData.ProviderInfo"
type="pi:ProviderInfoType"/>
<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: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: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="DataProviderString"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="ProviderID"
type="xs:string" minOccurs="0" 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="ProviderIDSeries"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="TypeOfProvider"
type="xs:token" minOccurs="1" 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="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="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="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="SubcontractorPrincipal"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="SubcontractorPriority"
type="pi:SubcontractorPriorityType"
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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</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">
<?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: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: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: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="ServiceEnvironment"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ServiceType"
type="xs:string" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="ServiceType"
type="xs:string" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="ServiceMobility"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</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">
<?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: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: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: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="DeviceClassification"
type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceMfgr"
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="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="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="DeviceSpecificData"
type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceSpecificType"
type="xs:string" 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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</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">
<?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="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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation="vcard.xsd"/>
<xs:element name="EmergencyCallData.SubscriberInfo"
type="sub:SubscriberInfoType"/>
<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: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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="privacyRequested"
type="xs:boolean" use="required"/>
</xs:sequence>
<xs:attribute name="privacyRequested"
type="xs:boolean" use="required"/>
</xs:complexType>
</xs:schema>
</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">
<?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: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: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: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: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: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:complexType name="CommentSubType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
</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">
<?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: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>
<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.
本文档中描述的数据结构包含通常被认为是私有的信息。当信息由value提供时，作为SIP信令一方的实体（如代理服务器和背对背用户代理）将有权访问该信息，并且需要保护该信息不被不当披露。能够窃听SIP信令的实体也将具有访问权限。某些互联网接入类型（如清晰的Wi-Fi）比其他类型（如3G或4G蜂窝数据流量）更容易受到窃听。在可行的情况下，应优先使用防止窃听的机制（如TLS 1.2版或更高版本）。（这一要求不是“必须”的，因为现有的明文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版或更高版本。建议仅使用提供完美前向保密（PFS）和避免密码块链接（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）公钥。一些国家正在为此和相关目的开发公钥基础设施。由于呼叫可以从设备和/或服务提供商不是应急服务机构本地的设备上进行，因此全球认可的凭据非常有用。这可以通过扩展[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或响应者所接受，这些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).
此文档支持向被叫方传递有关呼叫者、呼叫者的设备和服务的附加信息的功能。其中一些信息是个人数据，因此会引起隐私问题。定义了与呼叫方身份直接相关的信息的明确隐私指示器，并强制使用。但是，是否遵守此隐私请求以及与之相关的信息由目的地管辖区决定（该管辖区复制了某些传统应急服务系统中提供的功能）。
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系统中可用的信息共享量。出于这个原因，还有额外的隐私威胁要考虑，这在[RCF693]中有更详细的描述。
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
在呼叫者可以选择禁止某些个人识别信息的地区，网络或PSAP功能可以检查SIP头中的隐私标志，以确定可以传递、存储或显示哪些信息以符合当地政策或法律。RFC 3325[RFC3325]定义“id”priv value令牌。隐私标头字段中存在此隐私类型表示
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.
用户希望网络断言的身份对于用户进行身份验证的信任域之外的SIP实体（包括PSAP）保持私有。
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等组织发布的ID，因此允许他们使用其域名，但如果是，则需要是唯一的。）
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.
本文档创建了一个名为“服务移动性”的新子注册表。根据[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.
描述：服务提供商类型的简短描述。
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.
本文档创建了一个名为“设备分类”的新子注册表。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应该考虑所提出的类是否从现有类中唯一，并且类的定义对于实现者和PSAP/应答者是清楚的。
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
本文档创建了一个名为“设备ID类型”的新子注册表。根据[RFC5226]中的定义，该登记处按照“专家审查”规则运作。专家应确定建议的类型已被充分理解，并提供PSAP和响应者能够用于唯一识别设备的信息。（例如，生物特征识别
fingerprint used to authenticate a device would not normally be used by a PSAP or responder to identify a device.)
用于验证设备的指纹通常不会被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.
描述：识别数据的简短描述。
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.
本文档创建了一个名为“紧急呼叫数据类型”的新子注册表。如[RFC5226]中所定义，该注册中心按照“规范要求”规则运行，其中包括明确的“专家评审”。专家负责验证文档是否包含完整、清晰的规范，并且建议的功能不会明显重复现有功能。专家还负责验证是否根据第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
注册表包含每个数据块的条目，这些数据块可以使用本文档中指定的机制通过紧急调用发送。每个数据块由其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.
媒体子类型（“EmergencyCallData.”之后的部分）。如果MIME媒体子类型不是以“EmergencyCallData”开头，则不能在此处注册，也不能在此文档中指定的调用信息标头字段中使用。该子类型可以存在于任何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').
标记：数据的MIME媒体子类型的根（不包括'EmergencyCallData'前缀和任何后缀，如'+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.
关于数据：关于块是否被视为描述调用、调用方或位置（或适用于多个位置）的提示，可帮助PSAP和其他实体确定是否希望处理该块。请注意，这只是一个提示；在确定是否希望处理块时，实体需要考虑块的内容，而不仅仅是该字段（这就是字段仅存在于注册表中而不包含在块中的原因）。该值必须为“调用”、“调用方”、“位置”或“多个”。通过在后续RFC中扩展此注册表来创建新值。
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.
请注意，此注册表中的令牌是“EmergencyCallData”复合值的一部分；当用作Call Info标头字段的'purpose'参数值时，此注册表中列出的值以'EmergencyCallData'作为前缀。根据'EmergencyCallData'注册；见第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 |
+----------------+--------------+------------+
+----------------+--------------+------------+
| 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已将本文件添加到“会话启动协议（SIP）参数”注册表“标题字段参数和参数值”子注册表中呼叫信息“目的”值的参考列表中。请注意，“EmergencyCallData”是一个复合值；当用作呼叫信息标头字段的'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.
本节将第11.5.1节中指定的名称空间注册到RFC 4119建立的提供方注册表中，以便在PIDF-LO的<provided by>元素中使用。
The schema for the <provided-by> element used by this document is specified in Section 8.6.
第8.6节规定了本文件使用的<provided by>元素的模式。
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
子类型名称：EmergencyCallData.ProviderInfo+xml
Mandatory parameters: 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].
编码注意事项：使用XML，它可以包含8位字符，具体取决于字符编码。参见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
互操作性注意事项：不适用
Published specification: RFC 7852
已发布规范：RFC 7852
Applications that use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information:
其他信息：
Magic Number: N/A
幻数：不适用
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
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>
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].
本规范要求根据RFC 6838[RFC6838]的程序和RFC 7303[RFC7303]中的指南注册新的MIME媒体类型。
Type name: application
类型名称：应用程序
Subtype name: EmergencyCallData.ServiceInfo+xml
子类型名称：EmergencyCallData.ServiceInfo+xml
Mandatory parameters: 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].
编码注意事项：使用XML，它可以包含8位字符，具体取决于字符编码。参见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
互操作性注意事项：不适用
Published specification: RFC 7852
已发布规范：RFC 7852
Applications that use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information:
其他信息：
Magic Number: N/A
幻数：不适用
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
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>
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
子类型名称：EmergencyCallData.DeviceInfo+xml
Mandatory parameters: 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].
编码注意事项：使用XML，它可以包含8位字符，具体取决于字符编码。参见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
互操作性注意事项：不适用
Published specification: RFC 7852
已发布规范：RFC 7852
Applications that use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information:
其他信息：
Magic Number: N/A
幻数：不适用
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
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>
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)
可选参数：字符集（表示内容的字符编码）
Encoding considerations: Uses XML, which can contain 8-bit characters, depending on the character encoding. See Section 3.2 of RFC 7303 [RFC7303].
编码注意事项：使用XML，它可以包含8位字符，具体取决于字符编码。参见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
互操作性注意事项：不适用
Published specification: RFC 7852
已发布规范：RFC 7852
Applications that use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information:
其他信息：
Magic Number: N/A
幻数：不适用
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
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>
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
强制性参数：不适用
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].
编码注意事项：使用XML，它可以包含8位字符，具体取决于字符编码。参见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
互操作性注意事项：不适用
Published specification: RFC 7852
已发布规范：RFC 7852
Applications that use this media type: Emergency Services
使用此媒体类型的应用程序：紧急服务
Additional information:
其他信息：
Magic Number: N/A
幻数：不适用
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
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>
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
URI: urn:ietf:params:xml:ns:EmergencyCallData
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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
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
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
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>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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
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
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
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>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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>
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
<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
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
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>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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
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
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
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>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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
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
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
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>.
注册人联系人：IETF、ECRIT工作组、<ecrit@ietf.org>，由IESG授权<iesg@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
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注册人联系人：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注册人联系人：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
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.，“内容ID和消息ID统一资源定位器”，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：会话启动协议”，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]Burger，E.“关键内容多用途Internet邮件扩展（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.，“IETF XML注册表”，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.，“电话号码的电话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.，“基于状态的GeoDriv定位对象格式”，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，“在RFCs中编写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.，Ed.，“互联网信息格式”，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]Camarillo，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]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标签”，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格式规范”，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媒体类型”，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勘误表，勘误表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.，“在实时通信中协商人类语言”，正在进行的工作，草稿-ietf-slim-CONTATING-HUMAN-Language-042016年7月。
[IANA-XML-Schemas] IANA, "IETF XML Registry", <http://www.iana.org/assignments/xml-registry>.
[IANA XML模式]IANA，“IETF XML注册表”<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标准1512-2006，DOI 10.1109/IEEESTD.2006.224678，2006年8月<https://standards.ieee.org/findstds/ 标准/1512-2006.html>。
[LanguageSubtagRegistry] IANA, "Language Subtag Registry", <http://www.iana.org/assignments/ language-subtag-registry>.
[LanguageSubtagRegistry]IANA，“语言Subtag注册表”<http://www.iana.org/assignments/ 语言子标记注册表>。
[LERG] Telcordia Technologies, Inc., "LERG Routing Guide", ANI II Digits Definitions, June 2015.
[LERG]Telcordia Technologies，Inc.，“LERG路由指南”，ANI II数字定义，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数字分配”，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]国家应急号码协会（NENA），“9-1-1数据交换和GIS制图的NENA标准数据格式”，NENA-02-010，版本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.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<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.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<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，Ed.，“利用互联网技术解决紧急情况的要求”，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，“状态信息数据格式位置对象（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存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，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.，“位置到URL映射架构和框架”，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，“状态信息数据格式位置对象（PIDF-LO）的动态扩展”，RFC 5962，DOI 10.17487/RFC5962，2010年9月<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]巴恩斯，M.，编辑，“支持HTTP的位置传递（保留）”，RFC 5985，DOI 10.17487/RFC59852010年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]温特巴顿，J.，汤姆森，M.，巴恩斯，R.，罗森，B.，和R.乔治，“在状态信息数据格式位置对象（PIDF-LO）中指定公民地址扩展”，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]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，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，“相对位置表示”，RFC 7035，DOI 10.17487/RFC70352013年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，“公共安全应答点（PSAP）回调”，RFC 7090，DOI 10.17487/RFC70902014年4月<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，“安全使用传输层安全性（TLS）和数据报传输层安全性（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模式。除了将RELAXNG模式映射到XML模式之外，本规范还应用了为RFC 6351提出的关于类型定义的勘误表；参见RFC勘误表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"/>
<?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: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: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: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: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 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: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: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: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: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: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>
</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: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: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: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: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: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: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: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: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"
</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>
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>
</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 RFCs引入的格式限制。对于那些直接从该文档中复制XML模式和示例的读者，请考虑在附录A中包含的VCART模式中的正则表达式中使用断线和额外的空白来引入错误，以验证图18中的PIDF-LO，还需要参考参考的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模式]上找到，XML示例可在IETF ECRIT工作组wiki页面[ECRIT WG wiki]上找到。
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.
这项工作最初从NENA开始，并得益于NENA标准化工作的大量参与者，最初是长期定义工作组、数据技术委员会，最近是额外数据工作组。作者感谢许多NENA参与者提供的初始工作和扩展评论，包括Delaine Arnold、Marc Berryman、Guy Caron、Brian Dupras、Mark Fletcher、James Leyerle、Kathy McMahon、Christian Militeau、Ira Pyles、Matt Serra和Robert（Bob）Sherry。Amursana Khiyod、Robert Sherry、Frank Rahoi、Scott Ross和Tom Klepetka提供了关于本规范中vCard/xCard使用的宝贵反馈。
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和Francis Dupont的评论。Alissa Cooper、Guy Caron、Ben Campbell和Barry Leiba的详细和广泛的评论值得特别提及，这些评论非常有帮助，值得赞赏。
Authors' Addresses
作者地址
Randall Gellens San Diego, CA 92121 United States
美国加利福尼亚州圣地亚哥Randall Gellens 92121
Email: rg+ietf@randy.pensive.org
Email: rg+ietf@randy.pensive.org
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 United States
布莱恩·罗森·纽斯塔470康拉德·马尔斯博士，宾夕法尼亚州，美国16046
Phone: +1 724 382 1051
Email: br@brianrosen.net
Phone: +1 724 382 1051
Email: br@brianrosen.net
Hannes Tschofenig Hall in Tirol 6060 Austria
奥地利蒂罗尔的汉内斯·茨霍芬尼大厅6060
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Roger Marshall TeleCommunication Systems, Inc. 2401 Elliott Avenue Seattle, WA 98121 United States
美国华盛顿州西雅图艾略特大道2401号罗杰·马歇尔电信系统公司，邮编：98121
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
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
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com