< 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 18, line 44 ¶		skipping to change at page 19, line 4 ¶
	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".
	3.3.1. Device Classification		3.3.1. Device Classification
	Data Element: Device Classification		Data Element: Device Classification
	Use: Optional		Use: Optional
	XML Element: <DeviceClassification>		XML Element: <DeviceClassification>
	Description: This data element defines the kind of device making the		Description: This data element defines the kind of device making the
	emergency call. If the device provides the data structure, the		emergency call. If the device provides the data structure, the
	device information SHOULD be provided. If the service provider		device information SHOULD be provided. If the service provider
	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. 46 change blocks.
	149 lines changed or deleted		140 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/