< draft-ietf-ecrit-additional-data-30.txt   draft-ietf-ecrit-additional-data-31.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: January 1, 2016 NeuStar Expires: January 4, 2016 NeuStar
H. Tschofenig H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
June 30, 2015 July 3, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-30.txt draft-ietf-ecrit-additional-data-31.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 device that sends it, as well as any application service (PSAP), the originating device, the access network provider to which
provider in the path of the call, or access network provider through the device is connected, and all service providers in the path of the
which the call originated has information about the call, the caller call have information about the call, the caller or the location
or the location which might be helpful for the PSAP to have in which is helpful for the PSAP to have in handling the emergency.
handling the emergency. This document describes data structures and This document describes data structures and mechanisms to convey such
a mechanism to convey such data to the PSAP. The intent is that data to the PSAP. The intent is that every emergency call carry the
every emergency call carry the information described here using the information described here using the mechanisms described here.
mechanisms described here.
The mechanism uses a Uniform Resource Identifier (URI), which may The mechanisms permit the data to be conveyed by reference (as an
point to either an external resource or an object in the body of the external resource) or by value (within the body of a SIP message or a
SIP message. The mechanism thus allows the data to be passed by location object). This follows the tradition of prior emergency
reference (when the URI points to an external resource) or by value services standardization work where data can be conveyed by value
(when it points into the body of the message). This follows the within the call signaling (i.e., in the body of the SIP message) or
tradition of prior emergency services standardization work where data by reference.
can be conveyed by value within the call signaling (i.e., in body of
the SIP message) and also by reference.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 4, 2016.
This Internet-Draft will expire on January 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 33 skipping to change at page 2, line 27
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7
4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Data Provider Information . . . . . . . . . . . . . . . . 8 4.1. Data Provider Information . . . . . . . . . . . . . . . . 9
4.1.1. Data Provider String . . . . . . . . . . . . . . . . 9 4.1.1. Data Provider String . . . . . . . . . . . . . . . . 9
4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9 4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9
4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 10 4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 10
4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 11 4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 11
4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 11 4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 12
4.1.6. Data Provider Languages(s) Supported . . . . . . . . 12 4.1.6. Data Provider Languages(s) Supported . . . . . . . . 13
4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 13 4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 13
4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 13 4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 14
4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 14 4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 15
4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 14 4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 15
4.2. Service Information . . . . . . . . . . . . . . . . . . . 16 4.2. Service Information . . . . . . . . . . . . . . . . . . . 17
4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17 4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17
4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Service Mobility Environment . . . . . . . . . . . . 19 4.2.3. Service Mobility Environment . . . . . . . . . . . . 20
4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 20 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21
4.3. Device Information . . . . . . . . . . . . . . . . . . . 21 4.3. Device Information . . . . . . . . . . . . . . . . . . . 22
4.3.1. Device Classification . . . . . . . . . . . . . . . . 21 4.3.1. Device Classification . . . . . . . . . . . . . . . . 22
4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 22 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23
4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 23 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24
4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 23 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24
4.3.5. Device/Service-Specific Additional Data Structure . . 24 4.3.5. Device/Service-Specific Additional Data Structure . . 25
4.3.6. Device/Service Specific Additional Data Structure 4.3.6. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 24 Type . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.7. Issues with getting new types of data into use . . . 25 4.3.7. Issues with getting new types of data into use . . . 26
4.3.8. Choosing between defining a new type of block or new 4.3.8. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 26 type of device/service specific additional data . . . 27
4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 27 4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28
4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 27 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28
4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 27 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28
4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 28 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29
4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 28 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 29
4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 31 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 31 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32
5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 31 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 32
5.1. Transmitting Blocks using the Call-Info Header . . . . . 33 5.1. Transmitting Blocks using the Call-Info Header . . . . . 34
5.2. Transmitting Blocks by Reference using the <provided-by> 5.2. Transmitting Blocks by Reference using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 35 Element . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4. The Content-Disposition Parameter . . . . . . . . . . . . 37 5.3. Transmitting Blocks by Value using the <provided-by>
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Element . . . . . . . . . . . . . . . . . . . . . . . . . 36
7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38
7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 51 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 53 7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 54 7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52
7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 56 7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54
7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 57 7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55
7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 58 7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 57
8. Security Considerations . . . . . . . . . . . . . . . . . . . 60 7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 58
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 62 7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 59
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
10.1. Registry creation . . . . . . . . . . . . . . . . . . . 65 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 63
10.1.1. Provider ID Series Registry . . . . . . . . . . . . 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
10.1.2. Service Environment Registry . . . . . . . . . . . . 65 10.1. Registry creation . . . . . . . . . . . . . . . . . . . 66
10.1.3. Service Type Registry . . . . . . . . . . . . . . . 66 10.1.1. Provider ID Series Registry . . . . . . . . . . . . 66
10.1.4. Service Mobility Registry . . . . . . . . . . . . . 66 10.1.2. Service Environment Registry . . . . . . . . . . . . 66
10.1.5. Service Provider Type Registry . . . . . . . . . . . 67 10.1.3. Service Type Registry . . . . . . . . . . . . . . . 67
10.1.6. Device Classification Registry . . . . . . . . . . . 67 10.1.4. Service Mobility Registry . . . . . . . . . . . . . 67
10.1.7. Device ID Type Type Registry . . . . . . . . . . . . 67 10.1.5. Service Provider Type Registry . . . . . . . . . . . 68
10.1.8. Device/Service Data Type Registry . . . . . . . . . 68 10.1.6. Device Classification Registry . . . . . . . . . . . 68
10.1.9. Emergency Call Data Types Registry . . . . . . . . . 68 10.1.7. Device ID Type Type Registry . . . . . . . . . . . . 68
10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 69 10.1.8. Device/Service Data Type Registry . . . . . . . . . 69
10.1.9. Emergency Call Data Types Registry . . . . . . . . . 69
10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 70
10.3. URN Sub-Namespace Registration for <provided-by> 10.3. URN Sub-Namespace Registration for <provided-by>
Registry Entry . . . . . . . . . . . . . . . . . . . . . 70 Registry Entry . . . . . . . . . . . . . . . . . . . . . 71
10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 70 10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 71
10.4.1. MIME Content-type Registration for 10.4.1. MIME Content-type Registration for
'application/EmergencyCallData.ProviderInfo+xml' . . 70 'application/EmergencyCallData.ProviderInfo+xml' . . 71
10.4.2. MIME Content-type Registration for 10.4.2. MIME Content-type Registration for
'application/EmergencyCallData.ServiceInfo+xml' . . 71 'application/EmergencyCallData.ServiceInfo+xml' . . 72
10.4.3. MIME Content-type Registration for 10.4.3. MIME Content-type Registration for
'application/EmergencyCallData.DeviceInfo+xml' . . . 72 'application/EmergencyCallData.DeviceInfo+xml' . . . 73
10.4.4. MIME Content-type Registration for 10.4.4. MIME Content-type Registration for
'application/EmergencyCallData.SubscriberInfo+xml' . 73 'application/EmergencyCallData.SubscriberInfo+xml' . 74
10.4.5. MIME Content-type Registration for 10.4.5. MIME Content-type Registration for
'application/EmergencyCallData.Comment+xml' . . . . 74 'application/EmergencyCallData.Comment+xml' . . . . 75
10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 75 10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 76
10.5.1. Registration for 10.5.1. Registration for
urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 75 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 76
10.5.2. Registration for 10.5.2. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf
o . . . . . . . . . . . . . . . . . . . . . . . . . 76 o . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.5.3. Registration for 10.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 77 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 78
10.5.4. Registration for 10.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 78 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 79
10.5.5. Registration for 10.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI
nfo . . . . . . . . . . . . . . . . . . . . . . . . 79 nfo . . . . . . . . . . . . . . . . . . . . . . . . 80
10.5.6. Registration for 10.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 80 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 81
10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 81 10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 82
10.7. VCard Parameter Value Registration . . . . . . . . . . . 82 10.7. VCard Parameter Value Registration . . . . . . . . . . . 83
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
12.1. Normative References . . . . . . . . . . . . . . . . . . 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 84
12.2. Informational References . . . . . . . . . . . . . . . . 84 12.2. Informational References . . . . . . . . . . . . . . . . 85
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 85 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 87
Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 108 Appendix B. XML Validation . . . . . . . . . . . . . . . . . . . 109
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109
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 4, line 49 skipping to change at page 4, line 45
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
information that is useful for a PSAP when handling an emergency. information that is useful for a PSAP when handling an emergency.
This document extends the basic set of data communicated with an IP- This document extends the basic set of data communicated with an IP-
based emergency call, as described in [RFC6443] and [RFC6881], in based emergency call, as described in [RFC6443] and [RFC6881], in
order to carry additional data which is useful to an entity or call order to carry additional data which is useful to an entity or call
taker handling the call. This data is "additional" to the basic taker handling the call. This data is "additional" to the basic
information found in the emergency call signaling used. The intent information found in the emergency call signaling used. The intent
is that every emergency call carry the information described here is that every emergency call carry the information described here
using the mechanisms described here. using the mechanisms described here.
In general, there are three categories of this additional data that This document defines three categories of this additional data that
may be transmitted with an emergency call: can be transmitted with an emergency call:
Data Associated with a Location: Primary location data is conveyed Data Associated with a Location: Primary location data is conveyed
in the Presence Information Data Format Location Object (PIDF-LO) in the Presence Information Data Format Location Object (PIDF-LO)
data structure as defined in RFC 4119 [RFC4119] and extended by data structure as defined in RFC 4119 [RFC4119] and extended by
RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location
information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for
geodetic location information), and [RFC7035] (for relative geodetic location information), and [RFC7035] (for relative
location). This primary location data identifies the location or location). This primary location data identifies the location or
estimated location of the caller. However, there may exist estimated location of the caller. However, there may exist
additional, secondary data which is specific to the location, such additional, secondary data which is specific to the location, such
skipping to change at page 5, line 32 skipping to change at page 5, line 28
ventilation and air conditioning (HVAC) status, etc. Such ventilation and air conditioning (HVAC) status, etc. Such
secondary location data is not included in the location data secondary location data is not included in the location data
structure but can be transmitted using the mechanisms defined in structure but can be transmitted using the mechanisms defined in
this document. Although this document does not define any this document. Although this document does not define any
structures for such data, future documents may do so following the structures for such data, future documents may do so following the
procedures defined here. procedures defined here.
Data Associated with a Call: While some information is carried in Data Associated with a Call: While some information is carried in
the call setup procedure itself (as part of the SIP headers as the call setup procedure itself (as part of the SIP headers as
well as in the body of the SIP message), there is additional data well as in the body of the SIP message), there is additional data
known by the device making the call and/or a service provider known by the device making the call, the access network to which
along the path of the call. This information may include the the device is connected, and service providers along the path of
service provider contact information, subscriber identity and the call. This information includes service provider contact
contact information, the type of service the service provider and information, subscriber identity and contact information, the type
the access network provider offer, what type of device is being of service the service provider and the access network provide,
used, etc. Some data is broadly applicable, while other data is what type of device is being used, etc. Some data is broadly
dependent on the type of device or service. For example, a applicable, while other data is dependent on the type of device or
medical monitoring device may have sensor data. The data service. For example, a medical monitoring device may have sensor
structures defined in this document (Data Provider Information, data. The data structures defined in this document (Data Provider
Device Information, and Owner/Subscriber Information) all fall Information, Device Information, and Owner/Subscriber Information)
into the category of "Data Associated with a Call". all fall into the category of "Data Associated with a Call". Note
that the Owner/Subscriber Information includes the subscriber's
vCard, which may contain personal information such as birthday,
anniversary, etc., but the data block itself is still considered
to be about the call, not the caller.
Data Associated with a Caller: This is personal data about a caller, Data Associated with a Caller: This is personal data about a caller,
such as medical information and emergency contact data. Although such as medical information and emergency contact data. Although
this document does not define any structures within this category, this document does not define any structures within this category,
future documents may do so following the procedures defined here. future documents may do so following the procedures defined here.
While this document defines data structures only within the category While this document defines data structures only within the category
of Data Associated with a Call, by establishing the overall framework of Data Associated with a Call, by establishing the overall framework
of Additional Data, along with general mechanisms for transport of of Additional Data, along with general mechanisms for transport of
such data, extension points and procedures for future extensions, it such data, extension points and procedures for future extensions, it
skipping to change at page 7, line 35 skipping to change at page 7, line 34
defined and the name of that specification is xCard [RFC6351]. Since defined and the name of that specification is xCard [RFC6351]. Since
the term vCard is more familiar to most readers, we use the terms the term vCard is more familiar to most readers, we use the terms
xCard and vCard interchangeably. xCard and vCard interchangeably.
3. Document Scope 3. Document Scope
The scope of this document is explicitly limited to emergency calls. The scope of this document is explicitly limited to emergency calls.
The data structures defined here are not appropriate to be conveyed The data structures defined here are not appropriate to be conveyed
with non-emergency calls because they carry sensitive and private with non-emergency calls because they carry sensitive and private
data. However, in certain private-use situations where the endpoints data. However, in certain private-use situations where the endpoints
have a preexisting relationship and privacy concerns do not apply have a preexisting relationship and privacy issues are addressed
because of the relationship, the mechanisms and data structures within the relationship or do not apply because of it, the mechanisms
defined here MAY be used. and data structures defined here MAY be used.
4. Data Structures 4. Data Structures
This section defines the following five data structures, each as a This section defines the following five data structures, each as a
data block. For each block we define the MIME type, and the XML data block. For each block we define the MIME type, and the XML
encoding. The five data structures are: encoding. The five data structures are:
'Data Provider': This block supplies name and contact information 'Data Provider': This block supplies name and contact information
for the entity that created the data. Section 4.1 provides the for the entity that created the data. Section 4.1 provides the
details. details.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
<DataProviderReference> element. All blocks added by a single entity <DataProviderReference> element. All blocks added by a single entity
at the same time MUST have the same <DataProviderReference> value. at the same time MUST have the same <DataProviderReference> value.
The value of the <DataProviderReference> element has the same syntax The value of the <DataProviderReference> element has the same syntax
and properties (specifically, world-uniqueness) as the value of the and properties (specifically, world-uniqueness) as the value of the
"Message-ID" message body header field specified in RFC 5322 "Message-ID" message body header field specified in RFC 5322
[RFC5322] except that the <DataProviderReference> element is not [RFC5322] except that the <DataProviderReference> element is not
enclosed in brackets (the "<" and ">" symbols are omitted). In other enclosed in brackets (the "<" and ">" symbols are omitted). In other
words, the value of a <DataProviderReference> element is words, the value of a <DataProviderReference> element is
syntactically a msg-id as specified in RFC 5322 [RFC5322]. syntactically a msg-id as specified in RFC 5322 [RFC5322].
Each block is added to the Additional Data Blocks Registry created in
Section 10.1.9 and categorized as providing data about the caller.
New blocks added to the registry in the future MUST also be
categorized per the description of the three categories in Section 1.
See Section 4.3.7 and Section 4.3.8 for additional considerations
when 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. These numbers are useful to specify a "main" telephone number. These numbers are useful to
emergency responders who are called to a large enterprise. This emergency responders who are called to a large enterprise. This
document adds a new property value to the "tel" property of the TYPE document adds a new property value to the "tel" property of the TYPE
parameter called "main". It can be used in any xCard in additional parameter called "main". It can be used in any xCard in additional
data. data.
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, or the device. It path of the call, or the access network provider, and the device. It
includes identification and contact information. This block SHOULD includes identification and contact information. This block MUST be
be supplied by every service provider in the call path, and by the supplied by any entity that provides any other block; it SHOULD be
access network provider. Devices MAY use this block to provide supplied by every service provider in the call path and by the access
identifying information. The MIME subtype is "application/ network provider if those entities do not add any other blocks.
EmergencyCallData.ProviderInfo+xml". An access network provider Devices SHOULD use this block to provide identifying information.
SHOULD provide this block either by value or by reference in the The MIME subtype is "application/EmergencyCallData.ProviderInfo+xml".
<provided-by> element of a PIDF-LO An access network provider SHOULD provide this block either by value
or by reference in the <provided-by> element of a PIDF-LO
4.1.1. Data Provider String 4.1.1. Data Provider String
Data Element: Data Provider String Data Element: Data Provider String
Use: Required Use: Conditional
XML Element: <DataProviderString> XML Element: <DataProviderString>
Description: This is a plain text string suitable for displaying the Description: This is a plain text string suitable for displaying the
name of the service provider that supplied the data structure. If name of the service provider that supplied the data structure. If
the device creates the structure, it SHOULD use the value of the the device creates the structure, it SHOULD use the value of the
contact header in the SIP INVITE. contact header in the SIP INVITE.
Reason for Need: Inform the call taker of the identity of the entity Reason for Need: Inform the call taker of the identity of the entity
providing the data. providing the data.
skipping to change at page 16, line 50 skipping to change at page 17, line 31
</url> </url>
</vcard> </vcard>
</ad:DataProviderContact> </ad:DataProviderContact>
</ad:EmergencyCallData.ProviderInfo> </ad:EmergencyCallData.ProviderInfo>
Figure 3: EmergencyCallData.ProviderInfo Example. Figure 3: EmergencyCallData.ProviderInfo Example.
4.2. Service Information 4.2. Service Information
This block describes the service that the service provider provides This block describes the service that the service provider provides
to the caller. It SHOULD be included by all SPs in the path of the to the caller. It SHOULD be included by all service providers in the
call. The mime subtype is "application/ path of the call. The mime subtype is "application/
EmergencyCallData.ServiceInfo+xml". EmergencyCallData.ServiceInfo+xml".
4.2.1. Service Environment 4.2.1. Service Environment
Data Element: Service Environment Data Element: Service Environment
Use: Conditional: Required unless the 'ServiceType' value is Use: Conditional: Required unless the 'ServiceType' value is
'wireless'. 'wireless'.
XML Element: <ServiceEnvironment> XML Element: <ServiceEnvironment>
skipping to change at page 68, line 39 skipping to change at page 69, line 39
The initial set of values are listed in Figure 10. The initial set of values are listed in Figure 10.
10.1.9. Emergency Call Data Types Registry 10.1.9. Emergency Call Data Types Registry
This document creates a new sub-registry called 'Emergency Call Data This document creates a new sub-registry called 'Emergency Call Data
Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. Types' in the 'purpose' registry established by RFC 3261 [RFC3261].
As defined in [RFC5226], this registry operates under "Specification As defined in [RFC5226], this registry operates under "Specification
Required" rules, which include an explicit expert review. The expert Required" rules, which include an explicit expert review. The expert
is responsible for verifying that the document contains a complete is responsible for verifying that the document contains a complete
and clear specification and the proposed functionality does not and clear specification and the proposed functionality does not
obviously duplicate existing functionality. obviously duplicate existing functionality. The expert is also
responsible for verifying that the block is correctly categorized per
the description of the categories in Section 1.
The registry contains an entry for every data block that can be sent The registry contains an entry for every data block that can be sent
with an emergency call using the mechanisms as specified in this with an emergency call using the mechanisms as specified in this
document. Each data block is identified by the "root" of its MIME document. Each data block is identified by the "root" of its MIME
subtype (which is the part after 'EmergencyCallData.'). If the MIME subtype (which is the part after 'EmergencyCallData.'). If the MIME
subtype does not start with 'EmergencyCallData.', then it cannot be subtype does not start with 'EmergencyCallData.', then it cannot be
registered here nor used in a Call-Info header as specified in this registered here nor used in a Call-Info header as specified in this
document. The subtype MAY exist under any MIME type (although most document. The subtype MAY exist under any MIME type (although most
commonly these are under 'Application/' this is NOT REQUIRED), commonly these are under 'Application/' this is NOT REQUIRED),
however, to be added to the registry the "root" needs to be unique however, to be added to the registry the "root" needs to be unique
regardless of the MIME type. regardless of the MIME type.
The content of this registry includes: The content of this registry includes:
Token: The root of the data's MIME subtype (not including the Token: The root of the data's MIME subtype (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') 'EmergencyCallData' prefix and any suffix such as '+xml')
Data About: Indicates if the data describes the call, the caller, or
the location (or is applicable to all), which helps PSAPs and
other entities determine if they wish to process the block. The
value MUST be either "The Call", "The Caller", "The Location", or
"All". New values are created by extending this registry in a
subsequent RFC.
Reference: The document that describes the data object Reference: The document that describes the data object
Note that the values from this registry are part of the Note that the values from this registry are part of the
'EmergencyCallData' compound value; when used as a value of the 'EmergencyCallData' compound value; when used as a value of the
'purpose' parameter of the Call-Info header, the values listed in 'purpose' parameter of the Call-Info header, the values listed in
this registry are prefixed by 'EmergencyCallData.' per the the this registry are prefixed by 'EmergencyCallData.' per the the
'EmergencyCallData' registation Section 10.2. 'EmergencyCallData' registation Section 10.2.
The initial set of values are listed in Figure 25. The initial set of values are listed in Figure 25.
+----------------+------------+ +----------------+--------------+------------+
| Token | Reference | | Token | Data About | Reference |
+----------------+------------+ +----------------+--------------+------------+
| ProviderInfo | [This RFC] | | ProviderInfo | The Call | [This RFC] |
| ServiceInfo | [This RFC] | | ServiceInfo | The Call | [This RFC] |
| DeviceInfo | [This RFC] | | DeviceInfo | The Call | [This RFC] |
| SubscriberInfo | [This RFC] | | SubscriberInfo | The Call | [This RFC] |
| Comment | [This RFC] | | Comment | The Call | [This RFC] |
+----------------+------------+ +----------------+--------------+------------+
Figure 25: Additional Data Blocks Registry Figure 25: Additional Data Blocks Registry
10.2. 'EmergencyCallData' Purpose Parameter Value 10.2. 'EmergencyCallData' Purpose Parameter Value
This document defines the 'EmergencyCallData' value for the "purpose" This document defines the 'EmergencyCallData' value for the "purpose"
parameter of the Call-Info header field. The Call-Info header and parameter of the Call-Info header field. The Call-Info header and
the corresponding registry for the 'purpose' parameter was the corresponding registry for the 'purpose' parameter was
established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData' established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData'
is a compound value; when used as a value of the 'purpose' parameter is a compound value; when used as a value of the 'purpose' parameter
skipping to change at page 84, line 17 skipping to change at page 85, line 17
[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, RFC
6838, January 2013. 6838, January 2013.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
July 2014. July 2014.
12.2. Informational References 12.2. Informational References
[ECRIT-WG-wiki]
IETF, "ECRIT WG Wiki"", July 2015,
<http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/
WikiStart/additional-data-examples.zip>.
[I-D.gellens-slim-negotiating-human-language] [I-D.gellens-slim-negotiating-human-language]
Randy, R., "Negotiating Human Language in Real-Time Gellens, R., "Negotiating Human Language in Real-Time
Communications", draft-gellens-slim-negotiating-human- Communications", draft-gellens-slim-negotiating-human-
language-00 (work in progress), October 2014. language-01 (work in progress), April 2015.
[IANA-XML-Schemas]
IANA, "IANA XML Schemas"", July 2015,
<http://www.iana.org/assignments/xml-registry/
xml-registry.xhtml#schema>.
[LanguageTagRegistry] [LanguageTagRegistry]
IANA, "Language Subtag Registry", Feb 2015. IANA, "Language Subtag Registry", Feb 2015,
<http://www.iana.org/assignments/language-subtag-registry/
language-subtag-registry>.
[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. November 2002.
[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, August 2004.
skipping to change at page 108, line 28 skipping to change at page 109, line 38
whitespaces in the regular expressions contained in the vcard schema whitespaces in the regular expressions contained in the vcard schema
in Appendix A. To validate the PIDF-LO from Figure 18 it is also in Appendix A. To validate the PIDF-LO from Figure 18 it is also
necessary to consult the referenced RFCs and copy the schemas necessary to consult the referenced RFCs and copy the schemas
necessary for successful validation. necessary for successful validation.
The XML schemas found in this document include a 'SchemaLocation' The XML schemas found in this document include a 'SchemaLocation'
attribute. Depending on the location of the downloaded schema files attribute. Depending on the location of the downloaded schema files
you may need to adjust this schema location or configure your XML you may need to adjust this schema location or configure your XML
editor to point to the location. editor to point to the location.
For convience of readers we have put all schemas and XML examples at For convenience of readers, the schemas are available at http://ip-
http://ip-emergency.net/additional-data.zip emergency.net/additional-data.zip and the XML examples are available
at the IETF ECRIT Working Group wiki page [ECRIT-WG-wiki].
Authors' Addresses Note to RFC Editor: After IANA has published the schemas, the above
link to the schemas should be replaced with [IANA-XML-Schemas].
Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
US US
Email: rg+ietf@qti.qualcomm.com Email: rg+ietf@qti.qualcomm.com
Brian Rosen Brian Rosen
NeuStar NeuStar
 End of changes. 44 change blocks. 
141 lines changed or deleted 175 lines changed or added

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