draft-ietf-ecrit-additional-data-37.txt   draft-ietf-ecrit-additional-data-38.txt 
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft
Updates: 6443, 6881 (if approved) B. Rosen Updates: 6443, 6881 (if approved) B. Rosen
Intended status: Standards Track NeuStar Intended status: Standards Track NeuStar
Expires: April 14, 2016 H. Tschofenig Expires: October 7, 2016 H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
April 5, 2016
October 12, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-37.txt draft-ietf-ecrit-additional-data-38.txt
Abstract Abstract
When an emergency call is sent to a Public Safety Answering Point When an emergency call is sent to a Public Safety Answering Point
(PSAP), the originating device, the access network provider to which (PSAP), the originating device, the access network provider to which
the device is connected, and all service providers in the path of the the device is connected, and all service providers in the path of the
call have information about the call, the caller or the location call have information about the call, the caller or the location
which is helpful for the PSAP to have in handling the emergency. which is helpful for the PSAP to have in handling the emergency.
This document describes data structures and mechanisms to convey such This document describes data structures and mechanisms to convey such
data to the PSAP. The intent is that every emergency call carry as data to the PSAP. The intent is that every emergency call carry as
skipping to change at page 2, line 6 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 7, 2016.
This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 35 skipping to change at page 3, line 33
8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53 8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 53 8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 53
8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 55 8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 55
8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 56 8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 56
8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 58 8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 58
8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 59 8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 59
8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 60 8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 60
9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 62
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
11.1. Registry creation . . . . . . . . . . . . . . . . . . . 67 11.1. Emergency Call Additional Data Registry . . . . . . . . 67
11.1.1. Provider ID Series Registry . . . . . . . . . . . . 67 11.1.1. Provider ID Series Registry . . . . . . . . . . . . 67
11.1.2. Service Environment Registry . . . . . . . . . . . . 68 11.1.2. Service Environment Registry . . . . . . . . . . . . 68
11.1.3. Service Type Registry . . . . . . . . . . . . . . . 68 11.1.3. Service Type Registry . . . . . . . . . . . . . . . 68
11.1.4. Service Mobility Registry . . . . . . . . . . . . . 68 11.1.4. Service Mobility Registry . . . . . . . . . . . . . 69
11.1.5. Service Provider Type Registry . . . . . . . . . . . 69 11.1.5. Type of Provider Registry . . . . . . . . . . . . . 69
11.1.6. Device Classification Registry . . . . . . . . . . . 69 11.1.6. Device Classification Registry . . . . . . . . . . . 69
11.1.7. Device ID Type Type Registry . . . . . . . . . . . . 70 11.1.7. Device ID Type Registry . . . . . . . . . . . . . . 70
11.1.8. Device/Service Data Type Registry . . . . . . . . . 70 11.1.8. Device/Service Data Type Registry . . . . . . . . . 70
11.1.9. Emergency Call Data Types Registry . . . . . . . . . 70 11.1.9. Emergency Call Data Types Registry . . . . . . . . . 70
11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 72 11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 72
11.3. URN Sub-Namespace Registration for <provided-by> 11.3. URN Sub-Namespace Registration for <provided-by>
Registry Entry . . . . . . . . . . . . . . . . . . . . . 72 Registry Entry . . . . . . . . . . . . . . . . . . . . . 72
11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72 11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72
11.4.1. MIME Content-type Registration for 11.4.1. MIME Content-type Registration for
'application/EmergencyCallData.ProviderInfo+xml' . . 72 'application/EmergencyCallData.ProviderInfo+xml' . . 72
11.4.2. MIME Content-type Registration for 11.4.2. MIME Content-type Registration for
'application/EmergencyCallData.ServiceInfo+xml' . . 73 'application/EmergencyCallData.ServiceInfo+xml' . . 73
skipping to change at page 4, line 28 skipping to change at page 4, line 26
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 79 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 79
11.5.4. Registration for 11.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 80 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 80
11.5.5. Registration for 11.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI
nfo . . . . . . . . . . . . . . . . . . . . . . . . 81 nfo . . . . . . . . . . . . . . . . . . . . . . . . 81
11.5.6. Registration for 11.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 82 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 82
11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 83 11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 83
11.7. VCard Parameter Value Registration . . . . . . . . . . . 84 11.7. VCard Parameter Value Registration . . . . . . . . . . . 84
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.1. Normative References . . . . . . . . . . . . . . . . . . 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 85
13.2. Informational References . . . . . . . . . . . . . . . . 86 13.2. Informational References . . . . . . . . . . . . . . . . 87
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 88 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 89 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 90
Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 111 Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112
1. Introduction 1. Introduction
When an IP-based emergency call is initiated, a rich set of data from When an IP-based emergency call is initiated, a rich set of data from
multiple data sources is conveyed to the Public Safety Answering multiple data sources is conveyed to the Public Safety Answering
Point (PSAP). This data includes information about the calling party Point (PSAP). This data includes information about the calling party
identity, the multimedia capabilities of the device, the request for identity, the multimedia capabilities of the device, the request for
emergency services, location information, and meta-data about the emergency services, location information, and meta-data about the
sources of the data. In addition, the device, the access network sources of the data. In addition, the device, the access network
provider, and any service provider in the call path has even more provider, and any service provider in the call path has even more
skipping to change at page 9, line 11 skipping to change at page 9, line 11
categorized per the description of the three categories in Section 1. categorized per the description of the three categories in Section 1.
See Section 5 and Section 5.1 for additional considerations when See Section 5 and Section 5.1 for additional considerations when
adding new blocks or types of data. adding new blocks or types of data.
Note that the xCard format is re-used in some of the data structures Note that the xCard format is re-used in some of the data structures
to provide contact information. In an xCard there is no way to to provide contact information. In an xCard there is no way to
specify a "main" telephone number (that is, a primary or main contact specify a "main" telephone number (that is, a primary or main contact
number, typically of an enterprise, as opposed to a direct dial number, typically of an enterprise, as opposed to a direct dial
number of an individual). These numbers are useful to emergency number of an individual). These numbers are useful to emergency
responders who are called to a large enterprise. This document adds responders who are called to a large enterprise. This document adds
a new parameter value called "main-number" to the "TYPE" parameter of a new parameter value called 'main-number' to the "TYPE" parameter of
the "tel" property. It can be used in any xCard in an emergency call the "tel" property. It can be used in any xCard in an emergency call
additional data block. additional data block.
4.1. Data Provider Information 4.1. Data Provider Information
This block is intended to be supplied by any service provider in the 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 path of the call, or the access network provider, and the device. It
includes identification and contact information. This block MUST be includes identification and contact information. This block MUST be
supplied by any entity that provides any other block; it SHOULD 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 supplied by every service provider in the call path and by the access
skipping to change at page 12, line 23 skipping to change at page 12, line 23
|Telematics Provider | A sensor-based service provider, | |Telematics Provider | A sensor-based service provider, |
| | especially vehicle-based | | | especially vehicle-based |
|Language Translation Provider | A spoken language translation | |Language Translation Provider | A spoken language translation |
| | service | | | service |
|Emergency Service Provider | An emergency service provider | |Emergency Service Provider | An emergency service provider |
| | conveying information to another| | | conveying information to another|
| | emergency service provider. | | | emergency service provider. |
|Emergency Modality Translation| An emergency-call-specific | |Emergency Modality Translation| An emergency-call-specific |
| | modality translation service | | | modality translation service |
| | e.g., for sign language | | | e.g., for sign language |
|Relay Provider | A interpretation service, e.g., | |Relay Provider | An interpretation service, e.g., |
| | video relay for sign language | | | video relay for sign language |
| | interpreting | | | interpretation |
|Other | Any other type of service provider | |Other | Any other type of service provider |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Figure 2: Type of Data Provider Registry Figure 2: Type of Data Provider Registry
4.1.5. Data Provider Contact URI 4.1.5. Data Provider Contact URI
Data Element: Data Provider Contact URI Data Element: Data Provider Contact URI
Use: Required Use: Required
skipping to change at page 13, line 37 skipping to change at page 13, line 37
content MUST reflect the languages supported at the contact URI. content MUST reflect the languages supported at the contact URI.
(Note that this field informs the PSAP of the language(s) used by (Note that this field informs the PSAP of the language(s) used by
the data provider. If the PSAP needs to contact the data the data provider. If the PSAP needs to contact the data
provider, it can be helpful to know in advance the language(s) provider, it can be helpful to know in advance the language(s)
used by the data provider. If the PSAP uses a communication used by the data provider. If the PSAP uses a communication
protocol to reach the data provider, that protocol might have protocol to reach the data provider, that protocol might have
language facilities of its own (such as the 'language' media language facilities of its own (such as the 'language' media
feature tag, defined in RFC 3840 [RFC3840] and the more extensive feature tag, defined in RFC 3840 [RFC3840] and the more extensive
language negotiation mechanism proposed with language negotiation mechanism proposed with
[I-D.gellens-slim-negotiating-human-language]), and if so, those [I-D.ietf-slim-negotiating-human-language]), and if so, those are
are independent of this field.) independent of this field.)
Reason for Need: This information indicates if the emergency service Reason for Need: This information indicates if the emergency service
authority can directly communicate with the service provider or if authority can directly communicate with the service provider or if
an interpreter will be needed. an interpreter will be needed.
How Used by Call Taker: If the call taker cannot speak any language How Used by Call Taker: If the call taker cannot speak any language
supported by the service provider, a translation service will need supported by the service provider, a translation service will need
to be added to the conversation. Alternatively, other persons at to be added to the conversation. Alternatively, other persons at
the PSAP, besides the call taker, might be consulted for help the PSAP, besides the call taker, might be consulted for help
(depending on the urgency and the type of interaction). (depending on the urgency and the type of interaction).
skipping to change at page 17, line 30 skipping to change at page 17, line 30
</email> </email>
<geo> <geo>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<uri>geo:60.210796,24.812924</uri> <uri>geo:60.210796,24.812924</uri>
</geo> </geo>
<key> <key>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri> <uri>
http://www.tschofenig.priv.at/key.asc http://www.tschofenig.priv.at/key.asc
</uri> </uri>
</key> </key>
<tz><text>Finland/Helsinki</text></tz> <tz><text>Finland/Helsinki</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://www.tschofenig.priv.at</uri> <uri>http://www.tschofenig.priv.at</uri>
</url> </url>
</vcard> </vcard>
</ad:DataProviderContact> </ad:DataProviderContact>
skipping to change at page 20, line 35 skipping to change at page 20, line 35
| attended | monitoring service provider or that | | attended | monitoring service provider or that |
| | are capable of supporting interactive| | | are capable of supporting interactive|
| | media | | | media |
| POTS | Wireline: Plain Old Telephone Service | | POTS | Wireline: Plain Old Telephone Service |
| OTT | An over-the-top service that provides | | OTT | An over-the-top service that provides |
| | communication over arbitrary Internet| | | communication over arbitrary Internet|
| | access (fixed, nomadic, mobile) | | | access (fixed, nomadic, mobile) |
| digital | Wireline non-OTT digital phone service | | digital | Wireline non-OTT digital phone service |
| OPX | Off-premise extension | | OPX | Off-premise extension |
| relay | A service where a human third-party | | relay | A service where a human third-party |
| | agent provides additional assistance | | | agent provides additional assistance.|
| | This includes sign language relay/ | | | This includes sign language relay/ |
| | interpretation, telematics services | | | interpretation, telematics services |
| | that provide a human on the call, | | | that provide a human on the call, |
| | and similar services | | | and similar services |
+--------------+----------------------------------------+ +--------------+----------------------------------------+
Figure 5: Service Delivered by Provider to End User Registry Figure 5: Service Delivered by Provider to End User Registry
The initial set of values has been collected from sources of The initial set of values has been collected from sources of
currently-used systems, including [NENA-02-010], [nc911], [NANP], and currently-used systems, including [NENA-02-010], [nc911], [NANP], and
skipping to change at page 21, line 19 skipping to change at page 21, line 19
network used, the value should be treated as advisory and not be 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 relied upon. A registry is created in Section 11.1.4 with the
initial valid entries shown in Figure 6. initial valid entries shown in Figure 6.
Reason for Need: Knowing the service provider's belief of mobility Reason for Need: Knowing the service provider's belief of mobility
can assist the PSAP with the handling of the call. can assist the PSAP with the handling of the call.
How Used by Call Taker: To determine whether to assume the location How Used by Call Taker: To determine whether to assume the location
of the caller might change. of the caller might change.
+-----------+----------------------------+ +-----------+----------------------------+
| Token | Description | | Token | Description |
+-----------+----------------------------+ +-----------+----------------------------+
| Mobile | The device is able to move | | Mobile | The device is able to move |
| | at any time | | | at any time |
| Fixed | The device is not expected | | Fixed | The device is not expected |
| | to move unless the | | | to move unless the |
| | service is relocated | | | service is relocated |
| Nomadic | The device is not expected | | Nomadic | The device is not expected |
| | to change its point of | | | to change its point of |
| | attachment while on a | | | attachment while on a |
| | call | | | call |
| Unknown | No information is known | | Unknown | No information is known |
| | about the service | | | about the service |
| | mobility environment for | | | mobility environment for |
| | the device | | | the device |
+-----------+----------------------------+ +-----------+----------------------------+
Figure 6: Service Environment Registry Figure 6: Service Mobility Registry
4.2.4. EmergencyCallData.ServiceInfo Example 4.2.4. EmergencyCallData.ServiceInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:EmergencyCallData.ServiceInfo <svc:EmergencyCallData.ServiceInfo
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"> xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo">
<svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org <svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org
</svc:DataProviderReference> </svc:DataProviderReference>
<svc:ServiceEnvironment>Business</svc:ServiceEnvironment> <svc:ServiceEnvironment>Business</svc:ServiceEnvironment>
<svc:ServiceType>MLTS-hosted</svc:ServiceType> <svc:ServiceType>MLTS-hosted</svc:ServiceType>
<svc:ServiceMobility>Fixed</svc:ServiceMobility> <svc:ServiceMobility>Fixed</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo> </svc:EmergencyCallData.ServiceInfo>
Figure 7: EmergencyCallData.ServiceInfo Example. Figure 7: EmergencyCallData.ServiceInfo Example.
4.3. Device Information 4.3. Device Information
This block provides information about the device used to place the This block provides information about the device used to place the
call. It SHOULD be provided by any service provider that knows what 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 device is being used, and by the device itself. The MIME media type
is "application/EmergencyCallData.DeviceInfo+xml". is "application/EmergencyCallData.DeviceInfo+xml".
skipping to change at page 25, line 17 skipping to change at page 25, line 17
current service, it might be possible to determine who last had current service, it might be possible to determine who last had
service. Another example might be a disconnected call where the service. Another example might be a disconnected call where the
call taker believes there is a need for assistance but was not call taker believes there is a need for assistance but was not
able to obtain a location or other information). able to obtain a location or other information).
Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID> Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID>
+--------+------------------------------------------+ +--------+------------------------------------------+
| Token | Description | | Token | Description |
+--------+------------------------------------------+ +--------+------------------------------------------+
| MEID | Mobile Equipment Identifier (CDMA) | | MEID | Mobile Equipment Identifier (CDMA) |
| ESN | Electronic Serial Number (GSM) | | ESN | Electronic Serial Number (GSM) |
| MAC | Media Access Control Address (IEEE) | | MAC | Media Access Control Address (IEEE) |
| WiMAX | Device Certificate Unique ID | | WiMAX | Device Certificate Unique ID |
| IMEI | International Mobile Equipment ID (GSM) | | IMEI | International Mobile Equipment ID (GSM) |
| IMSI | International Mobile Subscriber ID (GSM) | | IMSI | International Mobile Subscriber ID (GSM) |
| UDI | Unique Device Identifier | | UDI | Unique Device Identifier |
| RFID | Radio Frequency Identification | | RFID | Radio Frequency Identification |
| SN | Manufacturer Serial Number | | SN | Manufacturer Serial Number |
+--------+------------------------------------------+ +--------+------------------------------------------+
skipping to change at page 26, line 34 skipping to change at page 26, line 34
externally defined schemas, which might have additional data that externally defined schemas, which might have additional data that
can assist in emergency response. can assist in emergency response.
How Used by Call Taker: This data element allows the end user (call 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 taker or first responder) to know what type of additional data is
available to aid in providing the needed emergency services. available to aid in providing the needed emergency services.
Note: This mechanism is not appropriate for information specific to Note: This mechanism is not appropriate for information specific to
a location or a caller (person). a location or a caller (person).
+----------+----------------------------+--------------------------------+ +----------+----------------------------+--------------------------+
| Token | Description | Specification | | Token | Description | Specification |
+----------+----------------------------+--------------------------------+ +----------+----------------------------+--------------------------+
| IEEE1512 | Common Incident Management |IEEE 1512-2006 | | IEEE1512 | Common Incident Management | IEEE 1512-2006 |
| | Message Set (USDoT model |https://standards.ieee.org/ | | | Message Set (USDoT model | |
| | for traffic incidents) |findstds/standard/1512-2006.html| | | for traffic incidents) | |
+----------+----------------------------+--------------------------------+ +----------+----------------------------+--------------------------+
Figure 10: Device/Service Data Type Registry Figure 10: Device/Service Data Type Registry
The IEEE 1512-2006 specifications can be found at [IEEE-1512-2006].
4.3.7. EmergencyCallData.DeviceInfo Example 4.3.7. EmergencyCallData.DeviceInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo <dev:EmergencyCallData.DeviceInfo
xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference>d4b3072df.201409182208075@example.org <dev:DataProviderReference>d4b3072df.201409182208075@example.org
</dev:DataProviderReference> </dev:DataProviderReference>
<dev:DeviceClassification>fixed</dev:DeviceClassification> <dev:DeviceClassification>fixed</dev:DeviceClassification>
<dev:DeviceMfgr>Nokia</dev:DeviceMfgr> <dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr> <dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
<dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104 <dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104
skipping to change at page 29, line 49 skipping to change at page 29, line 49
<adr> <adr>
<parameters> <parameters>
<type><text>work</text></type> <type><text>work</text></type>
<label><text>Simon Perreault <label><text>Simon Perreault
2875 boul. Laurier, suite D2-630 2875 boul. Laurier, suite D2-630
Quebec, QC, Canada Quebec, QC, Canada
G1V 2M2</text></label> G1V 2M2</text></label>
</parameters> </parameters>
<pobox/> <pobox/>
<ext/> <ext/>
<street>2875 boul. Laurier, suite D2-630</street> <street>2875 boul. Laurier,
suite D2-630</street>
<locality>Quebec</locality> <locality>Quebec</locality>
<region>QC</region> <region>QC</region>
<code>G1V 2M2</code> <code>G1V 2M2</code>
<country>Canada</country> <country>Canada</country>
</adr> </adr>
<tel> <tel>
<parameters> <parameters>
<type> <type>
<text>work</text> <text>work</text>
<text>voice</text> <text>voice</text>
skipping to change at page 31, line 4 skipping to change at page 31, line 5
</email> </email>
<geo> <geo>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<uri>geo:46.766336,-71.28955</uri> <uri>geo:46.766336,-71.28955</uri>
</geo> </geo>
<key> <key>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<uri> <uri>
http://www.viagenie.ca/simon.perreault/simon.asc http://
www.viagenie.ca/simon.perreault/simon.asc
</uri> </uri>
</key> </key>
<tz><text>America/Montreal</text></tz> <tz><text>America/Montreal</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://nomis80.org</uri> <uri>http://nomis80.org</uri>
</url> </url>
</vcard> </vcard>
</sub:SubscriberData> </sub:SubscriberData>
skipping to change at page 35, line 41 skipping to change at page 35, line 41
example, a block (provided by value or by reference) might not be the example, a block (provided by value or by reference) might not be the
type indicated by the "purpose" parameter, or might be badly formed, type indicated by the "purpose" parameter, or might be badly formed,
etc. The general principle that applies to emergency calls is that etc. The general principle that applies to emergency calls is that
it is more important for the call to go through than for everything 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 to be correct. Thus, most PSAPs will process a call if at all
possible, even if data is missing or other failures occur. possible, even if data is missing or other failures occur.
6.1. Transmitting Blocks using Call-Info 6.1. Transmitting Blocks using Call-Info
A URI to a block MAY be inserted in any SIP request or response A URI to a block MAY be inserted in any SIP request or response
method (most often INVITE or MESSAGE) with a Call-Info header field method (most often INVITE or MESSAGE), using a Call-Info header field
containing a purpose value starting with 'EmergencyCallData', a dot containing a purpose value starting with 'EmergencyCallData', a dot
("."), and the type of data available at the URI. The type of data ("."), 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 is denoted by including the root of the MIME media subtype (the
'EmergencyCallData' prefix is not repeated), omitting any suffix such 'EmergencyCallData' prefix is not repeated), omitting any suffix such
as '+xml'). For example, when referencing a block with MIME media as '+xml'). For example, when referencing a block with MIME media
type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose'
parameter is set to 'EmergencyCallData.ProviderInfo'. An example parameter is set to 'EmergencyCallData.ProviderInfo'. An example
"Call-Info" header field for this would be: "Call-Info" header field for this would be:
Call-Info: https://www.example.com/23sedde3; Call-Info: https://www.example.com/23sedde3;
skipping to change at page 37, line 5 skipping to change at page 36, line 49
provider is in the path of the call. The device MAY insert one if it 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 uses a service provider. Each service provider in the path of an
emergency call MUST insert its own. For example, a device, a emergency call MUST insert its own. For example, a device, a
telematics service provider in the call path, as well as the mobile telematics service provider in the call path, as well as the mobile
carrier handling the call will each provide one. There might be carrier handling the call will each provide one. There might be
circumstances where there is a service provider who is unaware that circumstances where there is a service provider who is unaware that
the call is an emergency call and cannot reasonably be expected to the call is an emergency call and cannot reasonably be expected to
determine that it is an emergency call. In that case, that service determine that it is an emergency call. In that case, that service
provider is not expected to provide EmergencyCallData. provider is not expected to provide 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.
6.2. Transmitting Blocks by Reference using the <provided-by> Element 6.2. Transmitting Blocks by Reference using the <provided-by> Element
The <EmergencyCallDataReference> element is used to transmit an The <EmergencyCallDataReference> element is used to transmit an
additional data block by reference within a <provided-by> element of additional data block by reference within a <provided-by> element of
a PIDF-LO. The <EmergencyCallDataReference> element has two a PIDF-LO. The <EmergencyCallDataReference> element has two
attributes: 'ref' to specify the URL, and 'purpose' to indicate the attributes: 'ref' to specify the URL, and 'purpose' to indicate the
type of data block referenced. The value of 'ref' is an HTTPS URL type of data block referenced. The value of 'ref' is an HTTPS URL
that resolves to a data structure with information about the call. 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 The value of 'purpose' is the same as used in a 'Call-Info' header
field (as specified in Section 6.1). field (as specified in Section 6.1).
skipping to change at page 41, line 47 skipping to change at page 41, line 47
... Location Retrieval/Response ... Location Retrieval/Response
Figure 15: Additional Data Example Flow Figure 15: Additional Data Example Flow
The example scenario starts with the end device itself adding device The example scenario starts with the end device itself adding device
information, owner/subscriber information, a location URI, and data information, owner/subscriber information, a location URI, and data
provider information to the outgoing emergency call setup message provider information to the outgoing emergency call setup message
(see step #1 in Figure 15). The SIP INVITE example is shown in (see step #1 in Figure 15). The SIP INVITE example is shown in
Figure 16. Figure 16.
INVITE urn:service:sos SIP/2.0 INVITE urn:service:sos SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: <urn:service:sos> To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg> Call-Info: <http://wwww.example.com/hannes/photo.jpg>
;purpose=icon, ;purpose=icon,
<http://www.example.com/hannes/> ;purpose=info, <http://www.example.com/hannes/> ;purpose=info,
<cid:1234567890@atlanta.example.com> <cid:1234567890@atlanta.example.com>
;purpose=EmergencyCallData.ProviderInfo, ;purpose=EmergencyCallData.ProviderInfo,
<cid:0123456789@atlanta.example.com> <cid:0123456789@atlanta.example.com>
;purpose=EmergencyCallData.DeviceInfo ;purpose=EmergencyCallData.DeviceInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/EmergencyCallData.ProviderInfo+xml application/EmergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:hannes@example.com> Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.DeviceInfo+xml Content-Type: application/EmergencyCallData.DeviceInfo+xml
Content-ID: <0123456789@atlanta.example.com> Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo <dev:EmergencyCallData.DeviceInfo
xmlns:dev= xmlns:dev=
"urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference> <dev:DataProviderReference>
d4b3072df09876543@[93.184.216.119] d4b3072df09876543@[93.184.216.119]
</dev:DataProviderReference> </dev:DataProviderReference>
<dev:DeviceClassification>laptop</dev:DeviceClassification> <dev:DeviceClassification>laptop</dev:DeviceClassification>
<dev:UniqueDeviceID <dev:UniqueDeviceID
TypeOfDeviceID="MAC">00-0d-4b-30-72-df TypeOfDeviceID="MAC">00-0d-4b-30-72-df
</dev:UniqueDeviceID> </dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo> </dev:EmergencyCallData.DeviceInfo>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo <pi:EmergencyCallData.ProviderInfo
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> xmlns:pi=
<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119] "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
</pi:DataProviderReference> <pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
<pi:DataProviderString>Hannes Tschofenig</pi:DataProviderString> </pi:DataProviderReference>
<pi:TypeOfProvider>Client</pi:TypeOfProvider> <pi:DataProviderString>Hannes Tschofenig</pi:DataProviderString>
<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI> <pi:TypeOfProvider>Client</pi:TypeOfProvider>
<pi:Language>en</pi:Language> <pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
<pi:DataProviderContact <pi:Language>en</pi:Language>
xmlns="urn:ietf:params:xml:ns:vcard-4.0"> <pi:DataProviderContact
<vcard> xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Hannes Tschofenig</text></fn> <vcard>
<n> <fn><text>Hannes Tschofenig</text></fn>
<surname>Hannes</surname> <n>
<given>Tschofenig</given> <surname>Hannes</surname>
<additional/> <given>Tschofenig</given>
<prefix/> <additional/>
<suffix>Dipl. Ing.</suffix> <prefix/>
</n> <suffix>Dipl. Ing.</suffix>
<bday><date>--0203</date></bday> </n>
<anniversary> <bday><date>--0203</date></bday>
<date-time>20090808T1430-0500</date-time> <anniversary>
</anniversary> <date-time>20090808T1430-0500</date-time>
<gender><sex>M</sex></gender> </anniversary>
<lang> <gender><sex>M</sex></gender>
<parameters><pref><integer>1</integer></pref> <lang>
</parameters> <parameters><pref><integer>1</integer></pref>
<language-tag>de</language-tag> </parameters>
</lang> <language-tag>de</language-tag>
<lang> </lang>
<parameters><pref><integer>2</integer></pref> <lang>
</parameters> <parameters><pref><integer>2</integer></pref>
<language-tag>en</language-tag> </parameters>
</lang> <language-tag>en</language-tag>
<adr> </lang>
<parameters> <adr>
<type><text>work</text></type> <parameters>
<label><text>Hannes Tschofenig <type><text>work</text></type>
Linnoitustie 6 <label><text>Hannes Tschofenig
Espoo, Finland Linnoitustie 6
02600</text></label> Espoo, Finland
</parameters> 02600</text></label>
<pobox/> </parameters>
<ext/> <pobox/>
<street>Linnoitustie 6</street> <ext/>
<locality>Espoo</locality> <street>Linnoitustie 6</street>
<region>Uusimaa</region> <locality>Espoo</locality>
<code>02600</code> <region>Uusimaa</region>
<country>Finland</country> <code>02600</code>
</adr> <country>Finland</country>
<adr> </adr>
<parameters> <adr>
<type><text>home</text></type> <parameters>
<label><text>Hannes Tschofenig <type><text>home</text></type>
c/o Hotel DuPont <label><text>Hannes Tschofenig
42 W 11th St c/o Hotel DuPont
Wilmington, DE 19801 42 W 11th St
USA</text></label> Wilmington, DE 19801
</parameters> USA</text></label>
<pobox/> </parameters>
<ext/> <pobox/>
<street>42 W 11th St</street> <ext/>
<locality>Wilmington</locality> <street>42 W 11th St</street>
<region>DE</region> <locality>Wilmington</locality>
<code>19801</code> <region>DE</region>
<country>USA</country> <code>19801</code>
</adr> <country>USA</country>
<tel> </adr>
<parameters> <tel>
<type> <parameters>
<text>work</text> <type>
<text>voice</text> <text>work</text>
</type> <text>voice</text>
</parameters> </type>
<uri>tel:+358 50 4871445</uri> </parameters>
</tel> <uri>tel:+358 50 4871445</uri>
<tel> </tel>
<parameters> <tel>
<type> <parameters>
<text>home</text> <type>
<text>voice</text> <text>home</text>
</type> <text>voice</text>
</parameters> </type>
<uri>tel:+1 555 555 0123</uri> </parameters>
</tel> <uri>tel:+1 555 555 0123</uri>
<tel> </tel>
<parameters> <tel>
<type> <parameters>
<text>work</text> <type>
<text>voice</text> <text>work</text>
<text>main-number</text> <text>voice</text>
</type> <text>main-number</text>
</parameters> </type>
<uri>tel:+1 302 594-3100</uri> </parameters>
</tel> <uri>tel:+1 302 594-3100</uri>
<email>
<parameters><type><text>work</text></type> </tel>
</parameters> <email>
<text>hannes.tschofenig@nsn.com</text> <parameters><type><text>work</text></type>
</email> </parameters>
<geo> <text>hannes.tschofenig@nsn.com</text>
<parameters><type><text>work</text></type> </email>
</parameters> <geo>
<uri>geo:60.210796,24.812924</uri> <parameters><type><text>work</text></type>
</geo> </parameters>
<geo> <uri>geo:60.210796,24.812924</uri>
<parameters><type><text>home</text></type> </geo>
</parameters> <geo>
<uri>geo:39.746537,-75.548027</uri> <parameters><type><text>home</text></type>
</geo> </parameters>
<key> <uri>geo:39.746537,-75.548027</uri>
<parameters> </geo>
<type><text>home</text></type> <key>
</parameters> <parameters>
<uri>https://www.example.com/key.asc</uri> <type><text>home</text></type>
</key> </parameters>
<tz><text>Finland/Helsinki</text></tz> <uri>https://www.example.com/key.asc</uri>
<url> </key>
<parameters><type><text>home</text></type> <tz><text>Finland/Helsinki</text></tz>
</parameters> <url>
<uri>http://example.com/hannes.tschofenig <parameters><type><text>home</text></type>
</uri> </parameters>
</url> <uri>http://example.com/hannes.tschofenig
</vcard> </uri>
</pi:DataProviderContact> </url>
</pi:EmergencyCallData.ProviderInfo> </vcard>
--boundary1-- </pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo>
--boundary1--
Figure 16: End Device sending SIP INVITE with Additional Data Figure 16: End Device sending SIP INVITE with Additional Data
In this example, information available to the access network provider In this example, information available to the access network provider
is included in the call setup message only indirectly via the use of 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 the location reference. The PSAP has to retrieve it via a separate
look-up step. Since the access network provider and the VoIP service look-up step. Since the access network provider and the VoIP service
provider are two independent entities in this scenario, the access provider are two independent entities in this scenario, the access
network provider is not involved in application layer exchanges; the network provider is not involved in application layer exchanges; the
SIP INVITE transits the access network transparently, as illustrated SIP INVITE transits the access network transparently, as illustrated
skipping to change at page 46, line 13 skipping to change at page 46, line 15
It performs typical emergency services related tasks (such as It performs typical emergency services related tasks (such as
location-based routing), and adds additional data, namely service and location-based routing), and adds additional data, namely service and
subscriber information as well as data provider information #2, to subscriber information as well as data provider information #2, to
the outgoing message. For the example we assume a VoIP service the outgoing message. For the example we assume a VoIP service
provider that deploys a back-to-back user agent allowing additional provider that deploys a back-to-back user agent allowing additional
data to be included in the body of the SIP message (rather than by 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 reference), which allows us to illustrate the use of multiple data
provider info blocks. The resulting message is shown in Figure 17. provider info blocks. The resulting message is shown in Figure 17.
The SIP INVITE is sent to the PSAP in step #3. The SIP INVITE is sent to the PSAP in step #3.
INVITE sips:psap@example.org SIP/2.0 INVITE sips:psap@example.org SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: <urn:service:sos> To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg>; Call-Info: <http://wwww.example.com/hannes/photo.jpg>;
purpose=icon, purpose=icon,
<http://www.example.com/hannes/>; purpose=info, <http://www.example.com/hannes/>; purpose=info,
<cid:1234567890@atlanta.example.com>; <cid:1234567890@atlanta.example.com>;
purpose=EmergencyCallData.ProviderInfo purpose=EmergencyCallData.ProviderInfo
<cid:0123456789@atlanta.example.com>; <cid:0123456789@atlanta.example.com>;
purpose=EmergencyCallData.DeviceInfo purpose=EmergencyCallData.DeviceInfo
Call-Info: <cid:bloorpyhex@atlanta.example.com>; Call-Info: <cid:bloorpyhex@atlanta.example.com>;
purpose=EmergencyCallData.ServiceInfo purpose=EmergencyCallData.ServiceInfo
Call-Info: <cid:aaabbb@atlanta.example.com>; Call-Info: <cid:aaabbb@atlanta.example.com>;
purpose=EmergencyCallData.ProviderInfo purpose=EmergencyCallData.ProviderInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/EmergencyCallData.ProviderInfo+xml application/EmergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:hannes@example.com> Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.DeviceInfo+xml Content-Type: application/EmergencyCallData.DeviceInfo+xml
Content-ID: <0123456789@atlanta.example.com> Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:EmergencyCallData.DeviceInfo <dev:EmergencyCallData.DeviceInfo
xmlns:dev= xmlns:dev=
"urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
<dev:DataProviderReference>d4b3072df09876543@[93.184.216.119] <dev:DataProviderReference>d4b3072df09876543@[93.184.216.119]
</dev:DataProviderReference> </dev:DataProviderReference>
<dev:DeviceClassification>laptop</dev:DeviceClassification> <dev:DeviceClassification>laptop</dev:DeviceClassification>
<dev:UniqueDeviceID <dev:UniqueDeviceID
TypeOfDeviceID="MAC">00-0d-4b-30-72-df</dev:UniqueDeviceID> TypeOfDeviceID="MAC">00-0d-4b-30-72-df</dev:UniqueDeviceID>
</dev:EmergencyCallData.DeviceInfo> </dev:EmergencyCallData.DeviceInfo>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo <pi:EmergencyCallData.ProviderInfo
xmlns:pi= xmlns:pi=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119] <pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
</pi:DataProviderReference> </pi:DataProviderReference>
<pi:DataProviderString>Hannes Tschofenig <pi:DataProviderString>Hannes Tschofenig
</pi:DataProviderString> </pi:DataProviderString>
<pi:TypeOfProvider>Client</pi:TypeOfProvider> <pi:TypeOfProvider>Client</pi:TypeOfProvider>
<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI> <pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
<pi:Language>en</pi:Language> <pi:Language>en</pi:Language>
<pi:DataProviderContact <pi:DataProviderContact
xmlns="urn:ietf:params:xml:ns:vcard-4.0"> xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard> <vcard>
<fn><text>Hannes Tschofenig</text></fn> <fn><text>Hannes Tschofenig</text></fn>
<n> <n>
<surname>Hannes</surname> <surname>Hannes</surname>
<given>Tschofenig</given> <given>Tschofenig</given>
<additional/> <additional/>
<prefix/> <prefix/>
<suffix>Dipl. Ing.</suffix> <suffix>Dipl. Ing.</suffix>
</n> </n>
<bday><date>--0203</date></bday> <bday><date>--0203</date></bday>
<anniversary> <anniversary>
<date-time>20090808T1430-0500</date-time> <date-time>20090808T1430-0500</date-time>
</anniversary> </anniversary>
<gender><sex>M</sex></gender> <gender><sex>M</sex></gender>
<lang> <lang>
<parameters><pref><integer>1</integer></pref> <parameters><pref><integer>1</integer></pref>
</parameters> </parameters>
<language-tag>de</language-tag> <language-tag>de</language-tag>
</lang> </lang>
<lang> <lang>
<parameters><pref><integer>2</integer></pref> <parameters><pref><integer>2</integer></pref>
</parameters> </parameters>
<language-tag>en</language-tag> <language-tag>en</language-tag>
</lang> </lang>
<adr> <adr>
<parameters> <parameters>
<type><text>work</text></type> <type><text>work</text></type>
<label><text>Hannes Tschofenig <label><text>Hannes Tschofenig
Linnoitustie 6 Linnoitustie 6
Espoo, Finland Espoo, Finland
02600</text></label> 02600</text></label>
</parameters> </parameters>
<pobox/> <pobox/>
<ext/> <ext/>
<street>Linnoitustie 6</street> <street>Linnoitustie 6</street>
<locality>Espoo</locality> <locality>Espoo</locality>
<region>Uusimaa</region> <region>Uusimaa</region>
<code>02600</code> <code>02600</code>
<country>Finland</country> <country>Finland</country>
</adr> </adr>
<adr> <adr>
<parameters> <parameters>
<type><text>home</text></type> <type><text>home</text></type>
<label><text>Hannes Tschofenig <label><text>Hannes Tschofenig
c/o Hotel DuPont c/o Hotel DuPont
42 W 11th St 42 W 11th St
Wilmington, DE 19801 Wilmington, DE 19801
USA</text></label> USA</text></label>
</parameters> </parameters>
<pobox/> <pobox/>
<ext/> <ext/>
<street>42 W 11th St</street> <street>42 W 11th St</street>
<locality>Wilmington</locality> <locality>Wilmington</locality>
<region>DE</region> <region>DE</region>
<code>19801</code> <code>19801</code>
<country>USA</country> <country>USA</country>
</adr> </adr>
<tel> <tel>
<parameters> <parameters>
<type> <type>
<text>work</text> <text>work</text>
<text>voice</text> <text>voice</text>
</type> </type>
</parameters> </parameters>
<uri>tel:+358 50 4871445</uri> <uri>tel:+358 50 4871445</uri>
</tel> </tel>
<tel> <tel>
<parameters> <parameters>
<type> <type>
<text>home</text> <text>home</text>
<text>voice</text> <text>voice</text>
</type> </type>
</parameters> </parameters>
<uri>tel:+1 555 555 0123</uri> <uri>tel:+1 555 555 0123</uri>
</tel> </tel>
<email> <email>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<text>hannes.tschofenig@nsn.com</text> <text>hannes.tschofenig@nsn.com</text>
</email> </email>
<geo> <geo>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<uri>geo:60.210796,24.812924</uri> <uri>geo:60.210796,24.812924</uri>
</geo> </geo>
<geo> <geo>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>geo:39.746537,-75.548027</uri> <uri>geo:39.746537,-75.548027</uri>
</geo> </geo>
<key> <key>
<parameters> <parameters>
<type><text>home</text></type> <type><text>home</text></type>
</parameters> </parameters>
<uri>https://www.example.com/key.asc</uri> <uri>https://www.example.com/key.asc</uri>
</key> </key>
<tz><text>Finland/Helsinki</text></tz> <tz><text>Finland/Helsinki</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://example.com/hannes.tschofenig</uri> <uri>http://example.com/hannes.tschofenig</uri>
</url> </url>
</vcard> </vcard>
</pi:DataProviderContact> </pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo> </pi:EmergencyCallData.ProviderInfo>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.ServiceInfo+xml Content-Type: application/EmergencyCallData.ServiceInfo+xml
Content-ID: <bloorpyhex@atlanta.example.com> Content-ID: <bloorpyhex@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:EmergencyCallData.ServiceInfo <svc:EmergencyCallData.ServiceInfo
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"> xmlns:svc=
<svc:DataProviderReference>string0987654321@example.org "urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo">
</svc:DataProviderReference> <svc:DataProviderReference>string0987654321@example.org
<svc:ServiceEnvironment>Residence</svc:ServiceEnvironment> </svc:DataProviderReference>
<svc:ServiceType>VOIP</svc:ServiceType> <svc:ServiceEnvironment>Residence</svc:ServiceEnvironment>
<svc:ServiceMobility>Unknown</svc:ServiceMobility> <svc:ServiceType>VOIP</svc:ServiceType>
</svc:EmergencyCallData.ServiceInfo> <svc:ServiceMobility>Unknown</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-Type: application/EmergencyCallData.ProviderInfo+xml
Content-ID: <aaabbb@atlanta.example.com> Content-ID: <aaabbb@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pi:EmergencyCallData.ProviderInfo <pi:EmergencyCallData.ProviderInfo
xmlns:pi= xmlns:pi=
"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
<pi:DataProviderReference>string0987654321@example.org <pi:DataProviderReference>string0987654321@example.org
</pi:DataProviderReference> </pi:DataProviderReference>
<pi:DataProviderString>Exemplar VoIP Provider <pi:DataProviderString>Exemplar VoIP Provider
</pi:DataProviderString> </pi:DataProviderString>
<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID> <pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries> <pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider> <pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>
<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI> <pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>
<pi:Language>en</pi:Language> <pi:Language>en</pi:Language>
<pi:DataProviderContact <pi:DataProviderContact
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"> xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard> <vcard>
<fn><text>John Doe</text></fn> <fn><text>John Doe</text></fn>
<n> <n>
<surname>John</surname> <surname>John</surname>
<given>Doe</given> <given>Doe</given>
<additional/> <additional/>
<prefix/> <prefix/>
<suffix/> <suffix/>
</n> </n>
<bday><date>--0203</date></bday> <bday><date>--0203</date></bday>
<anniversary> <anniversary>
<date-time>20090808T1430-0500</date-time> <date-time>20090808T1430-0500</date-time>
</anniversary> </anniversary>
<gender><sex>M</sex></gender> <gender><sex>M</sex></gender>
<lang> <lang>
<parameters><pref><integer>1</integer></pref> <parameters><pref><integer>1</integer></pref>
</parameters> </parameters>
<language-tag>en</language-tag> <language-tag>en</language-tag>
</lang> </lang>
<org> <org>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<text>Exemplar VoIP Provider</text> <text>Exemplar VoIP Provider</text>
</org> </org>
<adr> <adr>
<parameters> <parameters>
<type><text>work</text></type> <type><text>work</text></type>
<label><text>John Doe <label><text>John Doe
123 Middle Street 123 Middle Street
The Sticks, IA 50055</text></label> The Sticks, IA 50055</text></label>
</parameters> </parameters>
<pobox/> <pobox/>
<ext/> <ext/>
<street>123 Middle Street</street> <street>123 Middle Street</street>
<locality>the Sticks</locality> <locality>the Sticks</locality>
<region>IA</region> <region>IA</region>
<code>50055</code> <code>50055</code>
<country>USA</country> <country>USA</country>
</adr> </adr>
<tel> <tel>
<parameters> <parameters>
<type> <type>
<text>work</text> <text>work</text>
<text>voice</text> <text>voice</text>
<text>main-number</text> <text>main-number</text>
</type> </type>
</parameters> </parameters>
<uri>sips:john.doe@example.com</uri> <uri>sips:john.doe@example.com</uri>
</tel> </tel>
<email> <email>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<text>john.doe@example.com</text> <text>john.doe@example.com</text>
</email> </email>
<geo> <geo>
<parameters><type><text>work</text></type> <parameters><type><text>work</text></type>
</parameters> </parameters>
<uri>geo:41.761838,-92.963268</uri> <uri>geo:41.761838,-92.963268</uri>
</geo> </geo>
<tz><text>America/Chicago</text></tz> <tz><text>America/Chicago</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://www.example.com/john.doe</uri> <uri>http://www.example.com/john.doe</uri>
</url> </url>
</vcard> </vcard>
</pi:DataProviderContact> </pi:DataProviderContact>
</pi:EmergencyCallData.ProviderInfo> </pi:EmergencyCallData.ProviderInfo>
--boundary1-- --boundary1--
Figure 17: VoIP Provider sending SIP INVITE with Additional Data Figure 17: VoIP Provider sending SIP INVITE with Additional Data
Finally, the PSAP requests location information from the access Finally, the PSAP requests location information from the access
network provider. The response is shown in Figure 18. Along with network provider. The response is shown in Figure 18. Along with
the location information, additional data is provided in the the location information, additional data is provided in the
<provided-by> element of the PIDF-LO. This request and response is <provided-by> element of the PIDF-LO. This request and response is
step #4. step #4.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 54, line 23 skipping to change at page 54, line 25
name="EmergencyCallData.ProviderInfo" name="EmergencyCallData.ProviderInfo"
type="pi:ProviderInfoType"/> type="pi:ProviderInfoType"/>
<xs:simpleType name="SubcontractorPriorityType"> <xs:simpleType name="SubcontractorPriorityType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="sub"/> <xs:enumeration value="sub"/>
<xs:enumeration value="main"/> <xs:enumeration value="main"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="ProviderInfoType"> <xs:complexType name="ProviderInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="DataProviderReference" <xs:element name="DataProviderReference"
type="xs:token" minOccurs="1" maxOccurs="1"/> type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="DataProviderString" <xs:element name="DataProviderString"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="ProviderID" <xs:element name="ProviderID"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ProviderIDSeries" <xs:element name="ProviderIDSeries"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="TypeOfProvider" <xs:element name="TypeOfProvider"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:token" minOccurs="1" maxOccurs="1"/>
<xs:element name="ContactURI" type="xs:anyURI" <xs:element name="ContactURI" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="Language" minOccurs="1" maxOccurs="unbounded"> <xs:element name="Language" minOccurs="1" maxOccurs="unbounded">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern <xs:pattern
value="([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8}) 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}| (-[a-z]{4})?(-([a-z]{2}|\d{3}))?(-([0-9a-z]{5,8}|
skipping to change at page 60, line 50 skipping to change at page 60, line 50
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 23: EmergencyCallData.Comment XML Schema. Figure 23: EmergencyCallData.Comment XML Schema.
8.6. provided-by XML Schema 8.6. provided-by XML Schema
This section defines the provided-by schema. This section defines the provided-by schema.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace= targetNamespace=
"urn:ietf:params:xml:ns:EmergencyCallData" "urn:ietf:params:xml:ns:EmergencyCallData"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData" xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo" xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo" xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
xmlns:sub= xmlns:sub=
"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" "urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment" xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> 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" <xs:import
type="ad:ByRefType"/> 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="EmergencyCallDataValue" <xs:element name="EmergencyCallDataReference"
type="ad:EmergencyCallDataValueType"/> type="ad:ByRefType"/>
<!-- Additional Data By Reference --> <xs:element name="EmergencyCallDataValue"
type="ad:EmergencyCallDataValueType"/>
<xs:complexType name="ByRefType"> <!-- Additional Data By Reference -->
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
<xs:attribute name="purpose" type="xs:token"
use="required"/>
<xs:attribute name="ref" type="xs:anyURI" <xs:complexType name="ByRefType">
use="required"/> <xs:complexContent>
</xs:restriction> <xs:restriction base="xs:anyType">
</xs:complexContent> <xs:sequence>
</xs:complexType> <xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
<xs:attribute name="purpose" type="xs:token"
use="required"/>
<xs:attribute name="ref" type="xs:anyURI"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Additional Data By Value --> <!-- Additional Data By Value -->
<xs:complexType name="EmergencyCallDataValueType"> <xs:complexType name="EmergencyCallDataValueType">
<xs:sequence> <xs:sequence>
<xs:element name="EmergencyCallData.ProviderInfo" <xs:element name="EmergencyCallData.ProviderInfo"
type="pi:ProviderInfoType" type="pi:ProviderInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="EmergencyCallData.ServiceInfo" <xs:element name="EmergencyCallData.ServiceInfo"
type="svc:ServiceInfoType" type="svc:ServiceInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="EmergencyCallData.DeviceInfo" <xs:element name="EmergencyCallData.DeviceInfo"
type="dev:DeviceInfoType" type="dev:DeviceInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="EmergencyCallData.SubscriberInfo" <xs:element name="EmergencyCallData.SubscriberInfo"
type="sub:SubscriberInfoType" type="sub:SubscriberInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="EmergencyCallData.Comment" <xs:element name="EmergencyCallData.Comment"
type="com:CommentType" type="com:CommentType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 24: provided-by XML Schema Figure 24: provided-by XML Schema
9. Security Considerations 9. Security Considerations
The data structures described in this document contain information The data structures described in this document contain information
usually considered private. When information is provided by value, usually considered private. When information is provided by value,
entities that are a party to the SIP signaling (such as proxy servers 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 and back-to-back user agents) will have access to it and need to
protect it against inappropriate disclosure. An entity that is able protect it against inappropriate disclosure. An entity that is able
to eavesdrop on the SIP signaling will also have access. Some access to eavesdrop on the SIP signaling will also have access. Some
types (such as in-the-clear Wi-Fi) are more vulnerable than others Internet access types (such as in-the-clear Wi-Fi) are more
(such as 3G or 4G cellular data traffic) to eavesdropping. vulnerable than others (such as 3G or 4G cellular data traffic) to
Mechanisms that protect against eavesdropping (such as Transport eavesdropping. Mechanisms that protect against eavesdropping (such
Layer Security (TLS) version 1.2 or later) SHOULD be preferentially as Transport Layer Security (TLS) version 1.2 or later) SHOULD be
used whenever feasible. (This requirement is not a "MUST" because preferentially used whenever feasible. (This requirement is not a
there is an existing deployed base of clear-text SIP, and also "MUST" because there is an existing deployed base of clear-text SIP,
because, as an emergency call, it is more important for the call to and also because, as an emergency call, it is more important for the
go through than for it to be protected; e.g., the call MUST proceed call to go through than for it to be protected; e.g., the call MUST
even if the TLS negotiation or certificate verification fails for proceed even if the TLS negotiation or certificate verification fails
whatever reason.) When information is provided by reference, TLS for whatever reason.) When information is provided by reference, TLS
mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for mutual authentication is REQUIRED. That is, HTTPS is REQUIRED for
dereferencing, the requestor MUST use a client certificate to dereferencing, the requestor MUST use a client certificate to
authenticate the HTTP request, and the provider of the information is authenticate the HTTP request, and the provider of the information is
REQUIRED to validate the credentials provided by the requester. REQUIRED to validate the credentials provided by the requester.
While the creation of a public key infrastructure (PKI) that has While the creation of a public key infrastructure (PKI) that has
global scope might be difficult, the alternatives to creating devices global scope might be difficult, the alternatives to creating devices
and services that can provide critical information securely are more and services that can provide critical information securely are more
daunting. The provider of the information MAY enforce any policy it daunting. The provider of the information MAY enforce any policy it
wishes to use, but PSAPs and responder agencies are strongly advised wishes to use, but PSAPs and responder agencies are strongly advised
to deploy a PKI so that providers of additional data can check the to deploy a PKI so that providers of additional data can check the
skipping to change at page 67, line 10 skipping to change at page 67, line 12
sensitive and intermediaries are involved, transmitting by reference sensitive and intermediaries are involved, transmitting by reference
might be appropriate, assuming the source of the data can operate a might be appropriate, assuming the source of the data can operate a
sufficient dereferencing infrastructure and that proper access sufficient dereferencing infrastructure and that proper access
control policies are available for distinguishing the different control policies are available for distinguishing the different
entities dereferencing the reference. Without access control entities dereferencing the reference. Without access control
policies any party in possession of the reference is able to resolve policies any party in possession of the reference is able to resolve
the reference and to obtain the data, including intermediaries. the reference and to obtain the data, including intermediaries.
11. IANA Considerations 11. IANA Considerations
11.1. Registry creation 11.1. Emergency Call Additional Data Registry
This document creates a new registry called 'Emergency Call This document creates a new registry called 'Emergency Call
Additional Data' with a number of sub-registries. Additional Data' with a number of sub-registries.
For several of the sub-registries, "Expert Review" is the criteria For several of the sub-registries, "Expert Review" is the criteria
for adding new entries. As discussed in Section 5, it can be for adding new entries. As discussed in Section 5, it can be
counterproductive to register new types of data, and as discussed in counterproductive to register new types of data, and as discussed in
Section 10, data sent as part of an emergency call can be very Section 10, data sent as part of an emergency call can be very
privacy-sensitive. In some cases, it is anticipated that various privacy-sensitive. In some cases, it is anticipated that various
standards bodies dealing with emergency services might need to standards bodies dealing with emergency services might need to
skipping to change at page 69, line 17 skipping to change at page 69, line 23
to when the value is to be used or which value is to be used. to when the value is to be used or which value is to be used.
The content of this registry includes: The content of this registry includes:
Token: The value used in the <ServiceMobility> element. Token: The value used in the <ServiceMobility> element.
Description: A short description of the value. Description: A short description of the value.
The initial set of values is listed in Figure 6. The initial set of values is listed in Figure 6.
11.1.5. Service Provider Type Registry 11.1.5. Type of Provider Registry
This document creates a new sub-registry called "Service Provider This document creates a new sub-registry called "Type of Provider".
Type". As defined in [RFC5226], this registry operates under "Expert As defined in [RFC5226], this registry operates under "Expert
Review". The expert should determine that the proposed new value is Review". The expert should determine that the proposed new value is
distinct from existing values and appropriate for use in the distinct from existing values and appropriate for use in the
<TypeOfServicerProvider> element <TypeOfServicerProvider> element
The content of this registry includes: The content of this registry includes:
Token: The value used in the <TypeOfProvider> element. Token: The value used in the <TypeOfProvider> element.
Description: A short description of the type of service provider. Description: A short description of the type of service provider.
skipping to change at page 70, line 5 skipping to change at page 70, line 7
the class will be clear to implementors and PSAPs/responders. the class will be clear to implementors and PSAPs/responders.
The content of this registry includes: The content of this registry includes:
Token: Value used in the <DeviceClassification> element. Token: Value used in the <DeviceClassification> element.
Description: Short description identifying the device type. Description: Short description identifying the device type.
The initial set of values are defined in Figure 8. The initial set of values are defined in Figure 8.
11.1.7. Device ID Type Type Registry 11.1.7. Device ID Type Registry
This document creates a new sub-registry called "Device ID Type". As This document creates a new sub-registry called "Device ID Type". As
defined in [RFC5226], this registry operates under "Expert Review" defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should ascertain that the proposed type is well rules. The expert should ascertain that the proposed type is well
understood, and provides information which PSAPs and responders are understood, and provides information which PSAPs and responders are
able to use to uniquely identify a device. (For example, a biometric able to use to uniquely identify a device. (For example, a biometric
fingerprint used to authenticate a device would not normally be fingerprint used to authenticate a device would not normally be
useful by a PSAP or responder to identify a device.) useful by a PSAP or responder to identify a device.)
The content of this registry includes: The content of this registry includes:
skipping to change at page 83, line 27 skipping to change at page 83, line 27
<h1>Namespace for Additional Data related to an Emergency Call <h1>Namespace for Additional Data related to an Emergency Call
</h1> </h1>
<h2> Comment</h2> <h2> Comment</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
11.6. Schema Registrations 11.6. Schema Registrations
This specification registers five schemas, as per the guidelines in This specification registers the following schemas, as per the
RFC 3688 [RFC3688]. guidelines in RFC 3688 [RFC3688].
Name: Provided-by Schema
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.
Name: ProviderInfo Schema
URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo URI: urn:ietf:params:xml:schema:emergencycalldata:ProviderInfo
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 19. XML: The XML schema can be found in Figure 19.
URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo Name: ServiceInfo Schema
URI: urn:ietf:params:xml:schema:emergencycalldata:ServiceInfo
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 20. XML: The XML schema can be found in Figure 20.
Name: DeviceInfo Schema
URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo URI: urn:ietf:params:xml:schema:emergencycalldata:DeviceInfo
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 21. XML: The XML schema can be found in Figure 21.
Name: SubscriberInfo Schema
URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo URI: urn:ietf:params:xml:schema:emergencycalldata:SubscriberInfo
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Section 8.4. XML: The XML schema can be found in Section 8.4.
Name: Comment Schema
URI: urn:ietf:params:xml:schema:emergencycalldata:comment URI: urn:ietf:params:xml:schema:emergencycalldata:comment
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Section 8.5. XML: The XML schema can be found in Section 8.5.
Name: Additional Data VCard Schema
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.
11.7. VCard Parameter Value Registration 11.7. VCard Parameter Value Registration
This document registers a new value in the vCARD Parameter Values This document registers a new value in the vCARD Parameter Values
registry as defined by [RFC6350] with the following template: registry as defined by [RFC6350] with the following template:
Value: main Value: main
Purpose: The main telephone number, typically of an enterprise, as Purpose: The main telephone number, typically of an enterprise, as
opposed to a direct dial number of an individual employee opposed to a direct dial number of an individual employee
Conformance: This value can be used with the "TYPE" parameter Conformance: This value can be used with the "TYPE" parameter
applied on the "TEL" property. applied on the "TEL" property.
Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90 Example(s): TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90
00 00
12. Acknowledgments 12. Acknowledgments
skipping to change at page 84, line 48 skipping to change at page 85, line 29
group. The authors are grateful for the initial work and extended group. The authors are grateful for the initial work and extended
comments provided by many NENA participants, including Delaine comments provided by many NENA participants, including Delaine
Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra,
and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank
Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback
regarding the vCard/xCard use in this specification. regarding the vCard/xCard use in this specification.
We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris
Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, and Francis Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, Amanda Baber,
Dupont for their review comments. Alissa Cooper, Guy Caron, Ben Dan Banks, Andrew Newton, Philip Reichl, and Francis Dupont for their
Campbell, and Barry Leiba deserves special mention for their detailed review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry
and extensive review comments, which were very helpful and Leiba deserves special mention for their detailed and extensive
appreciated. review comments, which were very helpful and appreciated.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<http://www.rfc-editor.org/info/rfc2392>.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001. and QSIG Objects", RFC 3204, DOI 10.17487/RFC3204,
December 2001, <http://www.rfc-editor.org/info/rfc3204>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter", RFC 3459, January 2003. Extensions (MIME) Parameter", RFC 3459,
DOI 10.17487/RFC3459, January 2003,
<http://www.rfc-editor.org/info/rfc3459>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
3966, December 2004. RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
<http://www.rfc-editor.org/info/rfc4119>. <http://www.rfc-editor.org/info/rfc4119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009. Initiation Protocol (SIP)", RFC 5621,
DOI 10.17487/RFC5621, September 2009,
<http://www.rfc-editor.org/info/rfc5621>.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. DOI 10.17487/RFC6350, August 2011,
<http://www.rfc-editor.org/info/rfc6350>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC [RFC6351] Perreault, S., "xCard: vCard XML Representation",
6351, August 2011. RFC 6351, DOI 10.17487/RFC6351, August 2011,
<http://www.rfc-editor.org/info/rfc6351>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13,
6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <http://www.rfc-editor.org/info/rfc6838>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, DOI 10.17487/RFC7303, July 2014,
<http://www.rfc-editor.org/info/rfc7303>. <http://www.rfc-editor.org/info/rfc7303>.
13.2. Informational References 13.2. Informational References
[ECRIT-WG-wiki] [ECRIT-WG-wiki]
IETF, "ECRIT WG Wiki"", July 2015, IETF, "ECRIT WG Wiki"", July 2015,
<http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/ <http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/
WikiStart/additional-data-examples.zip>. WikiStart/additional-data-examples.zip>.
[I-D.gellens-slim-negotiating-human-language] [I-D.ietf-slim-negotiating-human-language]
Gellens, R., "Negotiating Human Language in Real-Time Gellens, R., "Negotiating Human Language in Real-Time
Communications", draft-gellens-slim-negotiating-human- Communications", draft-ietf-slim-negotiating-human-
language-02 (work in progress), July 2015. language-01 (work in progress), March 2016.
[IANA-XML-Schemas] [IANA-XML-Schemas]
IANA, "IANA XML Schemas"", July 2015, IANA, "IANA XML Schemas"", July 2015,
<http://www.iana.org/assignments/xml-registry/ <http://www.iana.org/assignments/xml-registry/
xml-registry.xhtml#schema>. xml-registry.xhtml#schema>.
[LERG] Telcordia Technologies, Inc., "Local Exchange Routing [IEEE-1512-2006]
Guide (LERG)", ANI II Digits Definitions , June 2015. IEEE, "1512-2006 - IEEE Standard for Common Incident
Management Message Sets for Use by Emergency Management
Centers", Jun 2006, <https://standards.ieee.org/findstds/
standard/1512-2006.html>.
[LanguageTagRegistry] [LanguageTagRegistry]
IANA, "Language Subtag Registry", Feb 2015, IANA, "Language Subtag Registry", Feb 2015,
<http://www.iana.org/assignments/language-subtag-registry/ <http://www.iana.org/assignments/language-subtag-registry/
language-subtag-registry>. language-subtag-registry>.
[LERG] Telcordia Technologies, Inc., "Local Exchange Routing
Guide (LERG)", ANI II Digits Definitions , June 2015.
[NANP] North American Numbering Plan Administration, "ANI II [NANP] North American Numbering Plan Administration, "ANI II
Digits Assignments", September 2015, Digits Assignments", September 2015,
<http://nanpa.com/number_resource_info/ <http://nanpa.com/number_resource_info/
ani_ii_assignments.html>. ani_ii_assignments.html>.
[nc911] North Carolina 911 Board, "North Carolina Telecommunicator
Reference", January 2009, <https://www.nc911.nc.gov/pdf/
A_TelecommunicatorReference.pdf>.
[NENA-02-010] [NENA-02-010]
National Emergency Number Association (NENA), "NENA National Emergency Number Association (NENA), "NENA
Standard Data Formats for 9-1-1 Data Exchange & GIS Standard Data Formats for 9-1-1 Data Exchange & GIS
Mapping", NENA Standard 02-010, December 2010, Mapping", NENA Standard 02-010, December 2010,
<http://www.nena.org>. <http://www.nena.org>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, DOI 10.17487/RFC5012, January 2008, RFC 5012, DOI 10.17487/RFC5012, January 2008,
<http://www.rfc-editor.org/info/rfc5012>. <http://www.rfc-editor.org/info/rfc5012>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <http://www.rfc-editor.org/info/rfc5139>.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, DOI 10.17487/RFC5491, March 2009, RFC 5491, DOI 10.17487/RFC5491, March 2009,
<http://www.rfc-editor.org/info/rfc5491>. <http://www.rfc-editor.org/info/rfc5491>.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, DOI 10.17487/RFC5582, September
2009, <http://www.rfc-editor.org/info/rfc5582>.
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", RFC 5962, DOI Data Format Location Object (PIDF-LO)", RFC 5962,
10.17487/RFC5962, September 2010, DOI 10.17487/RFC5962, September 2010,
<http://www.rfc-editor.org/info/rfc5962>. <http://www.rfc-editor.org/info/rfc5962>.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
5985, September 2010. RFC 5985, DOI 10.17487/RFC5985, September 2010,
<http://www.rfc-editor.org/info/rfc5985>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <http://www.rfc-editor.org/info/rfc6443>. 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in the R. George, "Specifying Civic Address Extensions in the
Presence Information Data Format Location Object (PIDF- Presence Information Data Format Location Object (PIDF-
LO)", RFC 6848, January 2013. LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013,
<http://www.rfc-editor.org/info/rfc6848>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<http://www.rfc-editor.org/info/rfc6881>. <http://www.rfc-editor.org/info/rfc6881>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July Considerations for Internet Protocols", RFC 6973,
2013. DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. [RFC7035] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.
Thomson, "Relative Location Representation", RFC 7035, Thomson, "Relative Location Representation", RFC 7035,
October 2013. DOI 10.17487/RFC7035, October 2013,
<http://www.rfc-editor.org/info/rfc7035>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
Patel, "Public Safety Answering Point (PSAP) Callback", Patel, "Public Safety Answering Point (PSAP) Callback",
RFC 7090, DOI 10.17487/RFC7090, April 2014, RFC 7090, DOI 10.17487/RFC7090, April 2014,
<http://www.rfc-editor.org/info/rfc7090>. <http://www.rfc-editor.org/info/rfc7090>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[nc911] North Carolina 911 Board, "North Carolina Telecommunicator
Reference", January 2009, <https://www.nc911.nc.gov/pdf/
A_TelecommunicatorReference.pdf>.
13.3. URIs 13.3. URIs
[1] http://www.nena.org/?page=cid2014 [1] http://www.nena.org/?page=cid2014
[2] http://www.nena.org/?page=CompanyID [2] http://www.nena.org/?page=CompanyID
Appendix A. XML Schema for vCard/xCard Appendix A. XML Schema for vCard/xCard
This section contains the vCard/xCard XML schema version of the Relax This section contains the vCard/xCard XML schema version of the Relax
NG schema defined in RFC 6351 [RFC6351] for simplified use with the NG schema defined in RFC 6351 [RFC6351] for use with the XML schemas
XML schemas defined in this document. The schema in RFC 6351 defined in this document. In addition to mapping the Relax NG schema
[RFC6351] is the normative source and this section is informative to an XML schema this specification furthermore applies an errata
only. raised for RFC 6351 regarding the type definition (see RFC Errata ID:
3047).
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:vcard-4.0" targetNamespace="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:ns1="urn:ietf:params:xml:ns:vcard-4.0"> xmlns:ns1="urn:ietf:params:xml:ns:vcard-4.0">
<!-- <!--
3.3 3.3
iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" } iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" }
skipping to change at page 100, line 8 skipping to change at page 101, line 9
<xs:sequence> <xs:sequence>
<xs:element minOccurs="0" name="parameters"> <xs:element minOccurs="0" name="parameters">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:group ref="ns1:param-altid"/> <xs:group ref="ns1:param-altid"/>
<xs:group ref="ns1:param-pid"/> <xs:group ref="ns1:param-pid"/>
<xs:group ref="ns1:param-pref"/> <xs:group ref="ns1:param-pref"/>
<xs:element minOccurs="0" name="type"> <xs:element minOccurs="0" name="type">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element maxOccurs="unbounded" name="text"> <xs:element maxOccurs="unbounded" name="text"
<xs:simpleType> type="xs:string"/>
<xs:restriction base="xs:token">
<xs:enumeration value="work"/>
<xs:enumeration value="home"/>
<xs:enumeration value="text"/>
<xs:enumeration value="voice"/>
<xs:enumeration value="fax"/>
<xs:enumeration value="cell"/>
<xs:enumeration value="video"/>
<xs:enumeration value="pager"/>
<xs:enumeration value="textphone"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:group ref="ns1:param-mediatype"/> <xs:group ref="ns1:param-mediatype"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:choice> <xs:choice>
<xs:element ref="ns1:text"/> <xs:element ref="ns1:text"/>
<xs:element ref="ns1:uri"/> <xs:element ref="ns1:uri"/>
skipping to change at page 112, line 4 skipping to change at page 112, line 34
editor to point to the location. editor to point to the location.
For convenience of readers, the schemas are available at http://ip- For convenience of readers, the schemas are available at http://ip-
emergency.net/additional-data.zip and the XML examples are available emergency.net/additional-data.zip and the XML examples are available
at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki]. at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki].
Note to RFC Editor: After IANA has published the schemas, the above Note to RFC Editor: After IANA has published the schemas, the above
link to the schemas should be replaced with [IANA-XML-Schemas]. link to the schemas should be replaced with [IANA-XML-Schemas].
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc.
5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
US US
Email: rg+ietf@randy.pensive.org Email: rg+ietf@randy.pensive.org
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
 End of changes. 104 change blocks. 
658 lines changed or deleted 714 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/