draft-ietf-ecrit-additional-data-20.txt   draft-ietf-ecrit-additional-data-21.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: August 16, 2014 (no affiliation) Expires: September 9, 2014 (no affiliation)
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
R. Gellens R. Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
J. Winterbottom J. Winterbottom
(no affiliation) (no affiliation)
February 12, 2014 March 08, 2014
Additional Data related to an Emergency Call Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data-20.txt draft-ietf-ecrit-additional-data-21.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 device that sends it, as well as any application service
provider in the path of the call, or access network provider through provider in the path of the call, or access network provider through
which the call originated may have information about the call, the which the call originated may have information about the call, the
caller or the location which the PSAP may be able to use. This caller or the location which the PSAP may be able to use. This
document describes data structures and a mechanism to convey such document describes data structures and a mechanism to convey such
data to the PSAP. The mechanism uses a Uniform Resource Identifier data to the PSAP. The mechanism uses a Uniform Resource Identifier
skipping to change at page 2, line 4 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 August 16, 2014. This Internet-Draft will expire on September 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 35 skipping to change at page 2, line 35
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Data Provider Information . . . . . . . . . . . . . . . . 8 3.1. Data Provider Information . . . . . . . . . . . . . . . . 8
3.1.1. Data Provider String . . . . . . . . . . . . . . . . 8 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 8
3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8
3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 9 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 9
3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9
3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10
3.1.6. Data Provider Languages(s) Supported . . . . . . . . 11 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 11
3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11
3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12
3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 13
3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13 3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13
3.2. Service Information . . . . . . . . . . . . . . . . . . . 15 3.2. Service Information . . . . . . . . . . . . . . . . . . . 15
3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15
3.2.2. Service Delivered by Provider to End User . . . . . . 16 3.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Service Mobility Environment . . . . . . . . . . . . 17 3.2.3. Service Mobility Environment . . . . . . . . . . . . 17
3.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 18 3.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 18
3.3. Device Information . . . . . . . . . . . . . . . . . . . 18 3.3. Device Information . . . . . . . . . . . . . . . . . . . 18
3.3.1. Device Classification . . . . . . . . . . . . . . . . 18 3.3.1. Device Classification . . . . . . . . . . . . . . . . 18
3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 20 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 20
3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20
3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20
3.3.5. Device/Service Specific Additional Data Structure . . 21 3.3.5. Device/Service Specific Additional Data Structure . . 21
3.3.6. Device/Service Specific Additional Data Structure 3.3.6. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 22 Type . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.7. Issues with getting new types of data into use . . . 22 3.3.7. Issues with getting new types of data into use . . . 23
3.3.8. Choosing between defining a new type of block or new 3.3.8. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 23 type of device/service specific additional data . . . 23
3.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 24 3.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 24
3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24
3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 24 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 25
3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25
3.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 25 3.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 26
3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 28 3.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 28
4. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 28 4. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 29
4.1. Transmitting Blocks using the Call-Info Header . . . . . 30 4.1. Transmitting Blocks using the Call-Info Header . . . . . 31
4.2. Transmitting Blocks by Reference using the Provided-By 4.2. Transmitting Blocks by Reference using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 31 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Transmitting Blocks by Value using the Provided-By 4.3. Transmitting Blocks by Value using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 32 Element . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4. The Content-Disposition Parameter . . . . . . . . . . . . 32 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 33
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 45 6.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 45
6.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 47 6.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 47
6.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 48 6.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 48
6.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 49 6.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 49
6.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 50 6.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 50
6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 51 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 56 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 56
9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 56 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 56
9.1.2. Service Environment Registry . . . . . . . . . . . . 57 9.1.2. Service Environment Registry . . . . . . . . . . . . 57
9.1.3. Service Provider Type Registry . . . . . . . . . . . 57 9.1.3. Service Provider Type Registry . . . . . . . . . . . 57
9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57 9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57
9.1.5. Device Classification Registry . . . . . . . . . . . 58 9.1.5. Device Classification Registry . . . . . . . . . . . 58
9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58 9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58
9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58 9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58
skipping to change at page 4, line 15 skipping to change at page 4, line 15
9.4.5. MIME Content-type Registration for 9.4.5. MIME Content-type Registration for
'application/EmergencyCallData.Comment+xml' . . . . . 64 'application/EmergencyCallData.Comment+xml' . . . . . 64
9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65
9.5.1. Registration for 9.5.1. Registration for
urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 65 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 65
9.5.2. Registration for 9.5.2. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 66 urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo 66
9.5.3. Registration for 9.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 67 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 67
9.5.4. Registration for 9.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo . 68 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo . 67
9.5.5. Registration for 9.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberIn urn:ietf:params:xml:ns:EmergencyCallData:SubscriberIn
fo . . . . . . . . . . . . . . . . . . . . . . . . . 68 fo . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.5.6. Registration for 9.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 69 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 69
9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 70 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 69
9.7. VCard Parameter Value Registration . . . . . . . . . . . 71 9.7. VCard Parameter Value Registration . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
11.1. Normative References . . . . . . . . . . . . . . . . . . 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 71
11.2. Informational References . . . . . . . . . . . . . . . . 72 11.2. Informational References . . . . . . . . . . . . . . . . 72
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 74 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
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
skipping to change at page 6, line 41 skipping to change at page 6, line 41
term "Access Network Provider" we refer to the Internet Access term "Access Network Provider" we refer to the Internet Access
Provider (IAP) and the Internet Service Provider (ISP) without Provider (IAP) and the Internet Service Provider (ISP) without
further distinguishing these two entities, since the difference further distinguishing these two entities, since the difference
between the two is not relevant for this document. Note that the between the two is not relevant for this document. Note that the
roles of ASP and access network provider may be provided by a single roles of ASP and access network provider may be provided by a single
company. company.
Within each data block definition (see Section 3), the values for the Within each data block definition (see Section 3), the values for the
"Use:" label are specified as one of the following: "Use:" label are specified as one of the following:
'Required': means they MUST be present in the data structure. 'Required': means it MUST be present in the data structure.
'Conditional': means they MUST be present if the specified 'Conditional': means it MUST be present if the specified
condition(s) is met. They MAY be present if the condition(s) is condition(s) is met. It MAY be present if the condition(s) is not
not met. met.
'Optional': means they MAY be present. 'Optional': means it MAY be present.
vCard is a data format for representing and exchanging a variety of vCard is a data format for representing and exchanging a variety of
information about individuals and other entities. For applications information about individuals and other entities. For applications
that use XML the format defined in vCard is not immediately that use XML the format defined in vCard is not immediately
applicable. For this purpose an XML-based encoding of the applicable. For this purpose an XML-based encoding of the
information elements defined in the vCard specification has been information elements defined in the vCard specification has been
defined and the name of that specification is xCard. Since the term defined and the name of that specification is xCard. Since the term
vCard is more familiar to most readers, we use the term xCard and vCard is more familiar to most readers, we use the term xCard and
vCard interchangeably. vCard interchangeably.
skipping to change at page 10, line 12 skipping to change at page 10, line 12
XML Element: <TypeOfProviderID> XML Element: <TypeOfProviderID>
Description: Identifies the type of data provider ID being supplied Description: Identifies the type of data provider ID being supplied
in the ProviderID data element. A registry with an initial set of in the ProviderID data element. A registry with an initial set of
values is shown in Figure 1 (see also Section 9.1). values is shown in Figure 1 (see also Section 9.1).
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Token | Description | | Token | Description |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
|Access Network Provider | Access network service provider | |Access Network Provider | Access network service provider |
|Service Provider | Calling or Origination telecom SP | |Telecom Provider | Calling or origination telecom SP |
|Subcontractor | A contractor to another SP | |Telematics Provider | A sensor based service provider, |
|Telematics Provider | A sensor based SP, especially | | | especially vehicle based |
| | vehicle based |
|Language Translation Provider | A spoken language translation SP | |Language Translation Provider | A spoken language translation SP |
|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 SP, for example, | |Relay Provider | A interpretation SP, for example, |
| | video relay for sign language | | | video relay for sign language |
| | interpreting | | | interpreting |
|Other | Any other type of service provider | |Other | Any other type of service provider |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Figure 1: Type of Data Provider ID Registry. Figure 1: Type of Data Provider ID Registry.
Reason for Need: Identifies the category of data provider. Reason for Need: Identifies the category of data provider.
How Used by Call Taker: This information may be helpful when How Used by Call Taker: This information may be helpful when
deciding whom to contact when further information is needed. deciding whom to contact when further information is needed.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
Reason for Need: Information needed to determine additional contact Reason for Need: Information needed to determine additional contact
information. information.
How Used by Call Taker: Assists call taker by providing additional How Used by Call Taker: Assists call taker by providing additional
contact information that may not be included in the SIP invite or contact information that may not be included in the SIP invite or
the PIDF-LO. the PIDF-LO.
3.1.8. Subcontractor Principal 3.1.8. Subcontractor Principal
When the entity providing the data is a subcontractor, the Data
Provider Type is set to that of the primary service provider and this
entry is supplied to provide information regarding the subcontracting
entity.
Data Element: Subcontractor Principal Data Element: Subcontractor Principal
Use: Conditional. This data is required if the Data Provider type Use: Conditional. This data is required if the entity providing the
is subcontractor. data is a subcontractor.
XML Element: <SubcontratorPrincipal> XML Element: <SubcontratorPrincipal>
Description: Some providers outsource their obligations to handle Description: Some providers outsource their obligations to handle
aspects of emergency services to specialized providers. If the aspects of emergency services to specialized providers. If the
data provider is a subcontractor to another provider this element data provider is a subcontractor to another provider this element
contains the DataProviderString of the service provider to contains the DataProviderString of the service provider to
indicate which provider the subcontractor is working for. indicate which provider the subcontractor is working for.
Reason for Need: Identify the entity the subcontractor works for. Reason for Need: Identify the entity the subcontractor works for.
skipping to change at page 15, line 34 skipping to change at page 15, line 43
to the caller. It SHOULD be included by all SPs in the path of the to the caller. It SHOULD be included by all SPs in the path of the
call. The mime subtype is "application/ call. The mime subtype is "application/
EmergencyCallData.ServiceInfo+xml". EmergencyCallData.ServiceInfo+xml".
3.2.1. Service Environment 3.2.1. Service Environment
Data Element: Service Environment Data Element: Service Environment
Use: Required Use: Required
XML Element: <SvcEnvironment> XML Element: <ServiceEnvironment>
Description: This element defines whether a call is from a business Description: This element defines whether a call is from a business
or residence caller. Currently, the only valid entries are or residence caller. Currently, the only valid entries are
'Business' or 'Residence'. New values can be defined via the 'Business' or 'Residence'. New values can be defined via the
registry created in Figure 22. registry created in Figure 22.
Reason for Need: To assist in determining equipment and manpower Reason for Need: To assist in determining equipment and manpower
requirements. requirements.
How Used by Call Taker: Information may be used to assist in How Used by Call Taker: Information may be used to assist in
skipping to change at page 16, line 8 skipping to change at page 16, line 17
responders. As the information is not always available, and the responders. As the information is not always available, and the
registry is not all encompassing, this is at best advisory registry is not all encompassing, this is at best advisory
information, but since it mimics a similar capability in some information, but since it mimics a similar capability in some
current emergency calling systems, it is known to be valuable. current emergency calling systems, it is known to be valuable.
The service provider uses its best information (such as a rate The service provider uses its best information (such as a rate
plan, facilities used to deliver service or service description) plan, facilities used to deliver service or service description)
to determine the information and is not responsible for to determine the information and is not responsible for
determining the actual characteristics of the location where the determining the actual characteristics of the location where the
call originates from. call originates from.
3.2.2. Service Delivered by Provider to End User 3.2.2. Service Type
Data Element: Service Delivered by Provider to End User Data Element: Service Delivered by Provider to End User
Use: Required Use: Required
XML Element: <SvcDelByProvider> XML Element: <ServiceType>
Description: This defines the type of service the end user has Description: This defines the type of service over which the call is
subscribed to. The implied mobility of this service cannot be placed. The implied mobility of this service cannot be relied
relied upon. A registry with an initial set of values is defined upon. A registry with an initial set of values is defined in
in Figure 3. Figure 3.
+--------+----------------------------------------+ +--------------+----------------------------------------+
| Name | Description | | Name | Description |
+--------+----------------------------------------+ +--------------+----------------------------------------+
| Wrless | Wireless Telephone Service: Includes | | wireless | Wireless Telephone Service: Includes |
| | Satellite, CDMA, GSM, Wi-Fi, WiMAX, | | | CDMA, GSM, Wi-Fi, WiMAX, LTE (but |
| | LTE (Long Term Evolution) | | | not satellite ) |
| Coin | Fixed Public Pay/Coin telephones: Any | | coin | Fixed public pay/coin telephones: Any |
| | coin or credit card operated device | | | coin or credit card operated device |
| 1way | One way outbound service | | one-way | One way outbound service |
| Prison | Inmate call/service | | prison | Inmate call/service |
| Temp | Soft dialtone/quick service/warm | | temp | Soft dialtone/quick service/warm |
| | disconnect/suspended | | | disconnect/suspended |
| MLTS | Multi-line telephone system: Includes | | MLTS | Multi-line telephone system: Includes |
| | all PBX, Centrex, key systems, | | | all PBX, Centrex, key systems, |
| | Shared Tenant Service | | | Shared Tenant Service |
| SenseU | Sensor, unattended: Includes devices | | sensor- |
| | that generate DATA ONLY. This is | | unattended | These are devices that generate DATA |
| | one-way information exchange and | | | ONLY. This is a one-way information |
| | there will be no other form of | | | transmit without interactive media |
| | communication | | sensor- | |
| SenseA | Sensor, attended: Includes devices | | attended | Devices that are supported by a |
| | that are supported by a monitoring | | | monitoring service provider or that |
| | service provider or automatically | | | are capable of supporting interactive|
| | open a two-way communication path | | | media |
| POTS | Wireline: Plain Old Telephone Service | | POTS | Wireline: Plain Old Telephone Service |
| VOIP | VoIP Telephone Service: A type of | | VOIP | An over-the-top service that provides |
| | service that offers communication | | | communication over arbitrary Internet|
| | over internet protocol, such as Fixed| | | access (fixed, nomadic, mobile) |
| | Nomadic, Mobile, ... | | remote | Off premise extension |
| Remote | Off premise extension | | relay | A service where there is a human third |
| Relay | Relay Service: a type of service where | | | party agent who provides additional |
| | there is a human 3rd party agent who | | | assistance. This includes sign |
| | provides some kind of additional | | | language relay and telematics |
| | assistance to the caller. Includes | | | services that provide a human on the |
| | sign language relay and telematics | | | call. |
| | services which provide a service | +--------------+----------------------------------------+
| | assistant on the call. |
+--------+----------------------------------------+
Figure 3: Service Delivered by Provider to End User Registry. Figure 3: Service Delivered by Provider to End User Registry.
More than one value MAY be returned. For example, a VoIP inmate More than one value MAY be returned. For example, a VoIP inmate
telephone service is a reasonable combination. telephone service is a reasonable combination.
Reason for Need: Knowing the type of service may assist the PSAP Reason for Need: Knowing the type of service may assist the PSAP
with the handling of the call. with the handling of the call.
How Used by Call Taker: Call takers often use this information to How Used by Call Taker: Call takers often use this information to
skipping to change at page 17, line 35 skipping to change at page 17, line 41
encompassing, this is at best advisory information, but since it encompassing, this is at best advisory information, but since it
mimics a similar capability in some current emergency calling mimics a similar capability in some current emergency calling
systems, it is known to be valuable. systems, it is known to be valuable.
3.2.3. Service Mobility Environment 3.2.3. Service Mobility Environment
Data Element: Service Mobility Environment Data Element: Service Mobility Environment
Use: Required Use: Required
XML Element: <SvcMobility> XML Element: <ServiceMobility>
Description: This provides the service providers view of the Description: This provides the service provider's view of the
mobility of the caller. As the service provider may not know the mobility of the caller. As the service provider may not know the
characteristics of the actual access network used, the value not characteristics of the actual device or access network used, the
be relied upon. A registry will reflect the following initial value MUST NOT be relied upon. A registry reflects the following
valid entries: initial valid entries:
* Mobile: the device should be able to move at any time * Mobile: the device should be able to move at any time
* Fixed: the device is not expected to move unless the service is * Fixed: the device is not expected to move unless the service is
relocated relocated
* Nomadic: the device is not expected to change its point of * Nomadic: the device is not expected to change its point of
attachment while on a call attachment while on a call
* Unknown: no information is known about the service mobility * Unknown: no information is known about the service mobility
environment for the device environment for the device
Reason for Need: Knowing the service provider's belief of mobility Reason for Need: Knowing the service provider's belief of mobility
skipping to change at page 18, line 23 skipping to change at page 18, line 28
3.2.4. EmergencyCallData.ServiceInfo Example 3.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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:DataProviderReference>string0987654321@example.org <svc:DataProviderReference>string0987654321@example.org
</svc:DataProviderReference> </svc:DataProviderReference>
<svc:id>12345</svc:id> <svc:id>12345</svc:id>
<svc:SvcEnvironment>Business</svc:SvcEnvironment> <svc:ServiceEnvironment>Business</svc:ServiceEnvironment>
<svc:SvcDelByProvider>MLTS</svc:SvcDelByProvider> <svc:ServiceType>MLTS</svc:ServiceType>
<svc:SvcMobility>Fixed</svc:SvcMobility> <svc:ServiceMobility>Fixed</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo> </svc:EmergencyCallData.ServiceInfo>
Figure 4: EmergencyCallData.ServiceInfo Example. Figure 4: EmergencyCallData.ServiceInfo Example.
3.3. Device Information 3.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 subtype is device is being used, and by the device itself. The mime subtype is
"application/EmergencyCallData.DeviceInfo+xml". "application/EmergencyCallData.DeviceInfo+xml".
skipping to change at page 19, line 10 skipping to change at page 19, line 17
provides the structure and it knows what the device is, the provides the structure and it knows what the device is, the
service provider SHOULD provide the device information. Often the service provider SHOULD provide the device information. Often the
carrier does not know what the device is. It is possible to carrier does not know what the device is. It is possible to
receive two Additional Data Associated with a Call data receive two Additional Data Associated with a Call data
structures, one created by the device and one created by the structures, one created by the device and one created by the
service provider. This information describes the device, not how service provider. This information describes the device, not how
it is being used. This data element defines the kind of device it is being used. This data element defines the kind of device
making the emergency call. The registry with the initial set of making the emergency call. The registry with the initial set of
values is shown in Figure 5. values is shown in Figure 5.
+--------+----------------------------------------+ +---------------+----------------------------------------+
| Token | Description | | Token | Description |
+--------+----------------------------------------+ +---------------+----------------------------------------+
|Cordless| Cordless handset | |cordless | Cordless handset |
| Fixed | Fixed phone | |fixed | Fixed phone |
| Mobile | Mobile handset | |satellite | Satellite phone |
| ATA | analog terminal adapter | |sensor-fixed | Fixed (non mobile) sensor/alarm device |
|Satphone| Satellite phone | |desktop | Desktop PC |
| FSense | Stationary computing device (alarm | |laptop | Laptop computing device |
| | system, data sensor) | |tablet | Tablet computing device |
| Guard | Guardian devices | |alarm-monitored| Alarm system |
| Desktop| Desktop PC | |sensor-mobile | Mobile sensor device |
| Laptop | Laptop computing device | |automobile | Automobile telematics |
| Tablet | Tablet computing device | |truck | Truck telematics |
| Alarm | Alarm system | |farm | Farm equipment telematics |
| MSense | Mobile Data sensor | |marine | Marine telematics |
| Beacon | Personal beacons (spot) | |personal | Personal telematics device |
| Auto | Auto telematics | |feature-phone | Feature (not smart-) cellular phone |
| Truck | Truck telematics | |smart-phone | Smart-phone cellular phone |
| Farm | Farm equipment telematics | |game | Gaming console |
| Marine | Marine telematics | |text-only | Other text device |
| PDA | Personal digital assistant | |NA | Not Available |
| PND | Personal navigation device) | +---------------+----------------------------------------+
| SmrtPhn| Smart phone |
| Itab | Internet tablet |
| Game | Gaming console |
| Video | Video phone |
| Text | Other text device |
|SoftPhn | Soft phone or soft client software |
| NA | Not Available |
+--------+----------------------------------------+
Figure 5: Device Classification Registry. Figure 5: Device Classification Registry.
Reason for Need: The device classification implies the capability of Reason for Need: The device classification implies the capability of
the calling device and assists in identifying the meaning of the the calling device and assists in identifying the meaning of the
emergency call location information that is being presented. For emergency call location information that is being presented. For
example, does the device require human intervention to initiate a example, does the device require human intervention to initiate a
call or is this call the result of programmed instructions? Does call or is this call the result of programmed instructions? Does
the calling device have the ability to update location or the calling device have the ability to update location or
condition changes? Is this device interactive or a one-way condition changes? Is this device interactive or a one-way
skipping to change at page 21, line 4 skipping to change at page 21, line 4
3.3.4. Unique Device Identifier 3.3.4. Unique Device Identifier
Data Element: Unique Device Identifier Data Element: Unique Device Identifier
Use: Optional Use: Optional
XML Element: <UniqueDeviceID> XML Element: <UniqueDeviceID>
XML Attribute: <TypeOfDeviceID> XML Attribute: <TypeOfDeviceID>
Description: A string that identifies the specific device making the Description: A string that identifies the specific device (or the
call or creating an event. device's current SIM) making the call or creating an event. Note
that more than one <UniqueDeviceID> may be present, to supply more
than one of the identifying values.
The <TypeOfDeviceID> attribute identifies the type of device The <TypeOfDeviceID> attribute identifies the type of device
identifier. A registry with an initial set of values can be seen identifier. A registry with an initial set of values can be seen
in Figure 6. in Figure 6.
+--------+----------------------------------------+ +--------+------------------------------------------+
| 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) |
| UDI | Unique Device Identifier | | IMSI | International Mobile Subscriber ID (GSM) |
| RFID | Radio Frequency Identification | | UDI | Unique Device Identifier |
| SN | Manufacturer Serial Number | | RFID | Radio Frequency Identification |
+--------+----------------------------------------+ | SN | Manufacturer Serial Number |
+--------+------------------------------------------+
Figure 6: Registry with Device Identifier Types. Figure 6: Registry with Device Identifier Types.
Reason for Need: Uniquely identifies the device (independent of any Reason for Need: Uniquely identifies the device (or, in the case of
signaling identifiers present in the call signaling stream). IMSI, a SIM), independent of any signaling identifiers present in
the call signaling stream.
How Used by Call Taker: Probably not used by the call taker; may be How Used by Call Taker: Probably not used by the call taker; may be
used by PSAP management during an investigation. used by PSAP management during an investigation.
Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID> Example: <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID>
3.3.5. Device/Service Specific Additional Data Structure 3.3.5. Device/Service Specific Additional Data Structure
Data Element: Device/service specific additional data structure Data Element: Device/service specific additional data structure
skipping to change at page 22, line 27 skipping to change at page 22, line 37
additional URI is provided additional URI is provided
XML Element: <DeviceSpecificType> XML Element: <DeviceSpecificType>
Description: Value from a registry defined by this document to Description: Value from a registry defined by this document to
describe the type of data that can be retrieved from the device/ describe the type of data that can be retrieved from the device/
service specific additional data structure. Initial values are: service specific additional data structure. Initial values are:
* IEEE 1512 * IEEE 1512
* VEDS IEEE 1512 is the USDoT model for traffic incidents.
IEEE 1512 is the USDoT model for traffic incidents and VEDS
provides data elements needed for an efficient emergency response
to vehicular emergency incidents.
Reason for Need: This data element allows identification of Reason for Need: This data element allows identification of
externally defined schemas, which may have additional data that externally defined schemas, which may have additional data that
may assist in emergency response. may assist in emergency response.
How Used by Call Taker: This data element allows the end user How Used by Call Taker: This data element allows the end user
(calltaker or first responder) to know what type of additional (calltaker or first responder) to know what type of additional
data may be available to aid in providing the needed emergency data may be available to aid in providing the needed emergency
services. services.
skipping to change at page 41, line 32 skipping to change at page 41, line 44
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="urn:ietf:params:xml:ns:EmergencyCallData.ServiceInfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:DataProviderReference>string0987654321@example.org <svc:DataProviderReference>string0987654321@example.org
</svc:DataProviderReference> </svc:DataProviderReference>
<svc:SvcEnvironment>Residence</svc:SvcEnvironment> <svc:ServiceEnvironment>Residence</svc:ServiceEnvironment>
<svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider> <svc:ServiceType>VOIP</svc:ServiceType>
<svc:SvcMobility>Unknown</svc:SvcMobility> <svc:ServiceMobility>Unknown</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo> </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="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo" xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
skipping to change at page 47, line 26 skipping to change at page 47, line 38
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="EmergencyCallData.ServiceInfo" type="svc:ServiceInfoType"/> <xs:element name="EmergencyCallData.ServiceInfo" type="svc:ServiceInfoType"/>
<xs:complexType name="ServiceInfoType"> <xs:complexType name="ServiceInfoType">
<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="SvcEnvironment" <xs:element name="ServiceEnvironment"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SvcDelByProvider" <xs:element name="ServiceType"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SvcMobility" <xs:element name="ServiceMobility"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Link" <xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<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 16: EmergencyCallData.ServiceInfo XML Schema. Figure 16: EmergencyCallData.ServiceInfo XML Schema.
6.3. EmergencyCallData.DeviceInfo XML Schema 6.3. EmergencyCallData.DeviceInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 57, line 15 skipping to change at page 57, line 18
9.1.2. Service Environment Registry 9.1.2. Service Environment Registry
This document creates a new sub-registry called 'Additional Call This document creates a new sub-registry called 'Additional Call
Service Environment'. As defined in [RFC5226], this registry Service Environment'. As defined in [RFC5226], this registry
operates under "Expert Review" rules. The expert should determine operates under "Expert Review" rules. The expert should determine
that the entity requesting a new value is relevant for this service that the entity requesting a new value is relevant for this service
element. element.
The content of this registry includes: The content of this registry includes:
Token: The value to be used in <SvcEnvironment> element. Token: The value to be used in <ServiceEnvironment> element.
Description: A short description of the token. Description: A short description of the token.
The initial set of values is listed in Figure 22. The initial set of values is listed in Figure 22.
+-----------+--------------------------+ +-----------+--------------------------+
| Token | Description | | Token | Description |
+-----------+--------------------------+ +-----------+--------------------------+
| Business | [[This RFC]] | | Business | [[This RFC]] |
| Residence | [[This RFC]] | | Residence | [[This RFC]] |
skipping to change at page 59, line 22 skipping to change at page 59, line 28
Specification: Citation for the specification of the data. Specification: Citation for the specification of the data.
The initial set of values are listed in Figure 23. The initial set of values are listed in Figure 23.
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| Token | Description | Specification | | Token | Description | Specification |
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 |
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS |
+---------+----------------------------------------+----------------+
Figure 23: Device/Service Data Type Registry. Figure 23: Device/Service Data Type Registry.
9.1.8. Additional Data Blocks Registry 9.1.8. Additional Data Blocks Registry
This document creates a new sub-registry called 'Additional Data This document creates a new sub-registry called 'Additional Data
Blocks' in the purpose registry established by RFC 3261 [RFC3261]. Blocks' in the purpose registry established by RFC 3261 [RFC3261].
As defined in [RFC5226], this registry operates under "Expert Review" As defined in [RFC5226], this registry operates under "Expert Review"
and "Specification Required" rules. The expert is responsible for and "Specification Required" rules. The expert is responsible for
verifying that the document contains a complete and clear verifying that the document contains a complete and clear
 End of changes. 45 change blocks. 
148 lines changed or deleted 140 lines changed or added

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