< draft-ietf-ecrit-additional-data-14.txt		draft-ietf-ecrit-additional-data-15.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: April 19, 2014 Nokia Solutions and Networks		Expires: May 07, 2014 Nokia Solutions and Networks
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	R. Gellens		R. Gellens
	Qualcomm Technologies, Inc.		Qualcomm Technologies, Inc.
	J. Winterbottom		J. Winterbottom
	October 16, 2013		November 03, 2013
	Additional Data related to an Emergency Call		Additional Data related to an Emergency Call
	draft-ietf-ecrit-additional-data-14.txt		draft-ietf-ecrit-additional-data-15.txt
	Abstract		Abstract
	When an emergency call is sent to a Public Safety Answering Point		When an emergency call is sent to a Public Safety Answering Point
	(PSAP), the device that sends it, as well as any application service		(PSAP), the device that sends it, as well as any application service
	provider in the path of the call, or access network provider through		provider in the path of the call, or access network provider through
	which the call originated may have information about the call, the		which the call originated may have information about the call, the
	caller or the location which the PSAP may be able to use. This		caller or the location which the PSAP may be able to use. This
	document describes data structures and a mechanism to convey such		document describes data structures and a mechanism to convey such
	data to the PSAP. The mechanism uses a Uniform Resource Identifier		data to the PSAP. The mechanism uses a Uniform Resource Identifier
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 19, 2014.		This Internet-Draft will expire on May 07, 2014.
	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 31 ¶		skipping to change at page 2, line 31 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . 9		3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9
	3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9		3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10
	3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10		3.1.6. Data Provider Languages(s) Supported . . . . . . . . 11
	3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10		3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11
	3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11		3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12
	3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 11		3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12
	3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12		3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13
	3.2. Service Information . . . . . . . . . . . . . . . . . . . 14		3.2. Service Information . . . . . . . . . . . . . . . . . . . 15
	3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14		3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . . . 18
	3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17		3.2.4. emergencyCallData.SvcInfo Example . . . . . . . . . . 18
	3.3. Device Information . . . . . . . . . . . . . . . . . . . 17		3.3. Device Information . . . . . . . . . . . . . . . . . . . 19
	3.3.1. Device Classification . . . . . . . . . . . . . . . . 17		3.3.1. Device Classification . . . . . . . . . . . . . . . . 19
	3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19		3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 20
	3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19		3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 21
	3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 19		3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 21
	3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 20		3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 21
	3.3.6. Device/Service Specific Additional Data Structure . . 20		3.3.6. Device/Service Specific Additional Data Structure . . 22
	3.3.7. Device/Service Specific Additional Data Structure		3.3.7. Device/Service Specific Additional Data Structure
	Type . . . . . . . . . . . . . . . . . . . . . . . . 21		Type . . . . . . . . . . . . . . . . . . . . . . . . 23
	3.3.8. Choosing between defining a new type of block or new		3.3.8. Choosing between defining a new type of block or new
	type of device/service specific additional data . . . 22		type of device/service specific additional data . . . 23
	3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22		3.3.9. emergencyCallData.DevInfo Example . . . . . . . . . . 24
	3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 23		3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24
	3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 23		3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 25
	3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 24		3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25
	3.4.3. emergencyCall.SubInfo Example . . . . . . . . . . . . 24		3.4.3. emergencyCallData.SubInfo Example . . . . . . . . . . 26
	3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 26		3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27		3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28
	3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27		3.5.2. emergencyCallData.Comment Example . . . . . . . . . . 29
	4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27		4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	4.1. Transmitting Blocks using the Call-Info Header . . . . . 29		4.1. Transmitting Blocks using the Call-Info Header . . . . . 31
	4.2. Transmitting Blocks by Reference using the Provided-By		4.2. Transmitting Blocks by Reference using the Provided-By
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 30		Element . . . . . . . . . . . . . . . . . . . . . . . . . 31
	4.3. Transmitting Blocks by Value using the Provided-By		4.3. Transmitting Blocks by Value using the Provided-By
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 30		Element . . . . . . . . . . . . . . . . . . . . . . . . . 32
	4.4. The Content-Disposition Parameter . . . . . . . . . . . . 31		4.4. The Content-Disposition Parameter . . . . . . . . . . . . 33
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 36		6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45
	6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 36		6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 45
	6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 37		6.2. emergencyCallData.SvcInfo XML Schema . . . . . . . . . . 47
	6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 38		6.3. emergencyCallData.DevInfo XML Schema . . . . . . . . . . 48
	6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 39		6.4. emergencyCallData.SubInfo XML Schema . . . . . . . . . . 49
	6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 39		6.5. emergencyCallData.Comment XML Schema . . . . . . . . . . 49
	6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 40		6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 50
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 42		7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
	9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 46		9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 56
	9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 46		9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 56
	9.1.2. Service Provider Type Registry . . . . . . . . . . . 46		9.1.2. Service Environment Registry . . . . . . . . . . . . 57
	9.1.3. Service Delivered Registry . . . . . . . . . . . . . 47		9.1.3. Service Provider Type Registry . . . . . . . . . . . 57
	9.1.4. Device Classification Registry . . . . . . . . . . . 47		9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57
	9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 47		9.1.5. Device Classification Registry . . . . . . . . . . . 58
	9.1.6. Device/Service Data Type Registry . . . . . . . . . . 48		9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58
	9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48		9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58
	9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 49		9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 59
			9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 60
	9.3. URN Sub-Namespace Registration for provided-by Registry		9.3. URN Sub-Namespace Registration for provided-by Registry
	Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 49		Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 60
	9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 49		9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 60
	9.4.1. MIME Content-type Registration for		9.4.1. MIME Content-type Registration for
	'application/emergencyCall.ProviderInfo+xml' . . . . 49		'application/emergencyCallData.ProviderInfo+xml' . . 60
	9.4.2. MIME Content-type Registration for		9.4.2. MIME Content-type Registration for
	'application/emergencyCall.SvcInfo+xml' . . . . . . . 50		'application/emergencyCallData.SvcInfo+xml' . . . . . 61
	9.4.3. MIME Content-type Registration for		9.4.3. MIME Content-type Registration for
	'application/emergencyCall.DevInfo+xml' . . . . . . . 51		'application/emergencyCallData.DevInfo+xml' . . . . . 62
	9.4.4. MIME Content-type Registration for		9.4.4. MIME Content-type Registration for
	'application/emergencyCall.SubInfo+xml' . . . . . . . 52		'application/emergencyCallData.SubInfo+xml' . . . . . 63
	9.4.5. MIME Content-type Registration for		9.4.5. MIME Content-type Registration for
	'application/emergencyCall.Comment+xml' . . . . . . . 53		'application/emergencyCallData.Comment+xml' . . . . . 64
	9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 54		9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65
	9.5.1. Registration for		9.5.1. Registration for
	urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 54		urn:ietf:params:xml:ns:emergencycalldata . . . . . . 65
	9.5.2. Registration for		9.5.2. Registration for
	urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 55		urn:ietf:params:xml:ns:emergencycalldata:providerinfo 66
	9.5.3. Registration for		9.5.3. Registration for
	urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 56		urn:ietf:params:xml:ns:emergencycalldata:svcinfo . . 67
	9.5.4. Registration for		9.5.4. Registration for
	urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 57		urn:ietf:params:xml:ns:emergencycalldata:devinfo . . 67
	9.5.5. Registration for		9.5.5. Registration for
	urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 57		urn:ietf:params:xml:ns:emergencycalldata:subinfo . . 68
	9.5.6. Registration for		9.5.6. Registration for
	urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 58		urn:ietf:params:xml:ns:emergencycalldata:comment . . 69
	9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 59		9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 70
	9.7. VCard Parameter Value Registration . . . . . . . . . . . 60		9.7. VCard Parameter Value Registration . . . . . . . . . . . 70
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
	11.1. Normative References . . . . . . . . . . . . . . . . . . 60		11.1. Normative References . . . . . . . . . . . . . . . . . . 71
	11.2. Informational References . . . . . . . . . . . . . . . . 61		11.2. Informational References . . . . . . . . . . . . . . . . 72
	Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 62		Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 74
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
	1. Introduction		1. Introduction
	When an IP-based emergency call is initiated a rich set of data from		When an IP-based emergency call is initiated a rich set of data from
	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 sources		service number, location information, and meta-data about the sources
	of the data. The device, the access network provider, and any		of the data. The device, the access network provider, and any
	service provider in the call path may have even more information		service provider in the call path may have even more information
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 20 ¶
	Section 3.3.		Section 3.3.
	'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.
			Each block contains a mandatory <id> element. The purpose of this
			<id> element is to associate the data added by a data provider to the
			data provider block. Consequently, when a data provider adds
			additional data to an emergency call (such as device information) it
			MUST add information about itself (via the data provider block) and
			the two blocks contain the same value in the <id> element, whereby
			the chosen value for the <id> element MUST be different to any other
			<id> elements already added by other data providers.
	Note that the xCard format is re-used in some of the data structures		Note that the xCard format is re-used in some of the data structures
	to provide contact information. In an xCard there is no way to		to provide contact information. In an xCard there is no way to
	specify a "main" telephone number. These numbers are useful to		specify a "main" telephone number. These numbers are useful to
	emergency responders who are called to a large enterprise. This		emergency responders who are called to a large enterprise. This
	document adds a new property value to the "tel" property of the TYPE		document adds a new property value to the "tel" property of the TYPE
	parameter called "main". It can be used in any xCard in additional		parameter called "main". It can be used in any xCard in additional
	data.		data.
	3.1. Data Provider Information		3.1. Data Provider Information
	skipping to change at page 9, line 28 ¶		skipping to change at page 10, line 10 ¶
	Description: Identifies the type of data provider id being supplied		Description: Identifies the type of data provider id being supplied
	in the ProviderId data element. A registry with an initial set of		in the ProviderId data element. A registry with an initial set of
	values is shown in Figure 1.		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 |		|Subcontractor | A contractor to another 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 |
	|Emergency Service Provider | An emergency service provider |		|Emergency Service Provider | An emergency service provider |
	| | conveying information to another |		| | conveying information to another |
	| | emergency service provider. |		| | emergency service provider. |
	|Emergency Modality Translation| An emergency call specific |		|Emergency Modality Translation| An emergency call specific |
	| | modality translation service |		| | modality translation service |
	| | e.g., for sign language |		| | e.g., for sign language |
	|Relay Provider | A interpretation SP, for example, |		|Relay Provider | A interpretation SP, for example, |
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 34 ¶
	+------------------------------+------------------------------------+		+------------------------------+------------------------------------+
	Figure 1: Type of Data Provider ID Registry.		Figure 1: Type of Data Provider ID Registry.
	Reason for Need: Identifies what kind of data provider this is.		Reason for Need: Identifies what kind of data provider this is.
	How Used by Call Taker: To decide who to contact when further		How Used by Call Taker: To decide who to contact when further
	information is needed		information is needed
	3.1.5. Data Provider Contact URI		3.1.5. Data Provider Contact URI
	Data Element: Data Provider Contact URI		Data Element: Data Provider Contact URI
	Use: Required		Use: Required
	XML Element: <ContactURI>		XML Element: <ContactURI>
	Description: When provided by a service provider or an access		Description: When provided by a service provider or an access
	provider, this information MUST be a URI to a 24/7 support		provider, this information MUST be a URI to a 24/7 support
	organization tasked to provide PSAP support for this emergency		organization tasked to provide PSAP support for this emergency
	call. If the call is from a device, this would reflect the		call. If the call is from a device, this would reflect the
	contact information of the owner of the device. If a telephone		contact information of the owner of the device. If a telephone
	number is the contact address then it MUST be tel URI. If it is		number is the contact address then it MUST be tel URI. If it is
	provided as a SIP URI then it MUST be in the form of		provided as a SIP URI then it MUST be in the form of
	sip:telephonenumber@serviceprovider:user=phone.		sip:telephonenumber@serviceprovider:user=phone. Note that this
			contact information is not used by PSAPs for callbacks using a SIP
			Priority header field with the value set to "psap- callback", as
			described in [I-D.ietf-ecrit-psap-callback].
	Reason for Need: Additional data providers may need to be contacted		Reason for Need: Additional data providers may need to be contacted
	for error or other unusual circumstances.		for error or other unusual circumstances.
	How Used by Call Taker: To contact the supplier of the additional		How Used by Call Taker: To contact the supplier of the additional
	data for assistance in handling the call.		data for assistance in handling the call.
	3.1.6. Data Provider Languages(s) Supported		3.1.6. Data Provider Languages(s) Supported
	Data Element: Data Provider Language(s) supported		Data Element: Data Provider Language(s) supported
	skipping to change at page 10, line 40 ¶		skipping to change at page 11, line 26 ¶
	XML Element: <Language>		XML Element: <Language>
	Description: The language used by the entity at the Data Provider		Description: The language used by the entity at the Data Provider
	Contact URI as an alpha 2-character code as defined in ISO		Contact URI as an alpha 2-character code as defined in ISO
	639-1:2002 Codes for the representation of names of languages --		639-1:2002 Codes for the representation of names of languages --
	Part 1: Alpha-2 code Multiple instances of this element may occur.		Part 1: Alpha-2 code Multiple instances of this element may occur.
	Order is significant; preferred language should appear first. The		Order is significant; preferred language should appear first. The
	content MUST reflect the languages supported at the contact URI.		content MUST reflect the languages supported at the contact URI.
			Note that the 'language' media feature tag, defined in RFC 3840
			[RFC3840] and the more extensive language negotiation mechanism
			proposed with [I-D.gellens-negotiating-human-language] are
			independent of this data provider language indication.
	Reason for Need: Information needed to determine if emergency		Reason for Need: Information needed to determine if emergency
	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. Alternatively, other persons at		to be added to the conversation. Alternatively, other persons at
	the PSAP, besides the call taker, might be consulted for help		the PSAP, besides the call taker, might be consulted for help
	(depending on the urgency and the type of interaction).		(depending on the urgency and the type of interaction).
	skipping to change at page 11, line 36 ¶		skipping to change at page 12, line 26 ¶
	3.1.8. Subcontractor Principal		3.1.8. Subcontractor Principal
	Data Element: Subcontractor Principal		Data Element: Subcontractor Principal
	Use: Conditional. This data is required if the Data Provider type		Use: Conditional. This data is required if the Data Provider type
	is subcontractor.		is subcontractor.
	XML Element: <SubcontratorPrincipal>		XML Element: <SubcontratorPrincipal>
	Description: If the data provider is a subcontractor to another		Description: Some providers outsource their obligations to handle
	provider, such as an access infrastructure provider or telematics		aspects of emergency services to specialized providers. If the
	provider, this element contains the DataProviderString of the		data provider is a subcontractor to another provider this element
	service provider to indicate which provider the subcontractor is		contains the DataProviderString of the service provider to
	working for.		indicate which provider the subcontractor is working for.
	Reason for Need: Identify the entity the subcontractor works for.		Reason for Need: Identify the entity the subcontractor works for.
	How Used by Call Taker: Allows the call taker to understand what the		How Used by Call Taker: Allows the call taker to understand what the
	relationship between data providers and the service providers in		relationship between data providers and the service providers in
	the path of the call are.		the path of the call are.
	3.1.9. Subcontractor Priority		3.1.9. Subcontractor Priority
	Data Element: Subcontractor Priority		Data Element: Subcontractor Priority
	Use: Conditional. This data is required if the Data Provider type
	is "subcontractor".		Use: Conditional. This element is required if the Data Provider
			type is set to "Subcontractor".
	XML Element: <SubcontractorPriority>		XML Element: <SubcontractorPriority>
	Description: If the subcontractor has to be contacted first then		Description: If the subcontractor has to be contacted first then
	this element MUST have the value "sub". If the access or service		this element MUST have the value "sub". If the provider the
	provider has to be contacted first then this element MUST have the		subcontractor is working for has to be contacted first then this
	value "main".		element MUST have the value "main".
	Reason for Need: Inform the call taker whom to contact first, if		Reason for Need: Inform the call taker whom to contact first, if
	support is needed.		support is needed.
	How Used by Call Taker: To decide which entity to contact first if		How Used by Call Taker: To decide which entity to contact first if
	assistance is needed.		assistance is needed.
	3.1.10. emergencyCall.ProviderInfo Example		3.1.10. ProviderInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ad:emergencyCall.ProviderInfo		<ad:emergencyCallData.ProviderInfo
	xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:ad="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<ad:id>12345</ad:id>
	<ad:DataProviderString>Example VoIP Provider		<ad:DataProviderString>Example VoIP Provider
	</ad:DataProviderString>		</ad:DataProviderString>
	<ad:ProviderID>urn:nena:companyid: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		<ad:DataProviderContact
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		xmlns="urn:ietf:params:xml:ns:vcard-4.0">
	<vcard>		<vcard>
	<fn><text>Hannes Tschofenig</text></fn>		<fn><text>Hannes Tschofenig</text></fn>
	<n>		<n>
	<surname>Hannes</surname>		<surname>Hannes</surname>
	<given>Tschofenig</given>		<given>Tschofenig</given>
	<additional/>		<additional/>
	<prefix/>		<prefix/>
	<suffix>Dipl. Ing.</suffix>		<suffix>Dipl. Ing.</suffix>
	</n>		</n>
	<bday><date>--0203</date></bday>		<bday><date>--0203</date></bday>
	skipping to change at page 14, line 18 ¶		skipping to change at page 15, line 9 ¶
	http://www.tschofenig.priv.at/key.asc		http://www.tschofenig.priv.at/key.asc
	</uri>		</uri>
	</key>		</key>
	<tz><text>Finland/Helsinki</text></tz>		<tz><text>Finland/Helsinki</text></tz>
	<url>		<url>
	<parameters><type><text>home</text></type>		<parameters><type><text>home</text></type>
	</parameters>		</parameters>
	<uri>http://www.tschofenig.priv.at</uri>		<uri>http://www.tschofenig.priv.at</uri>
	</url>		</url>
	</vcard>		</vcard>
	</xc:DataProviderContact>		</ad:DataProviderContact>
	</ad:emergencyCall.ProviderInfo>		</ad:emergencyCallData.ProviderInfo>
	Figure 2: emergencyCall.ProviderInfo Example.		Figure 2: emergencyCall.ProviderInfo Example.
	3.2. Service Information		3.2. Service Information
	This block describes the service that the service provider provides		This block describes the service that the service provider provides
	to the caller. It SHOULD be included by all SPs in the path of the		to the caller. It SHOULD be included by all SPs in the path of the
	call. The mime subtype is "application/emergencyCall.SvcInfo+xml".		call. The mime subtype is "application/emergencyCall.SvcInfo+xml".
	3.2.1. Service Environment		3.2.1. Service Environment
	Data Element: Service Environment		Data Element: Service Environment
	Use: Required		Use: Required
	XML Element: <SvcEnvironment>		XML Element: <SvcEnvironment>
	Description: This element defines whether a call is from a business		Description: This element defines whether a call is from a business
	or residence caller. Currently, the only valid entries are		or residence caller. Currently, the only valid entries are
	'Business' or 'Residence'.		'Business' or 'Residence'. New values can be defined via the
			registry created in Figure 22.
	Reason for Need: To assist in determining equipment and manpower		Reason for Need: To assist in determining equipment and manpower
	requirements.		requirements.
	How Used by Call Taker: Information may be used to assist in		How Used by Call Taker: Information may be used to assist in
	determining equipment and manpower requirements for emergency		determining equipment and manpower requirements for emergency
	responders. As the information is not always available, and the		responders. As the information is not always available, and the
	registry is not all encompassing, this is at best advisory		registry is not all encompassing, this is at best advisory
	information, but since it mimics a similar capability in some		information, but since it mimics a similar capability in some
	current emergency calling systems, it is known to be valuable.		current emergency calling systems, it is known to be valuable.
	skipping to change at page 17, line 14 ¶		skipping to change at page 18, line 45 ¶
	* Unknown: no information is known about the service mobility		* Unknown: no information is known about the service mobility
	environment for the device		environment for the device
	Reason for Need: Knowing the service provider's belief of mobility		Reason for Need: Knowing the service provider's belief of mobility
	may assist the PSAP with the handling of the call.		may assist the PSAP with the handling of the call.
	How Used by Call Taker: To determine whether to assume the location		How Used by Call Taker: To determine whether to assume the location
	of the caller might change.		of the caller might change.
	3.2.4. emergencyCall.SvcInfo Example		3.2.4. emergencyCallData.SvcInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<svc:emergencyCall.SvcInfo		<svc:emergencyCallData.SvcInfo
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"		xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<svc:id>12345</svc:id>
	<svc:SvcEnvironment>Business</svc:SvcEnvironment>		<svc:SvcEnvironment>Business</svc:SvcEnvironment>
	<svc:SvcDelByProvider>MLTS</svc:SvcDelByProvider>		<svc:SvcDelByProvider>MLTS</svc:SvcDelByProvider>
	<svc:SvcMobility>Fixed</svc:SvcMobility>		<svc:SvcMobility>Fixed</svc:SvcMobility>
	</svc:emergencyCall.SvcInfo>		</svc:emergencyCallData.SvcInfo>
	Figure 4: emergencyCall.SvcInfo Example.		Figure 4: emergencyCallData.SvcInfo Example.
	3.3. Device Information		3.3. Device Information
	This block provides information about the device used to place the		This block provides information about the device used to place the
	call. It should be provided by any service provider that knows what		call. It should be provided by any service provider that knows what
	device is being used, and by the device itself. The mime subtype is		device is being used, and by the device itself. The mime subtype is
	"application/emergencyCall.DevInfo+xml".		"application/emergencyCall.DevInfo+xml".
	3.3.1. Device Classification		3.3.1. Device Classification
	skipping to change at page 22, line 39 ¶		skipping to change at page 24, line 33 ¶
	DevInfo block, rather than a new block so that implementations are		DevInfo block, rather than a new block so that implementations are
	not tempted to send the data by value. Conversely, data which is		not tempted to send the data by value. Conversely, data which is
	small may best be sent in a separate block so that it can be sent		small may best be sent in a separate block so that it can be sent
	by value		by value
	Availability of a server: Providing the data via the device block		Availability of a server: Providing the data via the device block
	requires a server be made available to retrieve the data.		requires a server be made available to retrieve the data.
	Providing the data via new block allows it to be sent by value		Providing the data via new block allows it to be sent by value
	(CID).		(CID).
	3.3.9. emergencyCall.DevInfo Example		3.3.9. emergencyCallData.DevInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<svc:emergencyCall.DevInfo		<dev:emergencyCallData.DevInfo
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.DevInfo"		xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<svc:DeviceClassification>Fixed phone</svc:DeviceClassification>		<dev:id>12345</dev:id>
	<svc:DeviceMfgr>Nokia</svc:DeviceMfgr>		<dev:DeviceClassification>Fixed phone</dev:DeviceClassification>
	<svc:DeviceModelNr>Lumia 800</svc:DeviceModelNr>		<dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
	<svc:UniqueDeviceID>35788104</svc:UniqueDeviceID>		<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
	<svc:TypeOfDeviceID>IMEI</svc:TypeOfDeviceID>		<dev:UniqueDeviceID>35788104</dev:UniqueDeviceID>
	</svc:emergencyCall.DevInfo>		<dev:TypeOfDeviceID>IMEI</dev:TypeOfDeviceID>
			</dev:emergencyCallData.DevInfo>
	Figure 7: emergencyCallDevInfo Example.		Figure 7: emergencyCallData.DevInfo Example.
	3.4. Owner/Subscriber Information		3.4. Owner/Subscriber Information
	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".
	In some jurisdictions some or all parts of the subscriber-specific		In some jurisdictions some or all parts of the subscriber-specific
	information are subject to privacy constraints. These constraints		information are subject to privacy constraints. These constraints
	vary but dictate what information and be displayed and logged. A		vary but dictate what information and be displayed and logged. A
	general privacy indicator expressing a desire for privacy is		general privacy indicator expressing a desire for privacy is
	skipping to change at page 24, line 33 ¶		skipping to change at page 26, line 16 ¶
	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.
	Reason for Need: When the caller is unable to provide information,		Reason for Need: When the caller is unable to provide information,
	this data may be used to obtain it		this data may be used to obtain it
	How Used by Call Taker: Obtaining critical information about the		How Used by Call Taker: Obtaining critical information about the
	caller and possibly the location when it is not able to be		caller and possibly the location when it is not able to be
	obtained otherwise.		obtained otherwise.
	3.4.3. emergencyCall.SubInfo Example		3.4.3. emergencyCallData.SubInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ad:emergencyCall.SubInfo		<sub:emergencyCallData.SubInfo
	xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo"		xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:subinfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	privacyRequested="false">		privacyRequested="false">
	<xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		<sub:id>12345</sub:id>
	<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">		<sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0">
			<vcards>
	<vcard>		<vcard>
	<fn><text>Simon Perreault</text></fn>		<fn><text>Simon Perreault</text></fn>
	<n>		<n>
	<surname>Perreault</surname>		<surname>Perreault</surname>
	<given>Simon</given>		<given>Simon</given>
	<additional/>		<additional/>
	<prefix/>		<prefix/>
	<suffix>ing. jr</suffix>		<suffix>ing. jr</suffix>
	<suffix>M.Sc.</suffix>		<suffix>M.Sc.</suffix>
	</n>		</n>
	skipping to change at page 26, line 38 ¶		skipping to change at page 28, line 23 ¶
	</uri>		</uri>
	</key>		</key>
	<tz><text>America/Montreal</text></tz>		<tz><text>America/Montreal</text></tz>
	<url>		<url>
	<parameters><type><text>home</text></type>		<parameters><type><text>home</text></type>
	</parameters>		</parameters>
	<uri>http://nomis80.org</uri>		<uri>http://nomis80.org</uri>
	</url>		</url>
	</vcard>		</vcard>
	</vcards>		</vcards>
	</xc:SubscriberData>		</sub:SubscriberData>
	</ad:emergencyCall.SubInfo>		</sub:emergencyCallData.SubInfo>
	Figure 8: emergencyCall.SubInfo Example.		Figure 8: emergencyCallData.SubInfo Example.
	3.5. Comment		3.5. Comment
	This block provides a mechanism for the data provider to supply		This block provides a mechanism for the data provider to supply
	extra, human readable information to the PSAP. It is not intended		extra, human readable information to the PSAP. It is not intended
	for a general purpose extension mechanism nor does it aim to provide		for a general purpose extension mechanism nor does it aim to provide
	machine-reable content. The mime subtype is "application/		machine-reable content. The mime subtype is "application/
	emergencyCall.Comment+xml"		emergencyCall.Comment+xml"
	3.5.1. Comment		3.5.1. Comment
	skipping to change at page 27, line 21 ¶		skipping to change at page 29, line 5 ¶
	XML Element: <Comment>		XML Element: <Comment>
	Description: Human readable text providing additional information to		Description: Human readable text providing additional information to
	the PSAP staff.		the PSAP staff.
	Reason for Need: Explanatory information for values in the data		Reason for Need: Explanatory information for values in the data
	structure		structure
	How Used by Call Taker: To interpret the data provided		How Used by Call Taker: To interpret the data provided
	3.5.2. emergencyCall.Comment Example		3.5.2. emergencyCallData.Comment Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<sub:emergencyCall.Comment		<com:emergencyCallData.Comment
	xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.Comment"		xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:comment"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<sub:Comment xml:lang="en">This is an example text.</sub:Comment>		<com:id>12345</com:id>
	</sub:emergencyCall.Comment>		<com:Comment xml:lang="en">This is an example text.</com:Comment>
			</com:emergencyCallData.Comment>
	Figure 9: EmergencyCall.Comment Example.		Figure 9: EmergencyCallData.Comment Example.
	4. Transport		4. Transport
	This section defines how to convey additional data to an emergency		This section defines how to convey additional data to an emergency
	service provider. Two different means are specified: the first uses		service provider. Two different means are specified: the first uses
	the call signaling; the second uses the <provided-by> element of a		the call signaling; the second uses the <provided-by> element of a
	PIDF-LO [RFC4119].		PIDF-LO [RFC4119].
	1. First, the ability to embed a Uniform Resource Identifier (URI)		1. First, the ability to embed a Uniform Resource Identifier (URI)
	in an existing SIP header field, the Call-Info header, is		in an existing SIP header field, the Call-Info header, is
	skipping to change at page 32, line 8 ¶		skipping to change at page 33, line 38 ¶
	body part, and the SIP UA processes the body part according 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		reference. This is the case for the Call-info header containing a
	Content Indirection (CID) URL.		Content Indirection (CID) URL.
	As an example, a SIP message indicates the Content-Disposition		As an example, a SIP message indicates the Content-Disposition
	parameter in the body of the SIP message as shown in Figure 10.		parameter in the body of the SIP message as shown in Figure 10.
	Content-Type: application/sdp		Content-Type: application/sdp
	...Omit Content-Disposition here; defaults are ok		...Omit Content-Disposition here; defaults are ok
	...SDP goes here		...SDP goes in 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		Content-Disposition: by-reference;handling=optional
	...PIDF-LO goes here		...PIDF-LO goes in 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		Content-Disposition: by-reference;handling=optional
	...Additional data goes here		...Data provider information data goes in here
	--boundary1--		--boundary1--
	Figure 10: Example for use of the Content-Disposition Parameter in		Figure 10: Example for use of the Content-Disposition Parameter in
	SIP.		SIP.
	5. Examples		5. Examples
	This section provides three examples of communicating additional		This section illustrates a longer and more complex example, as shown
	data. In Figure 11 additional data is communicated in a SIP INVITE		in Figure 11. In this example additional data is added by the end
	per value. In Figure 12 we illustrate how additional data is added		device, included by the VoIP provider, and provided by the access
	by a SIP proxy per reference. Finally, an example for including		network provider.
	additional data in the <Provided-By> element of a PIDF-LO is
	illustrated.
	INVITE sips:bob@biloxi.example.com SIP/2.0		O +----+ Emergency Call
	Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		/|\ | UA |--+ +Device Info
			| +----+ | +Data Provider Info
			/ \ | +Location URI
			|
			| (1)
			\
			\
			,-----------. Location
			,' `. +Owner/Subscriber Info
			/ \ +Device Info
			| Access | +Data Provider Info #3
			| Network |<..................+
			| Provider | .
			\ / . (4)
			`. ,' .
			'----------' .
			| .
			| v
			| +----------+
			(2)| | |
			| | PSAP |
			\ | |
			\ +----------+
			Emergency Call \ ^
			+Device Info \ |
			+Data Provider Info ,-------. | (3)
			+Location URI ,' `. -
			/ VoIP \ ----
			( Provider )---
			\ example.org / Emergency Call
			`. ,' +Device Info
			'-------' +Owner/Subscriber Info
			+Data Provider Info
			//////////////
			+Service Info
			+Location URI
			+Data Provider Info #2
			Legend:
			--- Emergency Call Setup Procedure
			... Location Retrieval/Response
			Figure 11: Additional Data Example Flow.
			The example scenario starts with the end device itself adding device
			information, owner/subscriber information, a location URI, and data
			provider information to the outgoing emergency call setup message
			(see step #1 in Figure 11). The SIP INVITE example is shown in
			Figure 12.
			INVITE urn:service:sos SIP/2.0
			Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: <urn:service:sos>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@example.com
	Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,		Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
	<http://www.example.com/alice/> ;purpose=info,		<http://www.example.com/hannes/> ;purpose=info,
	<cid:1234567890@atlanta.example.com>		<cid:1234567890@example.com>
	;purpose=emergencyCallData.ProviderInfo		;purpose=emergencyCallData.ProviderInfo
	Geolocation: <cid:target123@atlanta.example.com>		Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
	Geolocation-Routing: no		Geolocation-Routing: yes
	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:hannes@example.com>
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	...SDP goes here		...SDP goes here
	--boundary1		--boundary1--
	Content-Type: application/pidf+xml		Content-Type: application/emergencyCallData.DevInfo+xml
	Content-ID: <target123@atlanta.example.com>		Content-ID: <1234567890@atlanta.example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
	...PIDF-LO goes here		<dev:emergencyCallData.DevInfo
			xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<dev:id>12345</svc:id>
			<dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
			<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
			<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
			</dev:emergencyCallData.DevInfo>
	--boundary1--		--boundary1--
	Content-Type: application/emergencyCall.ProviderInfo+xml		Content-Type: application/emergencyCallData.ProviderInfo+xml
	Content-ID: <1234567890@atlanta.example.com>		Content-ID: <1234567890@atlanta.example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
			<pi:emergencyCallData.ProviderInfo
			xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<pi:id>12345</pi:id>
			<pi:DataProviderString>Hannes Tschofenig
			</pi:DataProviderString>
			<pi:TypeOfProvider>Other</pi:TypeOfProvider>
			<pi:ContactURI>sip:hannes@example.com</pi:ContactURI>
			<pi:Language>EN</pi:Language>
			<xc:DataProviderContact
			xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcard>
			<fn><text>Hannes Tschofenig</text></fn>
			<n>
			<surname>Hannes</surname>
			<given>Tschofenig</given>
			<additional/>
			<prefix/>
			<suffix>Dipl. Ing.</suffix>
			</n>
			<bday><date>--0203</date></bday>
			<anniversary>
			<date-time>20090808T1430-0500</date-time>
			</anniversary>
			<gender><sex>M</sex></gender>
			<lang>
			<parameters><pref><integer>1</integer></pref>
			</parameters>
			<language-tag>de</language-tag>
			</lang>
			<lang>
			<parameters><pref><integer>2</integer></pref>
			</parameters>
			<language-tag>en</language-tag>
			</lang>
			<adr>
			<parameters>
			<type><text>work</text></type>
			<label><text>Hannes Tschofenig
			Linnoitustie 6
			Espoo, Finland
			02600</text></label>
			</parameters>
			<pobox/>
			<ext/>
			<street>Linnoitustie 6</street>
			<locality>Espoo</locality>
			<region>Uusimaa</region>
			<code>02600</code>
			<country>Finland</country>
			</adr>
			<tel>
			<parameters>
			<type>
			<text>work</text>
			<text>voice</text>
			</type>
			</parameters>
			<uri>tel:+358 50 4871445</uri>
			</tel>
			<email>
			<parameters><type><text>work</text></type>
			</parameters>
			<text>hannes.tschofenig@nsn.com</text>
			</email>
			<geo>
			<parameters><type><text>work</text></type>
			</parameters>
			<uri>geo:60.210796,24.812924</uri>
	...Additional data goes here		</geo>
			<key>
			<parameters>
			<type><text>home</text></type>
			</parameters>
			<uri>https://www.example.com/key.asc
			</uri>
			</key>
			<tz><text>Finland/Helsinki</text></tz>
			<url>
			<parameters><type><text>home</text></type>
			</parameters>
			<uri>http://example.com/hannes.tschofenig</uri>
			</url>
			</vcard>
			</xc:DataProviderContact>
			</pi:emergencyCallData.ProviderInfo>
	--boundary1--		--boundary1--
	Figure 11: Example: Attaching Additional Data via CID to a SIP		Figure 12: End Device sending SIP INVITE with Additional Data.
	INVITE.
	INVITE sips:bob@biloxi.example.com SIP/2.0		In this example, information available to the access network operator
	Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		is included in the call setup message only indirectly via the use of
			the location reference. The PSAP has to retrieve it via a separate
			look-up step. Since the access network provider and the VoIP service
			provider are two independent entities in this scenario the access
			network operator is not involved in the processing of application
			layer exchanges and forwards the SIP INVITE transparently, as
			illustrated in step #1. No change to the SIP INVITE is applied.
			When the VoIP service provider receives the message and determines
			based on the Service URN that the incoming request is an emergency
			call. It performs the typical emergency services related tasks,
			including location-based routing, and adds additional data, namely
			service and subscriber information, to the outgoing message. For the
			example we assume a VoIP service provider that deploys a back-to-back
			user agent allowing additional data to be included in the body of the
			SIP message (rather than per reference in the header), which allows
			us to illustrate the use of multiple data provider info blocks. The
			resulting message is shown in Figure 13.
			INVITE sips:psap@example.org SIP/2.0
			Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: <urn:service:sos>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@example.com
	Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,		Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
	<http://www.example.com/alice/> ;purpose=info,		<http://www.example.com/hannes/> ;purpose=info,
	<https://www.example.com/abc123456/>		<cid:1234567890@example.com>
	;purpose=emergencyCallData.ProviderInfo		;purpose=emergencyCallData.ProviderInfo
	Geolocation: <cid:target123@atlanta.example.com>		Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
	Geolocation-Routing: no		Geolocation-Routing: yes
	Accept: application/sdp, application/pidf+xml,		Accept: application/sdp, application/pidf+xml,
	application/emergencyCallProviderinfo+xml		application/emergencyCallData.ProviderInfo+xml
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Contact: <sips:alice@atlanta.example.com>		Contact: <sips:hannes@example.com>
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	...SDP goes here		...SDP goes here
	--boundary1		--boundary1--
	Content-Type: application/pidf+xml		Content-Type: application/emergencyCallData.DevInfo+xml
	Content-ID: <target123@atlanta.example.com>		Content-ID: <1234567890@atlanta.example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
	...PIDF-LO goes here		<dev:emergencyCallData.DevInfo
			xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<dev:id>12345</svc:id>
			<dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
			<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
			<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
			</dev:emergencyCallData.DevInfo>
	--boundary1--		--boundary1--
	Figure 12: Example: Attaching Additional Data per Reference in a SIP		Content-Type: application/emergencyCallData.ProviderInfo+xml
	INVITE.		Content-ID: <1234567890@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
			<pi:emergencyCallData.ProviderInfo
			xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<pi:id>12345</pi:id>
			<pi:DataProviderString>Hannes Tschofenig
			</pi:DataProviderString>
			<pi:TypeOfProvider>Other</pi:TypeOfProvider>
			<pi:ContactURI>sip:hannes@example.com</pi:ContactURI>
			<pi:Language>EN</pi:Language>
			<xc:DataProviderContact
			xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcard>
			<fn><text>Hannes Tschofenig</text></fn>
			<n>
			<surname>Hannes</surname>
			<given>Tschofenig</given>
			<additional/>
			<prefix/>
			<suffix>Dipl. Ing.</suffix>
			</n>
			<bday><date>--0203</date></bday>
			<anniversary>
			<date-time>20090808T1430-0500</date-time>
			</anniversary>
			<gender><sex>M</sex></gender>
			<lang>
			<parameters><pref><integer>1</integer></pref>
			</parameters>
			<language-tag>de</language-tag>
			</lang>
			<lang>
			<parameters><pref><integer>2</integer></pref>
			</parameters>
			<language-tag>en</language-tag>
			</lang>
			<adr>
			<parameters>
			<type><text>work</text></type>
			<label><text>Hannes Tschofenig
			Linnoitustie 6
			Espoo, Finland
			02600</text></label>
			</parameters>
			<pobox/>
			<ext/>
			<street>Linnoitustie 6</street>
			<locality>Espoo</locality>
			<region>Uusimaa</region>
			<code>02600</code>
			<country>Finland</country>
			</adr>
			<tel>
			<parameters>
			<type>
			<text>work</text>
			<text>voice</text>
			</type>
			</parameters>
			<uri>tel:+358 50 4871445</uri>
			</tel>
			<email>
			<parameters><type><text>work</text></type>
			</parameters>
			<text>hannes.tschofenig@nsn.com</text>
			</email>
			<geo>
			<parameters><type><text>work</text></type>
			</parameters>
			<uri>geo:60.210796,24.812924</uri>
			</geo>
			<key>
			<parameters>
			<type><text>home</text></type>
			</parameters>
			<uri>https://www.example.com/key.asc
			</uri>
			</key>
			<tz><text>Finland/Helsinki</text></tz>
			<url>
			<parameters><type><text>home</text></type>
			</parameters>
			<uri>http://example.com/hannes.tschofenig</uri>
			</url>
			</vcard>
			</xc:DataProviderContact>
			</pi:emergencyCallData.ProviderInfo>
			--boundary1--
			Content-Type: application/emergencyCall.SvcInfo+xml
			Content-ID: <1234567890@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
			<svc:emergencyCall.SvcInfo
			xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<svc:id>abc123</svc:id>
			<svc:SvcEnvironment>Residence</svc:SvcEnvironment>
			<svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider>
			<svc:SvcMobility>Unknown</svc:SvcMobility>
			</svc:emergencyCall.SvcInfo>
			--boundary1--
			Content-Type: application/emergencyCallData.ProviderInfo+xml
			Content-ID: <1234567890@atlanta.example.com>
			Content-Disposition: by-reference;handling=optional
			<?xml version="1.0" encoding="UTF-8"?>
			<pi:emergencyCallData.ProviderInfo
			xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<pi:id>abc123</pi:id>
			<pi:DataProviderString>Example VoIP Provider
			</pi:DataProviderString>
			<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
			<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
			<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>
			<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>
			<pi:Language>EN</pi:Language>
			<xc:DataProviderContact
			xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcard>
			<fn><text>John Doe</text></fn>
			<n>
			<surname>John</surname>
			<given>Doe</given>
			<additional/>
			<prefix/>
			<suffix/>
			</n>
			<bday><date>--0203</date></bday>
			<anniversary>
			<date-time>20090808T1430-0500</date-time>
			</anniversary>
			<gender><sex>M</sex></gender>
			<lang>
			<parameters><pref><integer>1</integer></pref>
			</parameters>
			<language-tag>en</language-tag>
			</lang>
			<org>
			<parameters><type><text>work</text></type>
			</parameters>
			<text>Example VoIP Provider</text>
			</org>
			<adr>
			<parameters>
			<type><text>work</text></type>
			<label><text>John Doe
			Downing Street 10
			London, UK</text></label>
			</parameters>
			<pobox/>
			<ext/>
			<street>Downing Street 10</street>
			<locality>London</locality>
			<region/>
			<code>SW1A 2AA</code>
			<country>UK</country>
			</adr>
			<tel>
			<parameters>
			<type>
			<text>work</text>
			<text>voice</text>
			</type>
			</parameters>
			<uri>sips:john.doe@example.com</uri>
			</tel>
			<email>
			<parameters><type><text>work</text></type>
			</parameters>
			<text>john.doe@example.com</text>
			</email>
			<geo>
			<parameters><type><text>work</text></type>
			</parameters>
			<uri>geo:51.503396, 0.127640</uri>
			</geo>
			<tz><text>Europe/London</text></tz>
			<url>
			<parameters><type><text>home</text></type>
			</parameters>
			<uri>http://www.example.com/john.doe</uri>
			</url>
			</vcard>
			</xc:DataProviderContact>
			</pi:emergencyCallData.ProviderInfo>
			Figure 13: VoIP Provider sending SIP INVITE with Additional Data.
			Finally, the PSAP requests location information from the access
			network operator. The response is shown in Figure 14. Along with
			the location information additional data is provided in the
			<Provided-By> element of the PIDF-LO.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"		xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	entity="pres:alice@atlanta.example.com">		entity="pres:alice@atlanta.example.com">
	<dm:device id="target123-1">		<dm:device id="target123-1">
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	skipping to change at page 35, line 15 ¶		skipping to change at page 44, line 33 ¶
	<NAM>Video Rental Store</NAM>		<NAM>Video Rental Store</NAM>
	<PC>2500</PC>		<PC>2500</PC>
	<ROOM>Westerns and Classics</ROOM>		<ROOM>Westerns and Classics</ROOM>
	<PLC>store</PLC>		<PLC>store</PLC>
	<POBOX>Private Box 15</POBOX>		<POBOX>Private Box 15</POBOX>
	</civicAddress>		</civicAddress>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules>		<gp:usage-rules>
	<gbp:retransmission-allowed>true		<gbp:retransmission-allowed>true
	</gbp:retransmission-allowed>		</gbp:retransmission-allowed>
	<gbp:retention-expiry>2013-07-10T20:00:00Z		<gbp:retention-expiry>2013-12-10T20:00:00Z
	</gbp:retention-expiry>		</gbp:retention-expiry>
	</gp:usage-rules>		</gp:usage-rules>
	<gp:method>802.11</gp:method>		<gp:method>802.11</gp:method>
	<provided-by
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData">		<provided-by
			xmlns="urn:ietf:params:xml:ns:emergencycalldata">
	<emergencyCallDataReference purpose="emergencyCallData.SvcInfo"		<emergencyCallDataReference purpose="emergencyCallData.SvcInfo"
	ref="https://example.com/ref2"/>		ref="https://example.com/ref2"/>
	<emergencyCallDataValue>		<emergencyCallDataValue>
	<emergencyCall.ProviderInfo		<emergencyCallData.ProviderInfo
	xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo">		xmlns="urn:ietf:params:xml:ns:emergencycalldata:providerinfo">
	<DataProviderString>University of California, Irvine		<DataProviderString>University of California, Irvine
	</DataProviderString>		</DataProviderString>
	<ProviderID>urn:nena:companyid:uci</ProviderID>		<ProviderID>urn:nena:companyid:uci</ProviderID>
	<ProviderIDSeries>NENA</ProviderIDSeries>		<ProviderIDSeries>NENA</ProviderIDSeries>
	<TypeOfProvider>Other</TypeOfProvider>		<TypeOfProvider>Other</TypeOfProvider>
	<ContactURI>tel:+1 9498245222</ContactURI>		<ContactURI>tel:+1 9498245222</ContactURI>
	<Language>EN</Language>		<Language>EN</Language>
	</emergencyCall.ProviderInfo>		</emergencyCallData.ProviderInfo>
	<emergencyCall.Comment		<emergencyCallData.Comment
	xmlns="urn:ietf:params:xml:ns:emergencyCall.Comment">		xmlns="urn:ietf:params:xml:ns:emergencycalldata:comment">
	<Comment xml:lang="en">This is an example text.</Comment>		<Comment xml:lang="en">This is an example text.</Comment>
	</emergencyCall.Comment>		</emergencyCallData.Comment>
	</emergencyCallDataValue>		</emergencyCallDataValue>
	</provided-by>		</provided-by>
	</gp:geopriv>		</gp:geopriv>
	<dm:deviceID>mac:1234567890ab</dm:deviceID>		<dm:deviceID>mac:00-0d-4b-30-72-df</dm:deviceID>
	<dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp>		<dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp>
	</dm:device>		</dm:device>
	</presence>		</presence>
	Figure 13: Example: Including Additional Data via the Provided-By
	Element in a PIDF-LO.		Figure 14: Access Network Provider returning PIDF-LO with Additional
			Data.
	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.		Additionally, the Provided-By schema is specified.
	6.1. emergencyCall.ProviderInfo XML Schema		6.1. emergencyCallData.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:emergencycalldata:providerinfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata: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"
	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:import namespace="urn:ietf:params:xml:ns:vcard-4.0">		<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0">
	skipping to change at page 36, line 32 ¶		skipping to change at page 46, line 4 ¶
	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:import namespace="urn:ietf:params:xml:ns:vcard-4.0">		<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		<xs:element
	name="emergencyCall.ProviderInfo"		name="emergencyCallData.ProviderInfo"
	type="pi:ProviderInfoType"/>		type="pi:ProviderInfoType"/>
	<xs:simpleType name="SubcontractorPriorityType">		<xs:simpleType name="SubcontractorPriorityType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="sub"/>		<xs:enumeration value="sub"/>
	<xs:enumeration value="main"/>		<xs:enumeration value="main"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="ProviderInfoType">		<xs:complexType name="ProviderInfoType">
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="DataProviderString"		<xs:element name="DataProviderString"
	type="xs:string" minOccurs="1" maxOccurs="1"/>		type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="ProviderID"		<xs:element name="ProviderID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="ProviderIDSeries"		<xs:element name="ProviderIDSeries"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="TypeOfProvider"		<xs:element name="TypeOfProvider"
	type="xs:string" minOccurs="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="pi: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:element name="SubcontratorPrincipal"		<xs:element name="SubcontratorPrincipal"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="SubcontractorPriority"		<xs:element name="SubcontractorPriority"
	type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/>		type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 14: emergencyCall.ProviderInfo XML Schema.		Figure 15: emergencyCallData.ProviderInfo XML Schema.
	6.2. emergencyCall.SvcInfo XML Schema		6.2. emergencyCallData.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:emergencycalldata: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:emergencycalldata:svcinfo"
	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.SvcInfo" type="svc:SvcInfoType"/>		<xs:element name="emergencyCallData.SvcInfo" type="svc:SvcInfoType"/>
	<xs:complexType name="SvcInfoType">		<xs:complexType name="SvcInfoType">
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<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="1"/>		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:schema>		</xs:schema>
			Figure 16: emergencyCallData.SvcInfo XML Schema.
	Figure 15: emergencyCall.SvcInfo XML Schema.		6.3. emergencyCallData.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:emergencycalldata:devinfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"		xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
	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.DevInfo" type="dev:DevInfoType"/>		<xs:element name="emergencyCallData.DevInfo" type="dev:DevInfoType"/>
	<xs:complexType name="DevInfoType">		<xs:complexType name="DevInfoType">
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<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"
	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:schema>		</xs:schema>
	Figure 16: emergencyCall.DevInfo XML Schema.		Figure 17: emergencyCallData.DevInfo XML Schema.
	6.4. emergencyCall.SubInfo XML Schema		6.4. emergencyCallData.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:emergencycalldata: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:emergencycalldata:subinfo"
	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"		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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"/>		<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"/>
	<xs:element name="emergencyCall.SubInfo" type="sub:SubInfoType"/>		<xs:element name="emergencyCallData.SubInfo" type="sub:SubInfoType"/>
	<xs:complexType name="SubInfoType">		<xs:complexType name="SubInfoType">
	<xs:complexContent>		<xs:complexContent>
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="SubscriberData" type="xc:vcardType"		<xs:element name="SubscriberData" type="xc:vcardType"
	minOccurs="0" maxOccurs="1" />		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:attribute name="privacyRequested" type="xs:boolean" use="required"/>		<xs:attribute name="privacyRequested" type="xs:boolean" use="required"/>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 17: emergencyCall.SubInfo XML Schema.		Figure 18: emergencyCallData.SubInfo XML Schema.
	6.5. emergencyCall.Comment XML Schema		6.5. emergencyCallData.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:emergencycalldata:comment"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"		xmlns:com="urn:ietf:params:xml:ns:emergencycalldata: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" type="com:CommentType"/>		<xs:element name="emergencyCallData.Comment" type="com:CommentType"/>
	<xs:complexType name="CommentType">		<xs:complexType name="CommentType">
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="Comment"		<xs:element name="Comment"
	type="com:CommentSubType" minOccurs="0"		type="com:CommentSubType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="CommentSubType">		<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 18: EmergencyCall.Comment XML Schema.		Figure 19: EmergencyCallData.Comment XML Schema.
	6.6. Provided-By XML Schema		6.6. Provided-By XML Schema
	This section defines the Provided-By schema.		This section defines the Provided-By schema.
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace=		targetNamespace=
	"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"		"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"		xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"		xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
	xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"		xmlns:svc="urn:ietf:params:xml:ns:emergencycalldata:svcinfo"
	xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"		xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
	xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"		xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:subinfo"
	xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"		xmlns:com="urn:ietf:params:xml:ns:emergencycalldata:comment"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.Comment"/>		<xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"/>
	<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo"/>		<xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:svcinfo"/>
	<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo"/>		<xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:devinfo"/>
	<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"/>		<xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:subinfo"/>
	<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"/>		<xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:comment"/>
	<xs:element name="provided-by" type="ad:provided-by-Type"/>		<xs:element name="provided-by" type="ad:provided-by-Type"/>
	<xs:complexType name="provided-by-Type">		<xs:complexType name="provided-by-Type">
	<xs:sequence>		<xs:sequence>
			<xs:element name="id"
			type="xs:string" minOccurs="1" maxOccurs="1"/>
	<xs:element name="emergencyCallDataReference"		<xs:element name="emergencyCallDataReference"
	type="ad:ByRefType"		type="ad:ByRefType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="emergencyCallDataValue"		<xs:element name="emergencyCallDataValue"
	type="ad:emergencyCallDataValueType"		type="ad:emergencyCallDataValueType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	skipping to change at page 42, line 4 ¶		skipping to change at page 52, line 10 ¶
	<xs:any namespace="##other" minOccurs="0"		<xs:any namespace="##other" minOccurs="0"
	maxOccurs="unbounded" processContents="lax"/>		maxOccurs="unbounded" processContents="lax"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="purpose" type="xs:anyURI"		<xs:attribute name="purpose" type="xs:anyURI"
	use="required"/>		use="required"/>
	<xs:attribute name="ref" type="xs:anyURI"		<xs:attribute name="ref" type="xs:anyURI"
	use="required"/>		use="required"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<!-- Additional Data By Value -->		<!-- Additional Data By Value -->
	<xs:complexType name="emergencyCallDataValueType">		<xs:complexType name="emergencyCallDataValueType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="emergencyCall.ProviderInfo"		<xs:element name="emergencyCallData.ProviderInfo"
	type="pi:ProviderInfoType"		type="pi:ProviderInfoType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="emergencyCall.SvcInfo"		<xs:element name="emergencyCallData.SvcInfo"
	type="svc:SvcInfoType"		type="svc:SvcInfoType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="emergencyCall.DevInfo"		<xs:element name="emergencyCallData.DevInfo"
	type="dev:DevInfoType"		type="dev:DevInfoType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="emergencyCall.SubInfo"		<xs:element name="emergencyCallData.SubInfo"
	type="sub:SubInfoType"		type="sub:SubInfoType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="emergencyCall.Comment"		<xs:element name="emergencyCallData.Comment"
	type="com:CommentType"		type="com:CommentType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	Figure 19: Provided-By XML Schema.		Figure 20: 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 public key infrastructure (PKI) that has global scope		creation of a public key infrastructure (PKI) that has global scope
	may be difficult, the alternatives to creating devices and services		may be difficult, the alternatives to creating devices and services
	that can provide critical information securely are more daunting.		that can provide critical information securely are more daunting.
	The provider may enforce any policy it wishes to use, but PSAPs and		The provider may enforce any policy it wishes to use, but PSAPs and
	responder agencies should deploy a PKI so that providers of		responder agencies should deploy a PKI so that providers of
	additional data can check the certificate of the client and decide		additional data can check the certificate of the client and decide
	the appropriate policy to enforce based on that certificate.		the appropriate policy to enforce based on that certificate.
	skipping to change at page 46, line 4 ¶		skipping to change at page 56, line 14 ¶
	intermediaries may also introduce additional privacy risk.		intermediaries may also introduce additional privacy risk.
	Therefore, in situations where the conveyed information raises		Therefore, in situations where the conveyed information raises
	privacy concerns and intermediaries are involved transmitting a		privacy concerns and intermediaries are involved transmitting a
	reference is more appropriate (assuming proper access control		reference is more appropriate (assuming proper access control
	policies are available for distinguishing the different entities		policies are available for distinguishing the different entities
	dereferencing the reference). Without access control policies any		dereferencing the reference). Without access control policies any
	party in possession of the reference is able to resolve the reference		party in possession of the reference is able to resolve the reference
	and to obtain the data, including intermediaries.		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 sub-registries are created in		Additional Data'. The following sub-registries are created for this
	Emergency Call Additional Data:		registry.
	9.1.1. Provider ID Series Registry		9.1.1. Provider ID Series Registry
	This document creates a new sub-registry 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 Figure 20.		The initial set of values is listed in Figure 21.
	+-----------+--------------------------+----------------------+		+-----------+--------------------------+----------------------+
	| Name | Source | URL |		| Name | Source | URL |
	+-----------+--------------------------+----------------------+		+-----------+--------------------------+----------------------+
	| NENA | National 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 | |
	+-----------+--------------------------+----------------------+		+-----------+--------------------------+----------------------+
	Figure 20: Provider ID Series Registry.		Figure 21: Provider ID Series Registry.
	9.1.2. Service Provider Type Registry		9.1.2. Service Environment Registry
			This document creates a new sub-registry called 'Additional Call
			Service Environment'. As defined in [RFC5226], this registry
			operates under "Expert Review" rules. The expert should determine
			that the entity requesting a new value is relevant for this service
			element.
			The content of this registry includes:
			Token: The value to be used in <SvcEnvironment> element.
			Description: A short description of the token.
			The initial set of values is listed in Figure 22.
			+-----------+--------------------------+
			| Token | Description |
			+-----------+--------------------------+
			| Business | [[This RFC]] |
			| Residence | [[This RFC]] |
			+-----------+--------------------------+
			Figure 22: Service Environment Registry.
			9.1.3. Service Provider Type Registry
	This document creates a new sub-registry called 'Service Provider		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: The 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. Service Delivered Registry		9.1.4. Service Delivered Registry
	This document creates a new sub-registry called 'Service Delivered'.		This document creates a new sub-registry called 'Service Delivered'.
	As defined in [RFC5226], this registry operates under "Expert Review"		As defined in [RFC5226], this registry operates under "Expert Review"
	rules. The expert should consider whether the proposed service is		rules. The expert should consider whether the proposed service is
	unique from existing services and the definition of the service will		unique from existing services and the definition 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. Device Classification Registry		9.1.5. Device Classification Registry
	This document creates a new sub-registry called 'Device		This document creates a new sub-registry called 'Device
	Classification'. As defined in [RFC5226], this registry operates		Classification'. As defined in [RFC5226], this registry operates
	under "Expert Review" rules. The expert should consider whether the		under "Expert Review" rules. The expert should consider whether the
	proposed class is unique from existing classes and the definition of		proposed class is unique from existing classes and the definition of
	the class will be clear to implementors and PSAPS/responders.		the class will be clear to implementors and PSAPS/responders.
	The content of this registry includes:		The content of this registry includes:
	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. Device ID Type Type Registry		9.1.6. Device ID Type Type Registry
	This document creates a new sub-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 Data Type Registry		9.1.7. Device/Service Data Type Registry
	This document creates a new sub-registry called 'Device/Service Data		This document creates a new sub-registry called 'Device/Service Data
	Type Registry'. As defined in [RFC5226], this registry operates		Type Registry'. As defined in [RFC5226], this registry operates
	under "Expert Review" and "Specification Required" rules. The expert		under "Expert Review" and "Specification Required" rules. The expert
	should ascertain that the proposed type is well understood, and		should ascertain that the proposed type is well understood, and
	provides information useful to PSAPs and responders. The		provides information useful to PSAPs and responders. The
	specification must contain a complete description of the data, and a		specification must contain a complete description of the data, 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 in Figure 21.		The initial set of values are listed in Figure 23.
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	| Token | Description | Specification |		| Token | Description | Specification |
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	| IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 |		| IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 |
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	| VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS |		| VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS |
	+---------+----------------------------------------+----------------+		+---------+----------------------------------------+----------------+
	Figure 21: Device/Service Data Type Registry.		Figure 23: Device/Service Data Type Registry.
	9.1.7. Additional Data Blocks Registry		9.1.8. Additional Data Blocks Registry
	This document creates a new sub-registry called 'Additional Data		This document creates a new sub-registry called 'Additional Data
	Blocks' in the purpose registry established by RFC 3261 [RFC3261].		Blocks' in the purpose registry established by RFC 3261 [RFC3261].
	As defined in [RFC5226], this registry operates under "Expert Review"		As defined in [RFC5226], this registry operates under "Expert Review"
	and "Specification Required" rules. The expert is responsible for		and "Specification Required" rules. The expert is responsible for
	verifying that the document contains a complete and clear		verifying that the document contains a complete and clear
	specification and the proposed functionality does not obviously		specification and the proposed functionality does not obviously
	duplicate existing functionality.		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
	The initial set of values are listed in Figure 22.		The initial set of values are listed in Figure 24.
	+--------------+------------+		+--------------+------------+
	| Token | Reference |		| Token | Reference |
	+--------------+------------+		+--------------+------------+
	| ProviderInfo | [This RFC] |		| ProviderInfo | [This RFC] |
	| SvcInfo | [This RFC] |		| SvcInfo | [This RFC] |
	| DevInfo | [This RFC] |		| DevInfo | [This RFC] |
	| Subscriber | [This RFC] |		| Subscriber | [This RFC] |
	| Comment | [This RFC] |		| Comment | [This RFC] |
	+--------------+------------+		+--------------+------------+
	Figure 22: Additional Data Blocks Registry.		Figure 24: 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 'emergencyCallData' value for the "purpose"
	parameter of the Call-Info header field. The Call-Info header and		parameter of the Call-Info header field. The Call-Info header and
	the corresponding registry for the 'purpose' parameter was		the corresponding registry for the 'purpose' parameter was
	established with RFC 3261 [RFC3261].		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 emergencyCallData [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.
	The schema for the provided-by schema used by this document is		The schema for the provided-by schema used by this document is
	specified in Section 6.6.		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'		emergencyCallData.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: emergencyCallData.ProviderInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset Indicates the character encoding of		Optional parameters: charset Indicates the character encoding of
	enclosed XML.		enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 3023 [RFC3023].
	skipping to change at page 50, line 50 ¶		skipping to change at page 61, line 37 ¶
	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>
	9.4.2. MIME Content-type Registration for 'application/		9.4.2. MIME Content-type Registration for 'application/
	emergencyCall.SvcInfo+xml'		emergencyCallData.SvcInfo+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.SvcInfo+xml		MIME subtype name: emergencyCallData.SvcInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset Indicates the character encoding of		Optional parameters: charset Indicates the character encoding of
	enclosed XML.		enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 3023 [RFC3023].
	skipping to change at page 51, line 50 ¶		skipping to change at page 62, line 37 ¶
	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>
	9.4.3. MIME Content-type Registration for 'application/		9.4.3. MIME Content-type Registration for 'application/
	emergencyCall.DevInfo+xml'		emergencyCallData.DevInfo+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.DevInfo+xml		MIME subtype name: emergencyCallData.DevInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset Indicates the character encoding of		Optional parameters: charset Indicates the character encoding of
	enclosed XML.		enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 3023 [RFC3023].
	skipping to change at page 52, line 50 ¶		skipping to change at page 63, line 37 ¶
	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>
	9.4.4. MIME Content-type Registration for 'application/		9.4.4. MIME Content-type Registration for 'application/
	emergencyCall.SubInfo+xml'		emergencyCallData.SubInfo+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.SubInfo+xml		MIME subtype name: emergencyCallData.SubInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset Indicates the character encoding of		Optional parameters: charset Indicates the character encoding of
	enclosed XML.		enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 3023 [RFC3023].
	skipping to change at page 53, line 50 ¶		skipping to change at page 64, line 37 ¶
	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>
	9.4.5. MIME Content-type Registration for 'application/		9.4.5. MIME Content-type Registration for 'application/
	emergencyCall.Comment+xml'		emergencyCallData.Comment+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.Comment+xml		MIME subtype name: emergencyCallData.Comment+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset Indicates the character encoding of		Optional parameters: charset Indicates the character encoding of
	enclosed XML.		enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See		characters, depending on the character encoding used. See
	Section 3.2 of RFC 3023 [RFC3023].		Section 3.2 of RFC 3023 [RFC3023].
	skipping to change at page 54, line 51 ¶		skipping to change at page 65, line 38 ¶
	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>
	9.5. URN Sub-Namespace Registration		9.5. URN Sub-Namespace Registration
	9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData		9.5.1. Registration for urn:ietf:params:xml:ns:emergencycalldata
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCallAddlData		URI: urn:ietf:params:xml:ns:emergencycalldata
	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:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 55, line 32 ¶		skipping to change at page 66, line 20 ¶
	<title>Namespace for Additional Emergency Call Data</title>		<title>Namespace for Additional Emergency Call Data</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Additional Data related to an Emergency Call</h1>		<h1>Namespace for Additional Data related to an Emergency Call</h1>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.5.2. Registration for		9.5.2. Registration for
	urn:ietf:params:xml:ns:emergencyCallProviderInfo		urn:ietf:params:xml:ns:emergencycalldata:providerinfo
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCallProviderInfo		URI: urn:ietf:params:xml:ns:emergencycalldata:providerinfo
	Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as		Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
	delegated by the IESG <iesg@ietf.org>.		delegated by the IESG <iesg@ietf.org>.
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 56, line 4 ¶		skipping to change at page 66, line 36 ¶
	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:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>Namespace for Additional Emergency Call Data:		<title>Namespace for Additional Emergency Call Data:
	Data Provider Information</title>		Data Provider Information</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Additional Data related to an Emergency Call</h1>		<h1>Namespace for Additional Data related to an Emergency Call</h1>
	<h2>Data Provider Information</h2>		<h2>Data Provider Information</h2>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo		9.5.3. Registration for
			urn:ietf:params:xml:ns:emergencycalldata:svcinfo
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCall.SvcInfo		URI: urn:ietf:params:xml:ns:emergencycalldata:svcinfo
	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:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 57, line 5 ¶		skipping to change at page 67, line 38 ¶
	Service Information</title>		Service Information</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Additional Data related to an Emergency Call</h1>		<h1>Namespace for Additional Data related to an Emergency Call</h1>
	<h2>Service Information</h2>		<h2>Service Information</h2>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo		9.5.4. Registration for
			urn:ietf:params:xml:ns:emergencycalldata:devinfo
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCall.DevInfo		URI: urn:ietf:params:xml:ns:emergencycalldata:devinfo
	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:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	skipping to change at page 57, line 36 ¶		skipping to change at page 68, line 28 ¶
	Device Information</title>		Device Information</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Additional Data related to an Emergency Call</h1>		<h1>Namespace for Additional Data related to an Emergency Call</h1>
	<h2>Device Information</h2>		<h2>Device Information</h2>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo		9.5.5. Registration for
			urn:ietf:params:xml:ns:emergencycalldata:subinfo
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCall.SubInfo		URI: urn:ietf:params:xml:ns:emergencycalldata: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:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 58, line 22 ¶		skipping to change at page 69, line 16 ¶
	Owner/Subscriber Information</title>		Owner/Subscriber Information</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for Additional Data related to an Emergency Call</h1>		<h1>Namespace for Additional Data related to an Emergency Call</h1>
	<h2> Owner/Subscriber Information</h2>		<h2> Owner/Subscriber Information</h2>
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment		9.5.6. Registration for
			urn:ietf:params:xml:ns:emergencycalldata:comment
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI: urn:ietf:params:xml:ns:emergencyCall.Comment		URI: urn:ietf:params:xml:ns:emergencycalldata:comment
	Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as		Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
	delegated by the IESG <iesg@ietf.org>.		delegated by the IESG <iesg@ietf.org>.
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 59, line 12 ¶		skipping to change at page 70, line 10 ¶
	<p>See [TBD: This document].</p>		<p>See [TBD: This document].</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.6. Schema Registrations		9.6. Schema Registrations
	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:emergencycalldata:providerinfo
	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 14.		XML: The XML schema can be found in Figure 15.
	URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo		URI: urn:ietf:params:xml:schema:emergencycalldata:svcinfo
	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 15.		XML: The XML schema can be found in Figure 16.
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:emergencycalldata:devinfo
	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 16.		XML: The XML schema can be found in Figure 17.
	URI: urn:ietf:params:xml:schema:additional-		URI: urn:ietf:params:xml:schema:emergencycalldata: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:emergencycalldata:comment
	data:emergencyCall.Comment
	Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as		Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
	delegated by the IESG (iesg@ietf.org).		delegated by the IESG (iesg@ietf.org).
	XML: The XML schema can be found in Section 6.5.		XML: The XML schema can be found in Section 6.5.
	9.7. VCard Parameter Value Registration		9.7. VCard Parameter Value Registration
	This document registers a new value in the vCARD Parameter Values		This document registers a new value in the vCARD Parameter Values
	registry as defined by [RFC6350] with the following template:		registry as defined by [RFC6350] with the following template:
	skipping to change at page 61, line 42 ¶		skipping to change at page 72, line 37 ¶
	Initiation Protocol (SIP)", RFC 5621, September 2009.		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.gellens-negotiating-human-language]
			Randy, R., "Negotiating Human Language Using SDP", draft-
			gellens-negotiating-human-language-02 (work in progress),
			February 2013.
			[I-D.ietf-ecrit-psap-callback]
			Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
			Patel, "Public Safety Answering Point (PSAP) Callback",
			draft-ietf-ecrit-psap-callback-13 (work in progress),
			October 2013.
	[I-D.ietf-geopriv-relative-location]		[I-D.ietf-geopriv-relative-location]
	Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.		Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.
	Thomson, "Relative Location Representation", draft-ietf-		Thomson, "Relative Location Representation", draft-ietf-
	geopriv-relative-location-08 (work in progress), September		geopriv-relative-location-08 (work in progress), September
	2013.		2013.
			[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
			"Indicating User Agent Capabilities in the Session
			Initiation Protocol (SIP)", RFC 3840, August 2004.
	[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		[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
	Format for Presence Information Data Format Location		Format for Presence Information Data Format Location
	Object (PIDF-LO)", RFC 5139, February 2008.		Object (PIDF-LO)", RFC 5139, 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
End of changes. 201 change blocks.
	285 lines changed or deleted		757 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/