< draft-ietf-ecrit-additional-data-09.txt		draft-ietf-ecrit-additional-data-10.txt >
	ECRIT B.R. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: November 29, 2013 Nokia Siemens Networks		Expires: January 16, 2014 Nokia Siemens Networks
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	R. Gellens		R. Gellens
	Qualcomm Technologies, Inc.		Qualcomm Technologies, Inc.
	May 28, 2013		J. Winterbottom
			July 15, 2013
	Additional Data related to an Emergency Call		Additional Data related to an Emergency Call
	draft-ietf-ecrit-additional-data-09.txt		draft-ietf-ecrit-additional-data-10.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 or the		which the call originated may have information about the call, the
	caller which the PSAP may be able to use. This document describes		caller or the location which the PSAP may be able to use. This
	data structures and a mechanism to convey such data to the PSAP. The		document describes data structures and a mechanism to convey such
	mechanism uses a Uniform Resource Identifier (URI), which may point		data to the PSAP. The mechanism uses a Uniform Resource Identifier
	to either an external resource or an object in the body of the SIP		(URI), which may point to either an external resource or an object in
	message. The mechanism thus allows the data to be passed by		the body of the SIP message. The mechanism thus allows the data to
	reference (when the URI points to an external resource) or by value		be passed by reference (when the URI points to an external resource)
	(when it points into the body of the message). This follows the		or by value (when it points into the body of the message). This
	tradition of prior emergency services standardization work where data		follows the tradition of prior emergency services standardization
	can be conveyed by value within the call signaling (i.e., in body of		work where data can be conveyed by value within the call signaling
	the SIP message) and also by reference.		(i.e., in body of the SIP message) and also by reference.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on January 16, 2014.
	This Internet-Draft will expire on November 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 27 ¶		skipping to change at page 2, line 28 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6		3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Data Provider Information . . . . . . . . . . . . . . . . 7		3.1. Data Provider Information . . . . . . . . . . . . . . . . 7
	3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7		3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7
	3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 7		3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8
	3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8		3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8
	3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 8		3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9
	3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9		3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9
	3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10		3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10
	3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10		3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10
	3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11		3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11
	3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12		3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 11
	3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12		3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12
	3.2. Service Information . . . . . . . . . . . . . . . . . . . 14		3.2. Service Information . . . . . . . . . . . . . . . . . . . 14
	3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14		3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14
	3.2.2. Service Delivered by Provider to End User . . . . . . 15		3.2.2. Service Delivered by Provider to End User . . . . . . 15
	3.2.3. Service Mobility Environment . . . . . . . . . . . . 16		3.2.3. Service Mobility Environment . . . . . . . . . . . . 16
	3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17		3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17
	3.3. Device Information . . . . . . . . . . . . . . . . . . . 17		3.3. Device Information . . . . . . . . . . . . . . . . . . . 17
	3.3.1. Device Classification . . . . . . . . . . . . . . . . 18		3.3.1. Device Classification . . . . . . . . . . . . . . . . 17
	3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19		3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 18
	3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20		3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19
	3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20		3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 19
	3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 21		3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 19
	3.3.6. Device/Service Specific Additional Data Structure . . 21		3.3.6. Device/Service Specific Additional Data Structure . . 20
	3.3.7. Device/Service Specific Additional Data Structure		3.3.7. Device/Service Specific Additional Data Structure
	Type . . . . . . . . . . . . . . . . . . . . . . . . 22		Type . . . . . . . . . . . . . . . . . . . . . . . . 21
	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 . . . 21
	3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 23		3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22
			3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 22
	3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24		3.4.1. xCard for Subscriber's Data . . . . . . . . . . . . . 22
	3.4.1. xCard for Subscriber's Data . . . . . . . . . . . . . 24		3.4.2. emergencyCall.SubInfo Example . . . . . . . . . . . . 23
	3.4.2. emergencyCall.SubInfo Example . . . . . . . . . . . . 24		3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 27		3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 25
	3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27		3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 26
	3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27		4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27		4.1. Transmitting Blocks using the Call-Info Header . . . . . 28
	4.1. Transmitting Blocks using the Call-Info Header . . . . . 29
	4.2. Transmitting Blocks by Reference using the Provided-By		4.2. Transmitting Blocks by Reference using the Provided-By
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 30		Element . . . . . . . . . . . . . . . . . . . . . . . . . 28
	4.3. Transmitting Blocks by Value using the Provided-By		4.3. Transmitting Blocks by Value using the Provided-By
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 31		Element . . . . . . . . . . . . . . . . . . . . . . . . . 29
			4.4. The Content-Disposition Parameter . . . . . . . . . . . . 30
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 33		6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 34
	6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 33		6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 34
	6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 34		6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 36
	6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 35		6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 36
	6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 36		6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 37
	6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 37		6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 38
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 37		6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 39
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39		7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
	9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 39		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
	9.1.1. Additional Call Data Provider ID Series Registry . . 39		9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 44
	9.1.2. Additional Call Data Service Provider Type Registry . 40		9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 44
	9.1.3. Additional Call Data Service Delivered Registry . . . 40		9.1.2. Service Provider Type Registry . . . . . . . . . . . 45
	9.1.4. Additional Call Data Device Classification Registry . 40		9.1.3. Service Delivered Registry . . . . . . . . . . . . . 45
	9.1.5. Additional Call Data Device ID Type Type Registry . . 41		9.1.4. Device Classification Registry . . . . . . . . . . . 45
	9.1.6. Device/Service Specific Additional Data Type Registry 41		9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 46
	9.1.7. Additional Call Data Blocks Registry . . . . . . . . 42		9.1.6. Device/Service Data Type Registry . . . . . . . . . . 46
	9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 42		9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 47
			9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 47
	9.3. URN Sub-Namespace Registration for provided-by Registry		9.3. URN Sub-Namespace Registration for provided-by Registry
	Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 43		Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	9.3.1. Provided-By XML Schema . . . . . . . . . . . . . . . 43		9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 48
	9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 44
	9.4.1. MIME Content-type Registration for		9.4.1. MIME Content-type Registration for
	'application/emergencyCall.ProviderInfo+xml' . . . . 45		'application/emergencyCall.ProviderInfo+xml' . . . . 48
	9.4.2. MIME Content-type Registration for		9.4.2. MIME Content-type Registration for
	'application/emergencyCall.SvcInfo+xml' . . . . . . . 46		'application/emergencyCall.SvcInfo+xml' . . . . . . . 49
	9.4.3. MIME Content-type Registration for		9.4.3. MIME Content-type Registration for
	'application/emergencyCall.DevInfo+xml' . . . . . . . 47		'application/emergencyCall.DevInfo+xml' . . . . . . . 50
	9.4.4. MIME Content-type Registration for		9.4.4. MIME Content-type Registration for
	'application/emergencyCall.SubInfo+xml' . . . . . . . 48		'application/emergencyCall.SubInfo+xml' . . . . . . . 51
	9.4.5. MIME Content-type Registration for		9.4.5. MIME Content-type Registration for
	'application/emergencyCall.Comment+xml' . . . . . . . 50		'application/emergencyCall.Comment+xml' . . . . . . . 52
	9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 51
	9.5.1. Registration for
	urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 51
			9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 53
			9.5.1. Registration for
			urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 53
	9.5.2. Registration for		9.5.2. Registration for
	urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 51		urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 53
	9.5.3. Registration for		9.5.3. Registration for
	urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 52		urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 54
	9.5.4. Registration for		9.5.4. Registration for
	urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 53		urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 55
	9.5.5. Registration for		9.5.5. Registration for
	urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 54		urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 56
	9.5.6. Registration for		9.5.6. Registration for
	urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 54		urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 56
	9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 55		9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 57
	9.7. VCard Parameter Value Registration . . . . . . . . . . . 56		9.7. VCard Parameter Value Registration . . . . . . . . . . . 58
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
	11.1. Normative References . . . . . . . . . . . . . . . . . . 57		11.1. Normative References . . . . . . . . . . . . . . . . . . 59
	11.2. Informational References . . . . . . . . . . . . . . . . 57		11.2. Informational References . . . . . . . . . . . . . . . . 60
	Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 58		Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 61
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
	1. Introduction		1. Introduction
	When an IP-based emergency call is initiated a rich set of data from		When an IP-based emergency call is initiated a rich set of data from
	multiple data sources is conveyed to the Public Safety Answering		multiple data sources is conveyed to the Public Safety Answering
	Point (PSAP). This data includes information about the calling party		Point (PSAP). This data includes information about the calling party
	identity, the multimedia capabilities of the device, the emergency		identity, the multimedia capabilities of the device, the emergency
	service number, location information, and meta-data about the		service number, location information, and meta-data about the sources
	sources. The device, the access network provider, and any service		of the data. The device, the access network provider, and any
	provider in the call path may have even more information that may be		service provider in the call path have even more information useful
	useful for a PSAP call taker. This document extends the basic set of		for a PSAP call taker. This document extends the basic set of data
	data communicated with an IP-based emergency call providing call		communicated with an IP-based emergency call providing call takers
	takers and the PSAP organization valuable insight and increased		and the PSAP organization valuable insight and increased situational
	situational awareness.		awareness.
	In general, there are three categories of data communicated in an		In general, there are three categories of data communicated in an
	emergency call:		emergency call:
	Data Associated with a Location: Location data is conveyed in the		Data Associated with a Location: Location data is conveyed in the
	Presence Information Data Format Location Object (PIDF-LO) data		Presence Information Data Format Location Object (PIDF-LO) data
	structure originally defined in RFC 4119 [RFC4119]. There may be		structure originally defined in RFC 4119 [RFC4119] and extended by
	data that is specific to the location not available in the		RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location
	location data structure itself, such as floor plans, tenant and		information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for
	building owner contact data, heating, ventilation and air		geodetic location information), and
			[I-D.ietf-geopriv-relative-location] (for relative location).
			There may be data that is specific to the location not available
			in the location data structure itself, such as floor plans, tenant
			and building owner contact data, heating, ventilation and air
	conditioning (HVAC) status, etc.		conditioning (HVAC) status, etc.
	Data Associated with a Call: While information is carried in the		Data Associated with a Call: While information is carried in the
	call setup procedure itself (as part of the SIP headers as well as		call setup procedure itself (as part of the SIP headers as well as
	in the body of the SIP message), there is additional data known by		in the body of the SIP message), there is additional data known by
	the device making the call, or a service provider in the path of		the device making the call, and the service provider along the
	the call. This information may include the service provider		path of the call. This information may include the service
	contact information, subscriber identity and contact information,		provider contact information, subscriber identity and contact
	the type of service the service provider and access network		information, the type of service the service provider and the
	provider offer, what kind of device is being used, etc. Some data		access network provider offer, what kind of device is being used,
	is device or service dependent data. For example, a car		etc. Some data is device or service dependent data. For example,
	telematics system may have crash information. A medical		a car telematics system may have crash information. A medical
	monitoring device may have sensor data.		monitoring device may have sensor data.
	Data Associated with a Caller: This is personal data about a caller,		Data Associated with a Caller: This is personal data about a caller,
	such as medical information and emergency contact data.		such as medical information and emergency contact data.
	This document only defines data structures relevant to data		This document only defines data structures relevant to data
	associated with the call. Other forms of additional data may use		associated with the call but defines extension points for other data
	this mechanism to carry data, but those blocks are not defined in		to be added via other specifications.
	this document.
	For interoperability, there needs to be a common way for the		For interoperability, there needs to be a common way for the
	information conveyed to a PSAP to be encoded and identified.		information conveyed to a PSAP to be encoded and identified.
	Identification allows emergency services authorities to know during		Identification allows emergency services authorities to know during
	call processing which types of data are present and to determine if		call processing which types of data are present and to determine if
	they wish to access it. A common encoding allows the data to be		they wish to access it. A common encoding allows the data to be
	accessed. This document defines the data structures and a way to		accessed.
	communicate the information in several ways. Although current
	standization efforts around IP-based emergency services are focused		This document defines the data structures and a way to communicate
	on the Session Initiation Protocol (SIP) and HTTP the data structures		the information in several ways. Although current standardization
	in XML format described in this document are usable for other		efforts around IP-based emergency services are focused on the Session
	communication systems as well. In Section 3 the data structures are		Initiation Protocol (SIP) and HTTP the data structures in XML format
	defined and the SIP/HTTP transport components are defined in		described in this document are usable for other communication systems
	Section 4 to offer a clear separation between the two.		as well. In Section 3 the data structures are defined and the SIP/
			HTTP transport components are defined in Section 4 to offer a clear
			separation between the two.
	More technically, the data structure described in this document is		More technically, the data structure described in this document is
	represented as one or more "blocks" of information. Each of the		represented as one or more "blocks" of information. Each of the
	blocks is an XML structure with an associated Multipurpose Internet		blocks is an XML structure with an associated Multipurpose Internet
	Mail Extensions (MIME) type for encapsulation, and an extensible set		Mail Extensions (MIME) type for encapsulation, and an extensible set
	of these types constitute the data set. A registry is defined to		of these types constitute the data set. A registry is defined to
	list the block types that may be included.		list the block types that may be included.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document also uses terminology from [RFC5012]. We use the term		This document also uses terminology from [RFC5012]. We use the term
	service provider to refer to an Application Service Provider (ASP) or		service provider to refer to an Application Service Provider (ASP).
	to Voice Service Provider (VSP), which is a specific type of ASP.		A Voice Service Provider (VSP) is a special type of ASP. With the
	With the term "Access Network Provider" we refer to the Internet		term "Access Network Provider" we refer to the Internet Access
	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.
	In the data block definitions, see Section 3, the values for the		In the data block definitions, see Section 3, the values for the
	"Use:" label are specified as one of:		"Use:" label are specified as one of:
	'Required': means they must be present in the data structure.		'Required': means they must be present in the data structure.
	'Conditional': means they must be present unless the specified		'Conditional': means they must be present unless the specified
	condition is met, in which case the they may be present.		condition is met, in which case the they may be present.
	'Optional': means they may be present.		'Optional': means they may be present.
			vCard is a data format for representing and exchanging a variety of
			information about individuals and other entities. For applications
			that use XML the format defined in vCard is not immediately
			applicable. For this purpose an XML-based encoding of the
			information elements defined in the vCard specification has been
			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 interchangeable but it would be accurate to use the term vCard
			only.
	3. Data Structures		3. Data Structures
	This section defines the following five data structures, each as a		This section defines the following five data structures, each as a
	data block. For each block we define the MIME type, and the XML data		data block. For each block we define the MIME type, and the XML data
	structure		structure. The five data structures are:
	'Data Provider': This block supplies name and contact information		'Data Provider': This block supplies name and contact information
	for the entity that created the data. Section 3.1 provides the		for the entity that created the data. Section 3.1 provides the
	details.		details.
	'Service Information': This block supplies information about the		'Service Information': This block supplies information about the
	service. The description can be found in Section 3.2.		service. The description can be found in Section 3.2.
	'Device Information': This block supplies information about the		'Device Information': This block supplies information about the
	device placing the call. Device information can be found in		device placing the call. Device information can be found in
	skipping to change at page 6, line 45 ¶		skipping to change at page 7, line 18 ¶
	'Owner/Subscriber': This block supplies information about the owner		'Owner/Subscriber': This block supplies information about the owner
	of the device or about the subscriber. Details can be found in		of the device or about the subscriber. Details can be found in
	Section 3.4.		Section 3.4.
	'Comment': This block provides a way to supply free form human		'Comment': This block provides a way to supply free form human
	readable text to the PSAP or emergency responders. This simple		readable text to the PSAP or emergency responders. This simple
	structure is defined in Section 3.5.		structure is defined in Section 3.5.
	Note that the xCard format is re-used in some of the data structures		Note that the xCard format is re-used in some of the data structures
	to provide contact information. In a xCard there is no way to		to provide contact information. In an xCard there is no way to
	specify a "main" telephone number. These numbers are useful to		specify a "main" telephone number. These numbers are useful to
	emergency responders who are called to a large enterprise. This		emergency responders who are called to a large enterprise. This
	document adds a new property value to the "tel" property of the TYPE		document adds a new property value to the "tel" property of the TYPE
	parameter called "main". It can be used in any xCard in additional		parameter called "main". It can be used in any xCard in additional
	data.		data.
	3.1. Data Provider Information		3.1. Data Provider Information
	This block is intended to be provided by any service provider in the		This block is intended to be provided by any service provider in the
	path of the call or the access network provider. It includes		path of the call or the access network provider. It includes
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 41 ¶
	3.1.3. Data Provider ID Series		3.1.3. Data Provider ID Series
	Data Element: Data Provider ID Series		Data Element: Data Provider ID Series
	Use: Conditional. If Data Provider ID is provided, Data Provider ID		Use: Conditional. If Data Provider ID is provided, Data Provider ID
	Series is required.		Series is required.
	XML Element: <ProviderIDSeries>		XML Element: <ProviderIDSeries>
	Description: Identifies the issuer of the the ProviderId. A		Description: Identifies the issuer of the ProviderId. A registry
	registry will reflect the following valid entries:		will reflect the following valid entries:
	* NENA		* NENA
	* EENA		* EENA
	Reason for Need: Identifies how to interpret the Data Provider ID.		Reason for Need: Identifies how to interpret the Data Provider ID.
	How Used by Call Taker: Determines which provider ID registry to		How Used by Call Taker: Determines which provider ID registry to
	consult for more information		consult for more information
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 16 ¶
	Data Element: Type of Data Provider ID		Data Element: Type of Data Provider ID
	Use: Conditional. If Data Provider ID is provided, Type of Data		Use: Conditional. If Data Provider ID is provided, Type of Data
	Provider ID is required.		Provider ID is required.
	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 the table below.		values is shown in Figure 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 |		|Service Provider | Calling or Origination telecom SP |
	|Service Provider Subcontractor| A contractor to another kind of SP |		|Service Provider Subcontractor| A contractor to another kind of SP |
	|Telematics Provider | A sensor based SP, especially |		|Telematics Provider | A sensor based SP, especially |
	| | vehicle based |		| | vehicle based |
	|Language Translation Provider | A spoken language translation SP |		|Language Translation Provider | A spoken language translation SP |
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 47 ¶
	service authority can communicate with the service provider or if		service authority can communicate with the service provider or if
	an interpreter will be needed.		an interpreter will be needed.
	How Used by Call Taker: If call taker cannot speak language(s)		How Used by Call Taker: If call taker cannot speak language(s)
	supported by the service provider, a translation service will need		supported by the service provider, a translation service will need
	to be added to the conversation.		to be added to the conversation.
	3.1.7. xCard of Data Provider		3.1.7. xCard of Data Provider
	Data Element: xCard of Data Provider		Data Element: xCard of Data Provider
	Use: Optional		Use: Optional
	XML Element: <DataProviderContact>		XML Element: <DataProviderContact>
			Description: There are many fields in the xCard and the creator of
	Description: There are many fields in the xCARD and the creator of
	the data structure is encouraged to provide as much information as		the data structure is encouraged to provide as much information as
	they have available. N, ORG, ADR, TEL, EMAIL are suggested at a		they have available. N, ORG, ADR, TEL, EMAIL are suggested at a
	minimum. N should contain name of support group or device owner		minimum. N should contain name of support group or device owner
	as appropriate. If more than one TEL property is provided, a		as appropriate. If more than one TEL property is provided, a
	parameter from the vCard Property Value registry MUST be specified		parameter from the vCard Property Value registry MUST be specified
	on each TEL. For encoding of the xCard this specification uses		on each TEL. For encoding of the xCard this specification uses
	the XML-based encoding specified in [RFC6351].		the XML-based encoding specified in [RFC6351]. and is hereinafter
			referred to as "xCard"
	and is hereinafter referred to as "xCard"
	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
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 25 ¶
	assistance is needed.		assistance is needed.
	3.1.10. emergencyCall.ProviderInfo Example		3.1.10. emergencyCall.ProviderInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ad:emergencyCall.ProviderInfo		<ad:emergencyCall.ProviderInfo
	xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<ad:DataProviderString>Example VoIP Provider		<ad:DataProviderString>Example VoIP Provider
	</ad:DataProviderString>		</ad:DataProviderString>
	<ad:ProviderID>ID123</ad:ProviderID>		<ad:ProviderID>urn:nena:companyid:ID123</ad:ProviderID>
	<ad:ProviderIDSeries>NENA</ad:ProviderIDSeries>		<ad:ProviderIDSeries>NENA</ad:ProviderIDSeries>
	<ad:TypeOfProvider>Service Provider</ad:TypeOfProvider>		<ad:TypeOfProvider>Service Provider</ad:TypeOfProvider>
	<ad:ContactURI>sip:voip-provider@example.com</ad:ContactURI>		<ad:ContactURI>sip:voip-provider@example.com</ad:ContactURI>
	<ad:Language>EN</ad:Language>		<ad:Language>EN</ad:Language>
	<xc:DataProviderContact		<xc:DataProviderContact
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
	<vcard>		<vcard>
	<fn><text>Hannes Tschofenig</text></fn>		<fn><text>Hannes Tschofenig</text></fn>
	<n>		<n>
	<surname>Hannes</surname>		<surname>Hannes</surname>
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 14 ¶
	3.2.2. Service Delivered by Provider to End User		3.2.2. Service Delivered by Provider to End User
	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: <SvcDelByProvider>
	Description: This defines the type of service the end user has		Description: This defines the type of service the end user has
	subscribed to. The implied mobility of this service can not be		subscribed to. The implied mobility of this service cannot be
	relied upon. A registry with a initial set of values is defined		relied upon. A registry with an initial set of values is defined
	in the table below.		in Figure 3.
	+--------+----------------------------------------+		+--------+----------------------------------------+
	| Name | Description |		| Name | Description |
	+--------+----------------------------------------+		+--------+----------------------------------------+
	| Wrless | Wireless Telephone Service: Includes |		| Wrless | Wireless Telephone Service: Includes |
	| | Satellite, CDMA, GSM, Wi-Fi, WiMAX, |		| | Satellite, CDMA, GSM, Wi-Fi, WiMAX, |
	| | LTE (Long Term Evolution) |		| | LTE (Long Term Evolution) |
	| 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 |		| 1way | One way outbound service |
	skipping to change at page 18, line 24 ¶		skipping to change at page 17, line 47 ¶
	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 below.		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 |		| Mobile | Mobile handset |
	| ATA | analog terminal adapter |		| ATA | analog terminal adapter |
	|Satphone| Satellite phone |		|Satphone| Satellite phone |
	| FSense | Stationary computing device (alarm |		| FSense | Stationary computing device (alarm |
	skipping to change at page 19, line 24 ¶		skipping to change at page 18, line 45 ¶
	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
	reporting device?		reporting device?
	How Used by Call Taker: May assist with location of caller. For		How Used by Call Taker: May assist with location of caller. For
	example, a cordless handset may be outside or next door. May		example, a cordless handset may be outside or next door. May
	provide calltaker some context about the caller, the capabilities		provide the calltaker some context about the caller, the
	of the device used for the call or the environment the device is		capabilities of the device used for the call or the environment
	being used in.		the device is being used in.
	3.3.2. Device Manufacturer		3.3.2. Device Manufacturer
	Data Element: Device Manufacturer		Data Element: Device Manufacturer
	Use: Optional		Use: Optional
	XML Element: <DeviceMfgr>		XML Element: <DeviceMfgr>
	Description: The plain language name of the manufacturer of the		Description: The plain language name of the manufacturer of the
	device.		device.
	Reason for Need: Used by PSAP management for post-mortem		Reason for Need: Used by PSAP management for post-mortem
	investigation/resolution.		investigation/resolution.
	How Used by Call Taker: Probably not used by calltaker, but by PSAP		How Used by Call Taker: Probably not used by the calltaker, but by
	management.		PSAP management.
	3.3.3. Device Model Number		3.3.3. Device Model Number
	Data Element: Device Model Number		Data Element: Device Model Number
	Use: Optional		Use: Optional
	XML Element: <DeviceModelNr>		XML Element: <DeviceModelNr>
	Description: Model number of the device.		Description: Model number of the device.
	Reason for Need: Used by PSAP management for after action		Reason for Need: Used by PSAP management for after action
	investigation/resolution.		investigation/resolution.
	How Used by Call Taker: Probably not used by calltaker, but by PSAP		How Used by Call Taker: Probably not used by the calltaker, but by
	management.		PSAP management.
	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>
	Description: String that identifies the specific device making the		Description: String that identifies the specific device making the
	call or creating an event.		call or creating an event.
	Reason for Need: Uniquely identifies the device as opposed to any		Reason for Need: Uniquely identifies the device as opposed to any
	signaling identifiers encountered in the call signaling stream.		signaling identifiers encountered in the call signaling stream.
	How Used by Call Taker: Probably not used by calltaker they would		How Used by Call Taker: Probably not used by the calltaker they
	need to refer to management for investigation.		would need to refer to management for investigation.
	3.3.5. Type of Device Identifier		3.3.5. Type of Device Identifier
	Data Element: Type of Device Identifier		Data Element: Type of Device Identifier
	Use: Conditional: must be provided if DeviceID is provided		Use: Conditional: must be provided if the DeviceID is provided
	XML Element: <TypeOfDeviceID>		XML Element: <TypeOfDeviceID>
	Description: Identifies the type of device identifier being		Description: Identifies the type of device identifier being
	generated in the unique device identifier data element. A		generated in the unique device identifier data element. A
	registry with an initial set of values can be seen below:		registry with an initial set of values can be seen 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 |		| UDI | Unique Device Identifier |
	skipping to change at page 23, line 15 ¶		skipping to change at page 21, line 49 ¶
	services.		services.
	Note: Information which is specific to a location or a caller		Note: Information which is specific to a location or a caller
	(person) should not be placed in this section.		(person) should not be placed in this section.
	3.3.8. Choosing between defining a new type of block or new type of		3.3.8. Choosing between defining a new type of block or new type of
	device/service specific additional data		device/service specific additional data
	For devices that have device or service specific data, there are two		For devices that have device or service specific data, there are two
	choices to carry it. A new block can be defined, or the device/		choices to carry it. A new block can be defined, or the device/
	service specific additional data URL the the DevInfo block can be		service specific additional data URL the DevInfo block can be used
	used and a new type for it defined . The data passed would likely be		and a new type for it defined . The data passed would likely be the
	the same in both cases. Considerations for choosing which mechanism		same in both cases. Considerations for choosing which mechanism to
	to register under include:		register under include:
	Applicability: Information which will be carried by many kinds of		Applicability: Information which will be carried by many kinds of
	devices or services are more appropriately defined as separate		devices or services are more appropriately defined as separate
	blocks.		blocks.
	Privacy: Information which may contain private data may be better		Privacy: Information which may contain private data may be better
	sent in the DevInfo block, rather than a new block so that		sent in the DevInfo block, rather than a new block so that
	implementations are not tempted to send the data by value, and		implementations are not tempted to send the data by value, and
	thus having more exposure to the data than forcing the data to be		thus having more exposure to the data than forcing the data to be
	retrieved via the URL in DevInfo.		retrieved via the URL in DevInfo.
	skipping to change at page 24, line 21 ¶		skipping to change at page 23, line 4 ¶
	This block describes the owner of the device (if provided by the		This block describes the owner of the device (if provided by the
	device) or the subscriber information, if provided by a service		device) or the subscriber information, if provided by a service
	provider. The contact location is not necessarily the location of		provider. The contact location is not necessarily the location of
	the caller or incident, but is rather the nominal contact address.		the caller or incident, but is rather the nominal contact address.
	The mime subtype is "application/emergencyCall.Subscriber+xml".		The mime subtype is "application/emergencyCall.Subscriber+xml".
	3.4.1. xCard for Subscriber's Data		3.4.1. xCard for Subscriber's Data
	Data Element: xCARD for Subscriber's Data		Data Element: xCARD for Subscriber's Data
	Use: Conditional: Some services (e.g., prepaid phones, initialized		Use: Conditional: Some services (e.g., prepaid phones, initialized
	phones, etc.) may not have this information.		phones, etc.) may not have this information.
	XML Element: <SubscriberData>		XML Element: <SubscriberData>
	Description: Information known by the service provider or device		Description: Information known by the service provider or device
	about the subscriber; e.g., Name, Address, Individual Telephone		about the subscriber; e.g., Name, Address, Individual Telephone
	Number, Main Telephone Number and any other data. N, ORG (if		Number, Main Telephone Number and any other data. N, ORG (if
	appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more		appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more
	than one TEL property is provided, a parameter from the vCard		than one TEL property is provided, a parameter from the vCard
	Property Value registry MUST be specified on each TEL.		Property Value registry MUST be specified on each TEL.
	skipping to change at page 28, line 18 ¶		skipping to change at page 26, line 39 ¶
	in an existing SIP header field, the Call-Info header, is		in an existing SIP header field, the Call-Info header, is
	defined. The URI points to the additional data structure. The		defined. The URI points to the additional data structure. The
	Call-Info header is specified in Section 20.9 of [RFC3261]. This		Call-Info header is specified in Section 20.9 of [RFC3261]. This
	document adds a new token with the value 'emergencyCallData' for		document adds a new token with the value 'emergencyCallData' for
	the Call-Info "purpose" parameter. If the "purpose" parameter is		the Call-Info "purpose" parameter. If the "purpose" parameter is
	set to 'emergencyCallData' then the Call-Info header contains		set to 'emergencyCallData' then the Call-Info header contains
	either an HTTPS URL pointing to an external resource or a CID		either an HTTPS URL pointing to an external resource or a CID
	(content indirection) URI that allows the data structure to be		(content indirection) URI that allows the data structure to be
	placed in the body of the SIP message. The "purpose" parameter		placed in the body of the SIP message. The "purpose" parameter
	also contains an indication of what kind of data is available at		also contains an indication of what kind of data is available at
	the URI.		the URI. As the data is conveyed using a URI in the SIP
			signaling, the data itself may reside on an external resource, or
	As the data is conveyed using a URI in the SIP signaling, the		may be contained within the body of the SIP message. When the
	data itself may reside on an external resource, or may be		URI refers to data at an external resource, the data is said to
	contained within the body of the SIP message. When the URI		be passed by reference. When the URI refers to data contained
	refers to data at an external resource, the data is said to be
	passed by reference. When the URI refers to data contained
	within the body of the SIP message, the data is said to be passed		within the body of the SIP message, the data is said to be passed
	by value. A PSAP or emergency responder is able to examine the		by value. A PSAP or emergency responder is able to examine the
	type of data provided and selectively inspect the data it is		type of data provided and selectively inspect the data it is
	interested in, while forwarding all of it (the values or		interested in, while forwarding all of it (the values or
	references) to downstream entities.		references) to downstream entities. To be conveyed in a SIP body
			additional data about a call is defined as a series of MIME
	To be conveyed in a SIP body additional data about a call is		objects, each with an XML data structure contained inside. As
	defined as a series of MIME objects, each with an XML data		usual, whenever more than one MIME part is included in the body
	structure contained inside. As usual, whenever more than one		of a message, MIME-multipart (i.e., 'multipart/mixed') encloses
	MIME part is included in the body of a message, MIME-multipart		them all. This document defines the XML schemas and MIME types
	(i.e., 'multipart/mixed') encloses them all. This document		used for each block. When additional data is passed by value in
	defines the XML schemas and MIME types used for each block. When		the SIP signaling, each CID URL points to one block in the body.
	additional data is passed by value in the SIP signaling, each CID		Multiple URIs are used within a Call-Info header field (or
	URL points to one block in the body. Multiple URIs are used		multiple Call-Info header fields) to point to multiple blocks.
	within a Call-Info header field (or multiple Call-Info header		When additional data is provided by reference (in SIP signaling
	fields) to point to multiple blocks. When additional data is		or Provided-By), each HTTPS URL references one block; the data is
	provided by reference (in SIP signaling or Provided-By), each		retrieved with an HTTPS GET operation, which returns one of the
	HTTPS URL references one block; the data is retrieved with an		blocks as an XML object.
	HTTPS GET operation, which returns one of the blocks as an XML
	object.
	2. Second, the ability to embed additional data structures in the		2. Second, the ability to embed additional data structures in the
	<provided-by> element of a PIDF-LO [RFC4119] is defined. Besides		<provided-by> element of a PIDF-LO [RFC4119] is defined. Besides
	a service provider in the call path, the access network provider		a service provider in the call path, the access network provider
	may also have similar information that may be valuable to the		may also have similar information that may be valuable to the
	PSAP. The access network provider may provide location in the		PSAP. The access network provider may provide location in the
	form of a PIDF-LO from a location server via a location		form of a PIDF-LO from a location server via a location
	configuration protocol. The data structures described in this		configuration protocol. The data structures described in this
	document are not specific to the location itsef, but rather		document are not specific to the location itself, but rather
	provides descriptive information having to do with the immediate		provides descriptive information having to do with the immediate
	circumstances about the provision of the location (who the access		circumstances about the provision of the location (who the access
	network is, how to contact that entity, what kind of service the		network is, how to contact that entity, what kind of service the
	access network provides, subscriber information, etc.). This		access network provides, subscriber information, etc.). This
	data is similar in nearly every respect to the data known by		data is similar in nearly every respect to the data known by
	service providers in the path of the call. When the access		service providers in the path of the call. When the access
	network provider and service provider are separate entities, the		network provider and service provider are separate entities, the
	access network does not participate in the application layer		access network does not participate in the application layer
	signaling (and hence cannot add a Call-Info header field to the		signaling (and hence cannot add a Call-Info header field to the
	SIP message), but may provide location information to assist in		SIP message), but may provide location information to assist in
	skipping to change at page 29, line 42 ¶		skipping to change at page 28, line 12 ¶
	blocks are optional, but each entity SHOULD supply any blocks where		blocks are optional, but each entity SHOULD supply any blocks where
	it has at least some of the information in the block.		it has at least some of the information in the block.
	4.1. Transmitting Blocks using the Call-Info Header		4.1. Transmitting Blocks using the Call-Info Header
	A URI to a block MAY be inserted in a SIP request or response method		A URI to a block MAY be inserted in a SIP request or response method
	(most often INVITE or MESSAGE) with a Call-Info header field		(most often INVITE or MESSAGE) with a Call-Info header field
	containing a purpose of "emergencyCallData" together with the type of		containing a purpose of "emergencyCallData" together with the type of
	data available at the URI. The type of data is denoted by including		data available at the URI. The type of data is denoted by including
	the root of the MIME type (not including the emergencyCall prefix and		the root of the MIME type (not including the emergencyCall prefix and
	the +xml suffix) with a "." separator. For example, when		the +xml suffix) with a "." separator. For example, when referencing
	referencing a block with MIME type 'application/		a block with MIME type 'application/emergencyCall.ProviderInfo+xml',
	emergencyCall.ProviderInfo+xml', the 'purpose' parameter is set to		the 'purpose' parameter is set to 'emergencyCallData.ProviderInfo'.
	'emergencyCallData.ProviderInfo'. An example "Call-Info" header		An example "Call-Info" header field for this would be:
	field for this would be:
	Call-Info: https://www.example.com/23sedde3;		Call-Info: https://www.example.com/23sedde3;
	purpose="emergencyCallData.ProviderInfo"		purpose="emergencyCallData.ProviderInfo"
	The Call-info header with purpose='emergencyCallData' MUST only be		The Call-info header with purpose='emergencyCallData' MUST only be
	sent on an emergency call, which can be ascertained by the presence		sent on an emergency call, which can be ascertained by the presence
	of an emergency service urn in a Route header of a SIP message.		of an emergency service urn in a Route header of a SIP message.
	If the data is provided by reference, an HTTPS URI MUST be included		If the data is provided by reference, an HTTPS URI MUST be included
	and consequently Transport Layer Security (TLS) protection is applied		and consequently Transport Layer Security (TLS) protection is applied
	skipping to change at page 31, line 21 ¶		skipping to change at page 29, line 37 ¶
	additional data block by value within a 'Provided-By' element of a		additional data block by value within a 'Provided-By' element of a
	PIDF-LO. The 'emergencyCallDataValue' element has one attribute:		PIDF-LO. The 'emergencyCallDataValue' element has one attribute:
	'purpose' to indicate the type of data block contained. The value of		'purpose' to indicate the type of data block contained. The value of
	'purpose' is the same as used in a 'Call-Info' header field (as		'purpose' is the same as used in a 'Call-Info' header field (as
	specified in Section 4.1, and in Section 4.1). The same XML		specified in Section 4.1, and in Section 4.1). The same XML
	structure as would be wrapped in the corresponding MIME type is		structure as would be wrapped in the corresponding MIME type is
	placed inside the emergencyCallDataValue element.		placed inside the emergencyCallDataValue element.
	For example:		For example:
	<provided-by xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">		<provided-by
	<emergencyCallDataValue purpose="emergencyCallData.ProviderInfo">		xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">
	<ProviderID>Test</ProviderID>		<emergencyCallData>
	<ProviderIDSeries>NENA</ProviderIDSeries>		<byRef purpose="emergencyCallData.SvcInfo"
	<TypeOfProviderID>Access Infrastructure Provider		ref="https://example.com/ref2"/>
			<sub:emergencyCall.Comment
			xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.Comment">
			<sub:Comment xml:lang="en">This is an example text.
			</sub:Comment>
			</sub:emergencyCall.Comment>
			</emergencyCallData>
			<emergencyCallDataValue
			purpose="emergencyCallData.ProviderInfo">
			<ProviderID>Test</ProviderID>
			<ProviderIDSeries>NENA</ProviderIDSeries>
			<TypeOfProviderID>Access Infrastructure Provider
	</TypeOfProviderID>		</TypeOfProviderID>
	<ContactURI>sip:15555550987@burf.example.com;user=phone		<ContactURI>sip:15555550987@burf.example.com;user=phone
	</ContactURI>		</ContactURI>
	</emergencyCallDataValue>		</emergencyCallDataValue>
	</provided-by>		</provided-by>
	Example Provided-By by Value.		Example Provided-By by Value.
			4.4. The Content-Disposition Parameter
			RFC 5621 [RFC5621] discusses the handling of message bodies in SIP.
			It updates and clarifies handling originally defined in RFC 3261
			[RFC3261] based on implementation experience. While RFC 3261 did not
			mandate support for 'multipart' message bodies 'multipart/mixed' MIME
			bodies are, however, used by many extensions (including additional
			data) today. For example, adding a PIDF-LO, SDP, and additional data
			in body of a SIP message requires a 'multipart' message body.
			RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling'
			parameter for the Content-Disposition header field. These RFCs
			describe how a UAS reacts if it receives a message body whose content
			type or disposition type it does not understand. If the 'handling'
			parameter has the value "optional", the UAS ignores the message body.
			If the 'handling' parameter has the value "required", the UAS returns
			a 415 (Unsupported Media Type) response. The 'by-reference'
			disposition type allows a SIP message to contain a reference to the
			body part, and the SIP UA processes the body part according to the
			reference. This is the case for the Call-info header containing a
			Content Indirection (CID) URL.
			As an example, a SIP message indicates the Content-Disposition
			parameter in the body of the SIP message as shown in Figure 10.
			Content-Type: application/sdp
			...Omit Content-Disposition here; defaults are ok
			...SDP goes here
			--boundary1
			Content-Type: application/pidf+xml
			Content-ID: <target123@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
			...PIDF-LO goes here
			--boundary1--
			Content-Type: application/emergencyCall.ProviderInfo+xml
			Content-ID: <1234567890@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
			...Additional data goes here
			--boundary1--
			Figure 10: Example for use of the Content-Disposition Parameter in
			SIP.
	5. Examples		5. Examples
	This section provides three examples of communicating additional		This section provides three examples of communicating additional
	data. In Figure 10 additional data is communicated in a SIP INVITE		data. In Figure 11 additional data is communicated in a SIP INVITE
	per value. In Figure 11 we illustrate how additional data is added		per value. In Figure 12 we illustrate how additional data is added
	by a SIP proxy per reference. Finally, an example of conveying		by a SIP proxy per reference. Finally, an example for including
	additional data in the <Provided-By> is illustrated.		additional data in the <Provided-By> element of a PIDF-LO is
			illustrated.
	INVITE sips:bob@biloxi.example.com SIP/2.0		INVITE sips:bob@biloxi.example.com SIP/2.0
	Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: Bob <sips:bob@biloxi.example.com>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,		Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
	<http://www.example.com/alice/> ;purpose=info,		<http://www.example.com/alice/> ;purpose=info,
	<cid:1234567890@atlanta.example.com>		<cid:1234567890@atlanta.example.com>
	skipping to change at page 32, line 18 ¶		skipping to change at page 32, line 4 ¶
	Geolocation-Routing: no		Geolocation-Routing: no
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallProviderinfo+xml		application/emergencyCallProviderinfo+xml
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Contact: <sips:alice@atlanta.example.com>		Contact: <sips:alice@atlanta.example.com>
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	...SDP goes here		...SDP goes here
	--boundary1		--boundary1
	Content-Type: application/pidf+xml		Content-Type: application/pidf+xml
	Content-ID: <target123@atlanta.example.com>		Content-ID: <target123@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
	\0x2026PIDF-LO goes here		...PIDF-LO goes here
	--boundary1--		--boundary1--
	Content-Type: application/emergencyCall.ProviderInfo+xml		Content-Type: application/emergencyCall.ProviderInfo+xml
	Content-ID: <1234567890@atlanta.example.com>		Content-ID: <1234567890@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
	...Additional Data goes here		...Additional data goes here
	--boundary1--		--boundary1--
	Figure 10: Example: Attaching Additional Data via CID to a SIP		Figure 11: Example: Attaching Additional Data via CID to a SIP
	INVITE.		INVITE.
	INVITE sips:bob@biloxi.example.com SIP/2.0		INVITE sips:bob@biloxi.example.com SIP/2.0
	Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: Bob <sips:bob@biloxi.example.com>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,		Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
	<http://www.example.com/alice/> ;purpose=info,		<http://www.example.com/alice/> ;purpose=info,
	skipping to change at page 33, line 16 ¶		skipping to change at page 33, line 4 ¶
	Geolocation-Routing: no		Geolocation-Routing: no
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallProviderinfo+xml		application/emergencyCallProviderinfo+xml
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Contact: <sips:alice@atlanta.example.com>		Contact: <sips:alice@atlanta.example.com>
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	...SDP goes here		...SDP goes here
	--boundary1		--boundary1
	Content-Type: application/pidf+xml		Content-Type: application/pidf+xml
	Content-ID: <target123@atlanta.example.com>		Content-ID: <target123@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
	PIDF-LO goes here		...PIDF-LO goes here
	--boundary1--		--boundary1--
	Figure 11: Example: Attaching Additional Data per Reference in a SIP		Figure 12: Example: Attaching Additional Data per Reference in a SIP
	INVITE.		INVITE.
	TBD.		<?xml version="1.0" encoding="UTF-8"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
			xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
			entity="pres:alice@atlanta.example.com">
			<dm:device id="target123-1">
			<gp:geopriv>
			<gp:location-info>
			<civicAddress
			xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
			<country>AU</country>
			<A1>NSW</A1>
			<A3>Wollongong</A3>
			<A4>North Wollongong</A4>
			<RD>Flinders</RD>
			<STS>Street</STS>
			<RDBR>Campbell Street</RDBR>
			<LMK>Gilligan's Island</LMK>
			<LOC>Corner</LOC>
			<NAM>Video Rental Store</NAM>
			<PC>2500</PC>
			<ROOM>Westerns and Classics</ROOM>
			<PLC>store</PLC>
			<POBOX>Private Box 15</POBOX>
			</civicAddress>
			</gp:location-info>
			<gp:usage-rules>
			<gbp:retransmission-allowed>true
			</gbp:retransmission-allowed>
			<gbp:retention-expiry>2013-07-10T20:00:00Z
			</gbp:retention-expiry>
			</gp:usage-rules>
			<gp:method>802.11</gp:method>
			<provided-by
			xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData">
	Figure 12: Example: Attaching Additional Data to Provided-By Element.		<emergencyCallDataReference purpose="emergencyCallData.SvcInfo"
			ref="https://example.com/ref2"/>
			<emergencyCallDataValue>
			<emergencyCall.ProviderInfo
			xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo">
			<DataProviderString>University of California, Irvine
			</DataProviderString>
			<ProviderID>urn:nena:companyid:uci</ProviderID>
			<ProviderIDSeries>NENA</ProviderIDSeries>
			<TypeOfProvider>Other</TypeOfProvider>
			<ContactURI>tel:+1 9498245222</ContactURI>
			<Language>EN</Language>
			</emergencyCall.ProviderInfo>
			<emergencyCall.Comment
			xmlns="urn:ietf:params:xml:ns:emergencyCall.Comment">
			<Comment xml:lang="en">This is an example text.</Comment>
			</emergencyCall.Comment>
			</emergencyCallDataValue>
			</provided-by>
			</gp:geopriv>
			<dm:deviceID>mac:1234567890ab</dm:deviceID>
			<dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp>
			</dm:device>
			</presence>
			Figure 13: Example: Including Additional Data via the Provided-By
			Element in a PIDF-LO.
	6. XML Schemas		6. XML Schemas
	This section defines the XML schemas of the five data blocks.		This section defines the XML schemas of the five data blocks.
			Additionally, the Provided-By schema is specified.
	6.1. emergencyCall.ProviderInfo XML Schema		6.1. emergencyCall.ProviderInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		targetNamespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	ttributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<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:import namespace="urn:ietf:params:xml:ns:vcard-4.0">
	<xs:simpleType name="iso3166a2">		<xs:simpleType name="iso3166a2">
	<xs:restriction base="xs:token">		<xs:restriction base="xs:token">
	<xs:pattern value="[A-Z]{2}"/>		<xs:pattern value="[A-Z]{2}"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:element name="emergencyCall.ProviderInfo">		<xs:element
	<xs:complexType>		name="emergencyCall.ProviderInfo"
			type="pi:ProviderInfoType"/>
			<xs:complexType name="ProviderInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DataProviderString"		<xs:element name="DataProviderString"
	type="xs:string" minOccurs="1" maxOccurs="1"/>		type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="ProviderID"		<xs:element name="ProviderID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="ProviderIDSeries"		<xs:element name="ProviderIDSeries"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="TypeOfProvider"		<xs:element name="TypeOfProvider"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="ContactURI" type="xs:anyURI"		<xs:element name="ContactURI" type="xs:anyURI"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:element name="Language" type="ad:iso3166a2"		<xs:element name="Language" type="pi:iso3166a2"
	minOccurs="0" maxOccurs="unbounded" />		minOccurs="0" maxOccurs="unbounded" />
	<xs:element name="DataProviderContact"		<xs:element name="DataProviderContact"
	type="xc:vcardType" minOccurs="0"		type="xc:vcardType" minOccurs="0"
	maxOccurs="1"/>		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:element>
	</xs:schema>
	Figure 13: emergencyCall.ProviderInfo XML Schema		</xs:schema>
			Figure 14: emergencyCall.ProviderInfo XML Schema
	6.2. emergencyCall.SvcInfo XML Schema		6.2. emergencyCall.SvcInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"		targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"		xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified"		elementFormDefault="qualified" attributeFormDefault="unqualified">
	attributeFormDefault="unqualified">
	<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="emergencyCall.SvcInfo">		<xs:element name="emergencyCall.SvcInfo" type="svc:SvcInfoType"/>
	<xs:complexType>
			<xs:complexType name="SvcInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="SvcEnvironment"		<xs:element name="SvcEnvironment"
	type="xs:string" minOccurs="1" maxOccurs="1"/>		type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="SvcDelByProvider"		<xs:element name="SvcDelByProvider"
	type="xs:string" minOccurs="1" maxOccurs="unbounded"/>		type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="SvcMobility"		<xs:element name="SvcMobility"
	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:element>
	</xs:schema>		</xs:schema>
	Figure 14: emergencyCall.SvcInfo XML Schema		Figure 15: emergencyCall.SvcInfo XML Schema
	6.3. emergencyCall.DevInfo XML Schema		6.3. emergencyCall.DevInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo"		targetNamespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.DevInfo"		xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified"		elementFormDefault="qualified" attributeFormDefault="unqualified">
	attributeFormDefault="unqualified">
	<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="emergencyCall.DevInfo">		<xs:element name="emergencyCall.DevInfo" type="dev:DevInfoType"/>
	<xs:complexType>
			<xs:complexType name="DevInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceClassification"		<xs:element name="DeviceClassification"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceMfgr"		<xs:element name="DeviceMfgr"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceModelNr"		<xs:element name="DeviceModelNr"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="UniqueDeviceID"		<xs:element name="UniqueDeviceID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="TypeOfDeviceID"		<xs:element name="TypeOfDeviceID"
	skipping to change at page 36, line 18 ¶		skipping to change at page 37, line 25 ¶
	<xs:element name="DeviceModelNr"		<xs:element name="DeviceModelNr"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="UniqueDeviceID"		<xs:element name="UniqueDeviceID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="TypeOfDeviceID"		<xs:element name="TypeOfDeviceID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceSpecificData"		<xs:element name="DeviceSpecificData"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>		type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceSpecificType"		<xs:element name="DeviceSpecificType"
	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:element>
	</xs:schema>		</xs:schema>
	Figure 15: emergencyCallDevInfo XML Schema		Figure 16: emergencyCall.DevInfo XML Schema
	6.4. emergencyCall.SubInfo XML Schema		6.4. emergencyCall.SubInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo"		targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"		xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
			xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<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="emergencyCall.SubInfo">		<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"/>
	<xs:complexType>
			<xs:element name="emergencyCall.SubInfo" type="sub:SubInfoType"/>
			<xs:complexType name="SubInfoType">
	<xs:sequence>		<xs:sequence>
	<!-- VCard data structure goes in here.		<xs:element name="SubscriberData" type="xc:vcardType"
	<xs:element name="SubscriberData"		minOccurs="0" maxOccurs="1" />
	type="xc:vcard" minOccurs="0" maxOccurs="1"/>
	-->
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>
	</xs:schema>		</xs:schema>
	Figure 16: emergencyCall.SubInfo XML Schema		Figure 17: emergencyCall.SubInfo XML Schema
	6.5. emergencyCall.Comment XML Schema		6.5. emergencyCall.Comment XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:emergencyCall.Comment"		targetNamespace="urn:ietf:params:xml:ns:emergencyCall.Comment"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.Comment"		xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<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="emergencyCall.Comment">		<xs:element name="emergencyCall.Comment" type="com:CommentType"/>
	<xs:complexType>
			<xs:complexType name="CommentType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Comment"		<xs:element name="Comment"
	type="sub:CommentType" minOccurs="0" maxOccurs="unbounded"/>		type="com:CommentSubType" minOccurs="0"
	<xs:any namespace="##other" processContents="lax" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>
	<xs:complexType name="CommentType">		<xs:complexType name="CommentSubType">
	<xs:simpleContent>		<xs:simpleContent>
	<xs:extension base="xs:string">		<xs:extension base="xs:string">
	<xs:attribute ref="xml:lang"/>		<xs:attribute ref="xml:lang"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 17: EmergencyCall.Comment XML Schema		Figure 18: EmergencyCall.Comment XML Schema
			6.6. Provided-By XML Schema
			This section defines the Provided-By schema.
			<?xml version="1.0"?>
			<xs:schema
			targetNamespace=
			"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
			xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
			xmlns:xml="http://www.w3.org/XML/1998/namespace"
			xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
			xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
			xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"
			xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
			xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"
			elementFormDefault="qualified" attributeFormDefault="unqualified">
			<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.Comment"/>
			<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo"/>
			<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo"/>
			<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"/>
			<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"/>
			<xs:element name="provided-by" type="ad:provided-by-Type"/>
			<xs:complexType name="provided-by-Type">
			<xs:sequence>
			<xs:element name="emergencyCallDataReference"
			type="ad:ByRefType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="emergencyCallDataValue"
			type="ad:emergencyCallDataValueType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
			<!-- Additional Data By Reference -->
			<xs:complexType name="ByRefType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:any namespace="##other" minOccurs="0"
			maxOccurs="unbounded" processContents="lax"/>
			</xs:sequence>
			<xs:attribute name="purpose" type="xs:anyURI"
			use="required"/>
			<xs:attribute name="ref" type="xs:anyURI"
			use="required"/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
			<!-- Additional Data By Value -->
			<xs:complexType name="emergencyCallDataValueType">
			<xs:sequence>
			<xs:element name="emergencyCall.ProviderInfo"
			type="pi:ProviderInfoType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="emergencyCall.SvcInfo"
			type="svc:SvcInfoType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="emergencyCall.DevInfo"
			type="dev:DevInfoType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="emergencyCall.SubInfo"
			type="sub:SubInfoType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="emergencyCall.Comment"
			type="com:CommentType"
			minOccurs="0" maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
			</xs:schema>
			Figure 19: Provided-By XML Schema
	7. Security Considerations		7. Security Considerations
	The information in this data structure will usually be considered		The information in this data structure will usually be considered
	private. HTTPS is specified to require the provider of the		private. HTTPS is specified to require the provider of the
	information to validate the credentials of the requester. While the		information to validate the credentials of the requester. While the
	creation of a PKI that has global scope may be difficult, the		creation of a PKI that has global scope may be difficult, the
	alternatives to creating devices and services that can provide		alternatives to creating devices and services that can provide
	critical information securely are more daunting. The provider may		critical information securely are more daunting. The provider may
	enforce any policy it wishes to use, but PSAPs and responder agencies		enforce any policy it wishes to use, but PSAPs and responder agencies
	should deploy a PKI so that providers of additional data can check		should deploy a PKI so that providers of additional data can check
	the certificate of the client and decide the appropriate policy to		the certificate of the client and decide the appropriate policy to
	enforce based on that certificate.		enforce based on that certificate.
	skipping to change at page 38, line 46 ¶		skipping to change at page 41, line 49 ¶
	server. The emergency authorities could provide credentials,		server. The emergency authorities could provide credentials,
	distinguishable from credentials it provides to emergency responders		distinguishable from credentials it provides to emergency responders
	and PSAPs, which could be used to validate data providers. Such		and PSAPs, which could be used to validate data providers. Such
	credentials would have to be acceptable to any PSAP or responder that		credentials would have to be acceptable to any PSAP or responder that
	could receive a call with additional data supplied by that provider.		could receive a call with additional data supplied by that provider.
	This would be extensible to global credential validation using the		This would be extensible to global credential validation using the
	forest guide as above. In the absence of such credentials, the		forest guide as above. In the absence of such credentials, the
	emergency authorities could maintain a list of local data providers'		emergency authorities could maintain a list of local data providers'
	credentials provided to it out of band. At a minimum, the emergency		credentials provided to it out of band. At a minimum, the emergency
	authorities could obtain a credential from the DNS entry of the		authorities could obtain a credential from the DNS entry of the
	domain in the Addional Data URI to at least validate that the server		domain in the Additional Data URI to at least validate that the
	is known to the domain providing the URI.		server is known to the domain providing the URI.
	Data provided by devices by reference have similar credential		Data provided by devices by reference have similar credential
	validation issues to service providers, and the solutions are the		validation issues to service providers, and the solutions are the
	same.		same.
	8. Privacy Considerations		8. Privacy Considerations
	[Editor's Note: Text to be re-written.]		This document enables functionality for conveying additional
			information about the caller to the callee. Some of this information
			is personal data and therefore privacy concerns arise. There are a
			number of privacy concerns with regular real-time communication
			services that are also applicable to emergency calling. Data
			protection regulation world-wide has, however, decided to create
			exceptions for emergency services since the drawbacks of disclosing
			personal data in comparison to the benefit for the emergency caller
			are often towards the latter. Hence, the data protection rights of
			individuals are often waived for emergency situations. There are,
			however, still various countries that offer some degree of anonymity
			for the caller towards PSAP call takers.
			The functionality defined in this document, however, far exceeds the
			amount of information sharing found in the Plain old telephone system
			(POTS). For this reason there are additional privacy threats to
			consider, which are described in more detail in
			[I-D.iab-privacy-considerations].
			Stored Data Compromise: First, there is an increased risk of stored
			data compromise since additional data is collected and stored in
			databases. Without adequate measures to secure stored data from
			unauthorized or inappropriate access at access network operators,
			service providers, end devices, as well as PSAPs individuals are
			exposed to potential financial, reputational, or physical harm.
			Misattribution: If the personal data collected and conveyed is
			incorrect or inaccurate then this may lead to misattribution.
			Misattribution occurs when data or communications related to one
			individual are attributed to another.
			Identification: By the nature of the additional data and its
			capability to provide much richer information about the caller,
			the call, and the location the calling party is identified in a
			much better way. Some users may feel uncomfortable with this
			degree of information sharing even in emergency services
			situations.
			Secondary Use: Furthermore, there is the risk of secondary use.
			Secondary use is the use of collected information about an
			individual without the individual's consent for a purpose
			different from that for which the information was collected. The
			stated purpose of the additional data is for emergency services
			purposes but theoretically the same information could be used for
			any other call as well. Additionally, parties involved in the
			emergency call may retain the obtained information and may re-use
			it for other, non-emergency services purposes.
			Disclosure: When the data defined in this document is not properly
			security (while in transit with traditional communication security
			techniques, and while at rest using access control mechanisms)
			there is the risk of disclosure, which is the revelation of
			information about an individual that affects the way others judge
			the individual.
			To mitigate these privacy risks the following countermeasures can be
			taken.
	In regions where callers can elect to suppress certain personally		In regions where callers can elect to suppress certain personally
	identifying information, the network or PSAP functionality can		identifying information, the network or PSAP functionality can
	inspect privacy flags within the SIP headers to determine what		inspect privacy flags within the SIP headers to determine what
	information may be passed, stored, or displayed to comply with local		information may be passed, stored, or displayed to comply with local
	policy or law.		policy or law. RFC 3325 [RFC3325] defines the "id" priv-value token.
			The presence of this privacy type in a Privacy header field indicates
			that the user would like the network asserted identity to be kept
			private with respect to SIP entities outside the trust domain with
			which the user authenticated, including the PSAP.
	There is much private data in this information. Local regulations		This document defines various data structures that constitutes
	may govern what data must be provided in emergency calls, but in		personal data. Local regulations may govern what data must be
	general, the emergency call system is often aided by the kinds of		provided in emergency calls, but in general, the emergency call
	information described in this document. There is a tradeoff between		system is often aided by the kinds of information described in this
	the privacy considerations and the utility of the data. Certainly,		document. There is a tradeoff between the privacy considerations and
	if the data cannot be protected, due to failure to establish (by TLS)		the utility of the data. For adequate protection this specification
	a secure connection to the data provider, data SHOULD NOT be sent		requires all data exchanges to be secured via communication security
	unless specifically required by regulation.		techniques (namely TLS) against eavesdropping and inception.
			Furthermore, security safeguards are required to prevent unauthorized
			access to data at rest. Various security incidents over the last 10
			years have shown data breaches are not not uncommon and are often
			caused by lack of proper access control frameworks, software bugs
			(buffer overflows), or missing input parsing (SQL injection attacks).
			The risks of data breaches is increased with the obligation for
			emergency services to retain emergency call related data for extended
			periods, e.g., several years are the norm.
	Some forms of data can be sent by value in the SIP signaling or by		Finally, it is also worth to highlight the nature of the SIP
	value (URL in SIP signaling). When data is sent by value, all		communication architecture, which introduces additional complications
	intermediaries have access to the data. If the data is private,		for privacy. Some forms of data can be sent by value in the SIP
	sending by reference is more appropriate.		signaling or by value (URL in SIP signaling). When data is sent by
			value, all intermediaries have access to the data. As such, these
			intermediaries may also introduce additional privacy risk.
			Therefore, in situations where the conveyed information raises
			privacy concerns and intermediaries are involved transmitting a
			reference is more appropriate (assuming proper access control
			policies are available for distinguishing the different entities
			dereferencing the reference). Without access control policies any
			party in possession of the reference is able to resolve the reference
			and to obtain the data, including intermediaries.
	9. IANA Considerations		9. IANA Considerations
	9.1. Registry creation		9.1. Registry creation
	This document creates a new registry called 'Emergency Call		This document creates a new registry called 'Emergency Call
	Additional Data'. The following subregistries are created in		Additional Data'. The following sub-registries are created in
	Emergency Call Additional Data:		Emergency Call Additional Data:
	9.1.1. Additional Call Data Provider ID Series Registry		9.1.1. Provider ID Series Registry
	This document creates a new subregistry called 'Additional Call Data		This document creates a new sub-registry called 'Additional Call Data
	Provider ID Series'. As defined in [RFC5226], this registry operates		Provider ID Series'. As defined in [RFC5226], this registry operates
	under "Expert Review" rules. The expert should determine that the		under "Expert Review" rules. The expert should determine that the
	entity requesting a new value is a legitimate issuer of service		entity requesting a new value is a legitimate issuer of service
	provider IDs suitable for use in Additional Call Data.		provider IDs suitable for use in Additional Call Data.
	The content of this registry includes:		The content of this registry includes:
	Name: The identifier which will be used in the ProviderIDSeries		Name: The identifier which will be used in the ProviderIDSeries
	element		element
	Source: The full name of the organization issuing the identifiers		Source: The full name of the organization issuing the identifiers
	URL: A URL to the organization for further information		URL: A URL to the organization for further information
	The initial set of values is listed in the table below.
	+-----------+-----------+--------------+----------------------+		The initial set of values is listed in Figure 20.
			+-----------+--------------------------+----------------------+
	| Name | Source | URL |		| Name | Source | URL |
	+-----------+--------------------------+----------------------+		+-----------+--------------------------+----------------------+
	| NENA | North American Emergency | http://www.nena.org |		| NENA | National Emergency | http://www.nena.org |
	| | Number Association | |		| | Number Association | |
	| EENA | European Emergency | http://www.eena.org |		| EENA | European Emergency | http://www.eena.org |
	| | Number Association | |		| | Number Association | |
	+-----------+--------------------------+----------------------+		+-----------+--------------------------+----------------------+
	9.1.2. Additional Call Data Service Provider Type Registry		Figure 20: Provider ID Series Registry
	This document creates a new subregistry called 'Service Provider		9.1.2. Service Provider Type Registry
			This document creates a new sub-registry called 'Service Provider
	Type'. As defined in [RFC5226], this registry operates under "Expert		Type'. As defined in [RFC5226], this registry operates under "Expert
	Review". The expert should determine that the proposed new value is		Review". The expert should determine that the proposed new value is
	distinct from existing values and appropriate for use in the		distinct from existing values and appropriate for use in the
	TypeOfServicerProvider element		TypeOfServicerProvider element
	The content of this registry includes:		The content of this registry includes:
	Name: Value to be used in TypeOfServiceProvider.		Name: Value to be used in TypeOfServiceProvider.
	Description: A short description of the type of service provider		Description: A short description of the type of service provider
	The initial set of values is defined in Figure 1.		The initial set of values is defined in Figure 1.
	9.1.3. Additional Call Data Service Delivered Registry		9.1.3. Service Delivered Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new sub-registry called 'Service Delivered'.
	Service Delivered'. As defined in [RFC5226], this registry operates		As defined in [RFC5226], this registry operates under "Expert Review"
	under "Expert Review" rules. The expert should consider whether the		rules. The expert should consider whether the proposed service is
	proposed service is unique from existing services and the definition		unique from existing services and the definition of the service will
	of the service will be clear to implementors and PSAPS/responders.		be clear to implementors and PSAPS/responders.
	The content of this registry includes:		The content of this registry includes:
	Name: enumeration token of the service.		Name: Enumeration token of the service.
	Description: Short description identifying the service.		Description: Short description identifying the service.
	The initial set of values are defined in Figure 3.		The initial set of values are defined in Figure 3.
	9.1.4. Additional Call Data Device Classification Registry		9.1.4. Device Classification Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new sub-registry called 'Device
	Device Classification'. As defined in [RFC5226], this registry		Classification'. As defined in [RFC5226], this registry operates
	operates under "Expert Review" rules. The expert should consider		under "Expert Review" rules. The expert should consider whether the
	whether the proposed class is unique from existing classes and the		proposed class is unique from existing classes and the definition of
	definition of the class will be clear to implementors and PSAPS/		the class will be clear to implementors and PSAPS/responders.
	responders.
	The content of this registry includes:		The content of this registry includes:
	Name: enumeration token of the device classification.		Name: Enumeration token of the device classification.
	Description: Short description identifying the device type.		Description: Short description identifying the device type.
	The initial set of values are defined in Figure 5.		The initial set of values are defined in Figure 5.
	9.1.5. Additional Call Data Device ID Type Type Registry		9.1.5. Device ID Type Type Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new sub-registry called 'Additional Call Data
	Device ID Type'. As defined in [RFC5226], this registry operates		Device ID Type'. As defined in [RFC5226], this registry operates
	under "Expert Review" rules. The expert should ascertain that the		under "Expert Review" rules. The expert should ascertain that the
	proposed type is well understood, and provides the information useful		proposed type is well understood, and provides the information useful
	to PSAPs and responders to uniquely identify a device.		to PSAPs and responders to uniquely identify a device.
	The content of this registry includes:		The content of this registry includes:
	Name: enumeration token of the device id type.		Name: Enumeration token of the device id type.
	Description: Short description identifying type of device id.		Description: Short description identifying type of device id.
	The initial set of values are defined in Figure 6.		The initial set of values are defined in Figure 6.
	9.1.6. Device/Service Specific Additional Data Type Registry		9.1.6. Device/Service Data Type Registry
	This document creates a new registry called 'Device/Service Specific		This document creates a new sub-registry called 'Device/Service Data
	Additional Data Type Registry'. As defined in [RFC5226], this		Type Registry'. As defined in [RFC5226], this registry operates
	registry operates under "Expert Review" and "Specification Required"		under "Expert Review" and "Specification Required" rules. The expert
	rules. The expert should ascertain that the proposed type is well		should ascertain that the proposed type is well understood, and
	understood, and provides information useful to PSAPs and responders.		provides information useful to PSAPs and responders. The
	The specification must contain a complete description of the data,		specification must contain a complete description of the data, and a
	and a precise format specification suitable to allow interoperable		precise format specification suitable to allow interoperable
	implementations.		implementations.
	The content of this registry includes:		The content of this registry includes:
	Name: enumeration token of the data type.		Name: Enumeration token of the data type.
	Description: Short description identifying the the data.		Description: Short description identifying the the data.
	Specification: Citation for the specification of the data.		Specification: Citation for the specification of the data.
	The initial set of values are listed below:		The initial set of values are listed in Figure 21.
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	| 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 |		| VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS |
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	9.1.7. Additional Call Data Blocks Registry		Figure 21: Device/Service Data Type Registry
	This document creates a new subregistry called 'Additional Call Data		9.1.7. Additional Data Blocks Registry
	Blocks' in the purpose registry established by RFC 261. As defined
	in [RFC5226], this registry operates under "Expert Review" and		This document creates a new sub-registry called 'Additional Data
	"Specification Required" rules. The expert is responsible for		Blocks' in the purpose registry established by RFC 3261 [RFC3261].
			As defined in [RFC5226], this registry operates under "Expert Review"
			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
	specification of the block and the block does not obviously duplicate		specification and the proposed functionality does not obviously
	existing blocks.		duplicate existing functionality.
	The content of this registry includes:		The content of this registry includes:
	Name: Element Name of enclosing block.		Name: Element Name of enclosing block.
	Reference: The document that describes the block		Reference: The document that describes the block
	This document defines the following set of values:		The initial set of values are listed in Figure 22.
	+--------------+-----------+		+--------------+------------+
	| Token | Reference |		| Token | Reference |
	+--------------+-----------+		+--------------+------------+
	| ProviderInfo | RFCXXXX |		| ProviderInfo | [This RFC] |
	| SvcInfo | RFCXXXX |		| SvcInfo | [This RFC] |
	| DevInfo | RFCXXXX |		| DevInfo | [This RFC] |
	| Subscriber | RFCXXXX |		| Subscriber | [This RFC] |
	| Comment | RFCXXXX |		| Comment | [This RFC] |
	+--------------+-----------+		+--------------+------------+
	RFC Editor Note:
	replace XXXX in the table above with this documents RFC number		Figure 22: Additional Data Blocks Registry
	9.2. 'emergencyCallData' Purpose Parameter Value		9.2. 'emergencyCallData' Purpose Parameter Value
	This document defines the 'emergencyCall' value for the "purpose"		This document defines the 'emergencyCall' value for the "purpose"
	parameter of the Call-Info header field. The Call-Info header and		parameter of the Call-Info header field. The Call-Info header and
	the corresponding registry for the 'purpose' parameter was		the corresponding registry for the 'purpose' parameter was
	established with RFC 3261 [RFC3261].		established with RFC 3261 [RFC3261].
	Header Parameter New		Header Parameter New
	Field Name Value Reference		Field Name Value Reference
	---------- --------- ----------------- ---------		---------- --------- ----------------- ---------
	Call-Info purpose emergencyCall [This RFC]		Call-Info purpose emergencyCall [This RFC]
	9.3. URN Sub-Namespace Registration for provided-by Registry Entry		9.3. URN Sub-Namespace Registration for provided-by Registry Entry
	This section registers the namespace specified in Section 9.5.1 in		This section registers the namespace specified in Section 9.5.1 in
	the provided-by registry established by RFC 4119, for usage within		the provided-by registry established by RFC 4119, for usage within
	the 'provided-by' element of a PIDF-LO.		the <provided-by> element of a PIDF-LO.
	9.3.1. Provided-By XML Schema
	<?xml version="1.0"?>
	<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
	xmlns:xs="http://www.w3.org/2001/XMLSchema";
	xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
	xmlns:xml="http://www.w3.org/XML/1998/namespace";
	xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
	xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"
	xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
	xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"
	elementFormDefault="qualified" attributeFormDefault="unqualified">
	<!-- Additional Data By Reference -->
	<xs:element name="emergencyCallDataReference">
	<xs:complexType>
	<xs:sequence>
	<xs:element name="emergencyProviderInfo"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyServiceInfo"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyDeviceInfo"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencySubscriberInfo"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyComment"
	type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	<xs:element name="anyOtherRefs"
	type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:ComplexType>
	</xs:element>
	<!-- Additional Data By Value -->
	<xs:element name="emergencyCallDataValue">
	<xs:complexType>
	<xs:sequence>
	<xs:element name="emergencyProviderInfo"
	type="pi:emergencyCall.ProviderInfo"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyServiceInfo"
	type="svc:emergencyCall.SvcInfo"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyDeviceInfo"
	type="dev:emergencyCall.DeviceInfo"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencySubscriberInfo"
	type="sub:emergencyCall.SubInfo"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="emergencyComment"
	type="com:emergencyCall.Comment"
	minOccurs="0" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:schema>
	Figure 18: Provided-By XML Schema		The schema for the provided-by schema used by this document is
			specified in Section 6.6.
	9.4. MIME Registrations		9.4. MIME Registrations
	9.4.1. MIME Content-type Registration for 'application/		9.4.1. MIME Content-type Registration for 'application/
	emergencyCall.ProviderInfo+xml'		emergencyCall.ProviderInfo+xml'
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: emergencyCall.ProviderInfo+xml		MIME subtype name: emergencyCall.ProviderInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset Indicates the character encoding of
			enclosed XML.
	Indicates the character encoding of enclosed XML.
	Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:
	This content type is designed to carry the data provider		Encoding considerations: Uses XML, which can employ 8-bit
	information, which is a sub-category of additional data about an		characters, depending on the character encoding used. See
	emergency call.		Section 3.2 of RFC 3023 [RFC3023].
	Since this data contains personal information appropriate		Security considerations: This content type is designed to carry
	precautions have to be taken to limit unauthorized access,		the data provider information, which is a sub-category of
	inappropriate disclosure to third parties, and eavesdropping of		additional data about an emergency call. Since this data contains
	this information. Please refer to Section 7 and Section 8 for		personal information appropriate precautions have to be taken to
	more information.		limit unauthorized access, inappropriate disclosure to third
			parties, and eavesdropping of this information. Please refer to
			Section 7 and Section 8 for more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information: Magic Number: None File Extension: .xml
	Magic Number: None
	File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Hannes		Person and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	skipping to change at page 46, line 27 ¶		skipping to change at page 49, line 27 ¶
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: emergencyCall.SvcInfo+xml		MIME subtype name: emergencyCall.SvcInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset Indicates the character encoding of
			enclosed XML.
	Indicates the character encoding of enclosed XML.
	Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:
	This content type is designed to carry the service information,		Encoding considerations: Uses XML, which can employ 8-bit
	which is a sub-category of additional data about an emergency		characters, depending on the character encoding used. See
	call.		Section 3.2 of RFC 3023 [RFC3023].
	Since this data contains personal information appropriate		Security considerations: This content type is designed to carry
	precautions have to be taken to limit unauthorized access,		the service information, which is a sub-category of additional
	inappropriate disclosure to third parties, and eavesdropping of		data about an emergency call. Since this data contains personal
	this information. Please refer to Section 7 and Section 8 for		information appropriate precautions have to be taken to limit
	more information.		unauthorized access, inappropriate disclosure to third parties,
			and eavesdropping of this information. Please refer to Section 7
			and Section 8 for more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services
	Additional information:		Applications which use this media type: Emergency Services
	Magic Number: None
	File Extension: .xml
			Additional information: Magic Number: None File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Hannes		Person and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	skipping to change at page 47, line 37 ¶		skipping to change at page 50, line 27 ¶
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: emergencyCall.DevInfo+xml		MIME subtype name: emergencyCall.DevInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset Indicates the character encoding of
			enclosed XML.
	Indicates the character encoding of enclosed XML.
	Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:
	This content type is designed to carry the device information		Encoding considerations: Uses XML, which can employ 8-bit
	information, which is a sub-category of additional data about an		characters, depending on the character encoding used. See
	emergency call.		Section 3.2 of RFC 3023 [RFC3023].
	Since this data contains personal information appropriate		Security considerations: This content type is designed to carry
	precautions have to be taken to limit unauthorized access,		the device information information, which is a sub-category of
	inappropriate disclosure to third parties, and eavesdropping of		additional data about an emergency call. Since this data contains
	this information. Please refer to Section 7 and Section 8 for		personal information appropriate precautions have to be taken to
	more information.		limit unauthorized access, inappropriate disclosure to third
			parties, and eavesdropping of this information. Please refer to
			Section 7 and Section 8 for more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information: Magic Number: None File Extension: .xml
	Magic Number: None
	File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Hannes		Person and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	skipping to change at page 48, line 48 ¶		skipping to change at page 51, line 27 ¶
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: emergencyCall.SubInfo+xml		MIME subtype name: emergencyCall.SubInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset Indicates the character encoding of
			enclosed XML.
	Indicates the character encoding of enclosed XML.
	Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:
	This content type is designed to carry owner/subscriber		Encoding considerations: Uses XML, which can employ 8-bit
	information, which is a sub-category of additional data about an		characters, depending on the character encoding used. See
	emergency call.		Section 3.2 of RFC 3023 [RFC3023].
	Since this data contains personal information appropriate		Security considerations: This content type is designed to carry
	precautions have to be taken to limit unauthorized access,		owner/subscriber information, which is a sub-category of
	inappropriate disclosure to third parties, and eavesdropping of		additional data about an emergency call. Since this data contains
	this information. Please refer to Section 7 and Section 8 for		personal information appropriate precautions have to be taken to
	more information.		limit unauthorized access, inappropriate disclosure to third
			parties, and eavesdropping of this information. Please refer to
			Section 7 and Section 8 for more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information: Magic Number: None File Extension: .xml
	Magic Number: None
	File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Hannes		Person and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	skipping to change at page 50, line 18 ¶		skipping to change at page 52, line 27 ¶
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: emergencyCall.Comment+xml		MIME subtype name: emergencyCall.Comment+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset Indicates the character encoding of
			enclosed XML.
	Indicates the character encoding of enclosed XML.
	Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:
	This content type is designed to carry a comment, which is a sub-		Encoding considerations: Uses XML, which can employ 8-bit
	category of additional data about an emergency call.		characters, depending on the character encoding used. See
			Section 3.2 of RFC 3023 [RFC3023].
	This data may contain personal information. Appropriate		Security considerations: This content type is designed to carry a
	precautions may have to be taken to limit unauthorized access,		comment, which is a sub-category of additional data about an
	inappropriate disclosure to third parties, and eavesdropping of		emergency call. This data may contain personal information.
	this information. Please refer to Section 7 and Section 8 for		Appropriate precautions may have to be taken to limit unauthorized
	more information.		access, inappropriate disclosure to third parties, and
			eavesdropping of this information. Please refer to Section 7 and
			Section 8 for more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information: Magic Number: None File Extension: .xml
	Magic Number: None
	File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Person and email address for further information: Hannes		Person and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	skipping to change at page 55, line 36 ¶		skipping to change at page 57, line 36 ¶
	This specification registers five schemas, as per the guidelines in		This specification registers five schemas, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:additional-
	data:emergencyCallProviderInfo		data:emergencyCallProviderInfo
	Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as		Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
	delegated by the IESG (iesg@ietf.org).		delegated by the IESG (iesg@ietf.org).
	XML: The XML schema can be found in Figure 13.		XML: The XML schema can be found in Figure 14.
	URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo		URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo
	Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as		Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as
	delegated by the IESG (iesg@ietf.org).		delegated by the IESG (iesg@ietf.org).
	XML: The XML schema can be found in Figure 14.		XML: The XML schema can be found in Figure 15.
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:additional-
	data:emergencyCallDevInfo		data:emergencyCallDevInfo
	Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as		Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
	delegated by the IESG (iesg@ietf.org).		delegated by the IESG (iesg@ietf.org).
	XML: The XML schema can be found in Figure 15.		XML: The XML schema can be found in Figure 16.
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:additional-
	data:emergencyCall.SubInfo		data:emergencyCall.SubInfo
	Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as		Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
	delegated by the IESG (iesg@ietf.org).		delegated by the IESG (iesg@ietf.org).
	XML: The XML schema can be found in Section 6.4.		XML: The XML schema can be found in Section 6.4.
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:additional-
	skipping to change at page 57, line 5 ¶		skipping to change at page 58, line 51 ¶
	This work was originally started in NENA and has benefitted from a		This work was originally started in NENA and has benefitted from a
	large number of participants in NENA standardization efforts,		large number of participants in NENA standardization efforts,
	originally in the Long Term Definition Working Group, the Data		originally in the Long Term Definition Working Group, the Data
	Technical Committee and most recently the Additional Data working		Technical Committee and most recently the Additional Data working
	group. The authors are grateful for the initial work and extended		group. The authors are grateful for the initial work and extended
	comments provided by many NENA participants, including Delaine		comments provided by many NENA participants, including Delaine
	Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James		Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
	Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra,		Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra,
	and Robert (Bob) Sherry.		and Robert (Bob) Sherry.
	We would also like to thank James Winterbottom, Paul Kyzivat, Gunnar		We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
	Hellstrom, Martin Thomson, Keith Drage, and Laura Liess for their		Thomson, Keith Drage, and Laura Liess for their review comments.
	review comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, August 1998.		Locators", RFC 2392, August 1998.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
			[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
			F., Watson, M., and M. Zonoun, "MIME media types for ISUP
			and QSIG Objects", RFC 3204, December 2001.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
			[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
			Extensions to the Session Initiation Protocol (SIP) for
			Asserted Identity within Trusted Networks", RFC 3325,
			November 2002.
			[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail
			Extensions (MIME) Parameter", RFC 3459, January 2003.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", RFC 4288, December 2005.		Registration Procedures", RFC 4288, December 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[RFC5621] Camarillo, G., "Message Body Handling in the Session
			Initiation Protocol (SIP)", RFC 5621, September 2009.
	[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,		[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
	August 2011.		August 2011.
	[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC		[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC
	6351, August 2011.		6351, August 2011.
	11.2. Informational References		11.2. Informational References
	[I-D.iab-privacy-considerations]		[I-D.iab-privacy-considerations]
	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", draft-iab-privacy-		Considerations for Internet Protocols", draft-iab-privacy-
	considerations-03 (work in progress), July 2012.		considerations-03 (work in progress), July 2012.
			[I-D.ietf-geopriv-relative-location]
			Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.
			Thomson, "Relative Location Representation", draft-ietf-
			geopriv-relative-location-05 (work in progress), June
			2013.
	[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for		[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	RFC 5012, January 2008.		RFC 5012, January 2008.
			[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
			Format for Presence Information Data Format Location
			Object (PIDF-LO)", RFC 5139, February 2008.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.		[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation		Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, August 2008.		Protocol", RFC 5222, August 2008.
			[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
			Presence Information Data Format Location Object (PIDF-LO)
			Usage Clarification, Considerations, and Recommendations",
			RFC 5491, March 2009.
			[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
			Thomson, "Dynamic Extensions to the Presence Information
			Data Format Location Object (PIDF-LO)", RFC 5962,
			September 2010.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC		[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
	5985, September 2010.		5985, September 2010.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, December 2011.		Multimedia", RFC 6443, December 2011.
			[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
			R. George, "Specifying Civic Address Extensions in the
			Presence Information Data Format Location Object (PIDF-
			LO)", RFC 6848, January 2013.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",		Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, March 2013.		BCP 181, RFC 6881, March 2013.
	Appendix A. XML Schema for vCard/xCard		Appendix A. XML Schema for vCard/xCard
	This section contains the vCard/xCard XML schema version of the Relax		This section contains the vCard/xCard XML schema version of the Relax
	NG schema defined in RFC 6351 [RFC6351] for simplified use with the		NG schema defined in RFC 6351 [RFC6351] for simplified use with the
	XML schemas defined in this document. The schema in RFC 6351		XML schemas defined in this document. The schema in RFC 6351
	[RFC6351] is the normative source and this section is informative		[RFC6351] is the normative source and this section is informative
	skipping to change at page 81, line 4 ¶		skipping to change at page 83, line 37 ¶
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar		NeuStar
	470 Conrad Dr.		470 Conrad Dr.
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone: +1 724 382 1051		Phone: +1 724 382 1051
	Email: br@brianrosen.net		Email: br@brianrosen.net
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Roger Marshall		Roger Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	2401 Elliott Avenue		2401 Elliott Avenue
	Seattle, WA 98121		Seattle, WA 98121
	US		US
	Phone: +1 206 792 2424		Phone: +1 206 792 2424
	Email: rmarshall@telecomsys.com		Email: rmarshall@telecomsys.com
	URI: http://www.telecomsys.com		URI: http://www.telecomsys.com
	Randall Gellens		Randall Gellens
	Qualcomm Technologies, Inc.		Qualcomm Technologies, Inc.
	5775 Morehouse Drive		5775 Morehouse Drive
	San Diego, CA 92121		San Diego, CA 92121
	US		US
	Email: rg+ietf@qti.qualcomm.com		Email: rg+ietf@qti.qualcomm.com
			James Winterbottom
			AU
			Email: a.james.winterbottom@gmail.com
End of changes. 198 change blocks.
	532 lines changed or deleted		761 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/