< draft-ietf-ecrit-additional-data-24.txt		draft-ietf-ecrit-additional-data-25.txt >
	ECRIT R. Gellens		ECRIT R. Gellens
	Internet-Draft Qualcomm Technologies, Inc.		Internet-Draft Qualcomm Technologies, Inc.
	Intended status: Standards Track B. Rosen		Intended status: Standards Track B. Rosen
	Expires: April 16, 2015 NeuStar		Expires: June 6, 2015 NeuStar
	H. Tschofenig		H. Tschofenig
	(no affiliation)		(no affiliation)
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	J. Winterbottom		J. Winterbottom
	(no affiliation)		(no affiliation)
	October 13, 2014		December 3, 2014
	Additional Data related to an Emergency Call		Additional Data related to an Emergency Call
	draft-ietf-ecrit-additional-data-24.txt		draft-ietf-ecrit-additional-data-25.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 16, 2015.		This Internet-Draft will expire on June 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4.1.1. Data Provider String . . . . . . . . . . . . . . . . 8		4.1.1. Data Provider String . . . . . . . . . . . . . . . . 8
	4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9		4.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 9
	4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 9		4.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 9
	4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 10		4.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 10
	4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 11		4.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 11
	4.1.6. Data Provider Languages(s) Supported . . . . . . . . 11		4.1.6. Data Provider Languages(s) Supported . . . . . . . . 11
	4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 12		4.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 12
	4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12		4.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12
	4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 13		4.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 13
	4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13		4.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13
	4.2. Service Information . . . . . . . . . . . . . . . . . . . 15		4.2. Service Information . . . . . . . . . . . . . . . . . . . 16
	4.2.1. Service Environment . . . . . . . . . . . . . . . . . 16		4.2.1. Service Environment . . . . . . . . . . . . . . . . . 16
	4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 16		4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 17
	4.2.3. Service Mobility Environment . . . . . . . . . . . . 18		4.2.3. Service Mobility Environment . . . . . . . . . . . . 19
	4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 18		4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 19
	4.3. Device Information . . . . . . . . . . . . . . . . . . . 19		4.3. Device Information . . . . . . . . . . . . . . . . . . . 20
	4.3.1. Device Classification . . . . . . . . . . . . . . . . 19		4.3.1. Device Classification . . . . . . . . . . . . . . . . 20
	4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 21		4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 22
	4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 21		4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 22
	4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 21		4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 22
	4.3.5. Device/Service Specific Additional Data Structure . . 22		4.3.5. Device/Service Specific Additional Data Structure . . 23
	4.3.6. Device/Service Specific Additional Data Structure		4.3.6. Device/Service Specific Additional Data Structure
	Type . . . . . . . . . . . . . . . . . . . . . . . . 23		Type . . . . . . . . . . . . . . . . . . . . . . . . 24
	4.3.7. Issues with getting new types of data into use . . . 23		4.3.7. Issues with getting new types of data into use . . . 24
	4.3.8. Choosing between defining a new type of block or new		4.3.8. Choosing between defining a new type of block or new
	type of device/service specific additional data . . . 24		type of device/service specific additional data . . . 25
	4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 25		4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 26
	4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 25		4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 26
	4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 25		4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 26
	4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 26		4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 27
	4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 26		4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 27
	4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 29		4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 30
	4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 29		4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 30
	4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 29		4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 30
	5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 29		5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 30
	5.1. Transmitting Blocks using the Call-Info Header . . . . . 31		5.1. Transmitting Blocks using the Call-Info Header . . . . . 32
	5.2. Transmitting Blocks by Reference using the Provided-By		5.2. Transmitting Blocks by Reference using the provided-by
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.3. Transmitting Blocks by Value using the Provided-By
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 33		Element . . . . . . . . . . . . . . . . . . . . . . . . . 33
	5.4. The Content-Disposition Parameter . . . . . . . . . . . . 34		5.3. Transmitting Blocks by Value using the provided-by
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35		Element . . . . . . . . . . . . . . . . . . . . . . . . . 34
	7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 47		5.4. The Content-Disposition Parameter . . . . . . . . . . . . 35
	7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 47		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 49		7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 48
	7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 50		7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 48
	7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 51		7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 50
	7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 52		7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 51
	7.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 53		7.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 52
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 56		7.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 53
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 57		7.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 54
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60		8. Security Considerations . . . . . . . . . . . . . . . . . . . 57
	10.1. Registry creation . . . . . . . . . . . . . . . . . . . 60		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58
	10.1.1. Provider ID Series Registry . . . . . . . . . . . . 60		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
	10.1.2. Service Environment Registry . . . . . . . . . . . . 61		10.1. Registry creation . . . . . . . . . . . . . . . . . . . 61
	10.1.3. Service Type Registry . . . . . . . . . . . . . . . 61		10.1.1. Provider ID Series Registry . . . . . . . . . . . . 61
	10.1.4. Service Mobility Registry . . . . . . . . . . . . . 62		10.1.2. Service Environment Registry . . . . . . . . . . . . 62
	10.1.5. Service Provider Type Registry . . . . . . . . . . . 62		10.1.3. Service Type Registry . . . . . . . . . . . . . . . 62
	10.1.6. Service Delivered Registry . . . . . . . . . . . . . 63		10.1.4. Service Mobility Registry . . . . . . . . . . . . . 63
	10.1.7. Device Classification Registry . . . . . . . . . . . 63		10.1.5. Service Provider Type Registry . . . . . . . . . . . 63
	10.1.8. Device ID Type Type Registry . . . . . . . . . . . . 63		10.1.6. Service Delivered Registry . . . . . . . . . . . . . 64
	10.1.9. Device/Service Data Type Registry . . . . . . . . . 64		10.1.7. Device Classification Registry . . . . . . . . . . . 64
	10.1.10. Emergency Call Data Types Registry . . . . . . . . . 64		10.1.8. Device ID Type Type Registry . . . . . . . . . . . . 64
	10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 65		10.1.9. Device/Service Data Type Registry . . . . . . . . . 65
			10.1.10. Emergency Call Data Types Registry . . . . . . . . . 65
			10.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 66
	10.3. URN Sub-Namespace Registration for provided-by Registry		10.3. URN Sub-Namespace Registration for provided-by Registry
	Entry . . . . . . . . . . . . . . . . . . . . . . . . . 65		Entry . . . . . . . . . . . . . . . . . . . . . . . . . 66
	10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 66		10.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 67
	10.4.1. MIME Content-type Registration for		10.4.1. MIME Content-type Registration for
	'application/EmergencyCallData.ProviderInfo+xml' . . 66		'application/EmergencyCallData.ProviderInfo+xml' . . 67
	10.4.2. MIME Content-type Registration for		10.4.2. MIME Content-type Registration for
	'application/EmergencyCallData.ServiceInfo+xml' . . 67		'application/EmergencyCallData.ServiceInfo+xml' . . 68
	10.4.3. MIME Content-type Registration for		10.4.3. MIME Content-type Registration for
	'application/EmergencyCallData.DeviceInfo+xml' . . . 68		'application/EmergencyCallData.DeviceInfo+xml' . . . 69
	10.4.4. MIME Content-type Registration for		10.4.4. MIME Content-type Registration for
	'application/EmergencyCallData.SubscriberInfo+xml' . 69		'application/EmergencyCallData.SubscriberInfo+xml' . 70
	10.4.5. MIME Content-type Registration for		10.4.5. MIME Content-type Registration for
	'application/EmergencyCallData.Comment+xml' . . . . 70		'application/EmergencyCallData.Comment+xml' . . . . 71
	10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 71		10.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 72
	10.5.1. Registration for		10.5.1. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 71		urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 72
	10.5.2. Registration for		10.5.2. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf		urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf
	o . . . . . . . . . . . . . . . . . . . . . . . . . 72		o . . . . . . . . . . . . . . . . . . . . . . . . . 73
	10.5.3. Registration for		10.5.3. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 73		urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 74
	10.5.4. Registration for		10.5.4. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 74		urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 75
	10.5.5. Registration for		10.5.5. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI		urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI
	nfo . . . . . . . . . . . . . . . . . . . . . . . . 75		nfo . . . . . . . . . . . . . . . . . . . . . . . . 76
	10.5.6. Registration for		10.5.6. Registration for
	urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 76		urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 77
	10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 77		10.6. Schema Registrations . . . . . . . . . . . . . . . . . . 78
	10.7. VCard Parameter Value Registration . . . . . . . . . . . 78		10.7. VCard Parameter Value Registration . . . . . . . . . . . 79
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 79		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
	12.1. Normative References . . . . . . . . . . . . . . . . . . 79		12.1. Normative References . . . . . . . . . . . . . . . . . . 80
	12.2. Informational References . . . . . . . . . . . . . . . . 80		12.2. Informational References . . . . . . . . . . . . . . . . 81
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 81		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 81		Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 82
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
	1. Introduction		1. Introduction
	When an IP-based emergency call is initiated, a rich set of data from		When an IP-based emergency call is initiated, a rich set of data from
	multiple data sources is conveyed to the Public Safety Answering		multiple data sources is conveyed to the Public Safety Answering
	Point (PSAP). This data includes information about the calling party		Point (PSAP). This data includes information about the calling party
	identity, the multimedia capabilities of the device, the request for		identity, the multimedia capabilities of the device, the request for
	emergency services, location information, and meta-data about the		emergency services, location information, and meta-data about the
	sources of the data. The device, the access network provider, and		sources of the data. The device, the access network provider, and
	any service provider in the call path may have even more information		any service provider in the call path may have even more information
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 35 ¶
	4.1. Data Provider Information		4.1. Data Provider Information
	This block is intended to be supplied by any service provider in the		This block is intended to be supplied by any service provider in the
	path of the call or the access network provider. It includes		path of the call or the access network provider. It includes
	identification and contact information. This block SHOULD be		identification and contact information. This block SHOULD be
	supplied by every service provider in the call path, and by the		supplied by every service provider in the call path, and by the
	access network provider. Devices MAY use this block to provide		access network provider. Devices MAY use this block to provide
	identifying information. The MIME subtype is "application/		identifying information. The MIME subtype is "application/
	EmergencyCallData.ProviderInfo+xml". An access network provider		EmergencyCallData.ProviderInfo+xml". An access network provider
	SHOULD provide this block either by value or by reference in the		SHOULD provide this block either by value or by reference in the
	Provided-By section of a PIDF-LO		provided-by section of a PIDF-LO
	4.1.1. Data Provider String		4.1.1. Data Provider String
	Data Element: Data Provider String		Data Element: Data Provider String
	Use: Required		Use: Required
	XML Element: <DataProviderString>		XML Element: <DataProviderString>
	Description: This is a plain text string suitable for displaying the		Description: This is a plain text string suitable for displaying the
	skipping to change at page 12, line 25 ¶		skipping to change at page 12, line 25 ¶
	(depending on the urgency and the type of interaction).		(depending on the urgency and the type of interaction).
	4.1.7. xCard of Data Provider		4.1.7. xCard of Data Provider
	Data Element: xCard of Data Provider		Data Element: xCard of Data Provider
	Use: Optional		Use: Optional
	XML Element: <DataProviderContact>		XML Element: <DataProviderContact>
	Description: There are many fields in the xCard and the creator of		Description: Per [RFC6351] the xcard structure is represented within
	the data structure is encouraged to provide as much information as		a <vcard> element, which is a child element of a <vcards> element.
	they have available. N, ORG, ADR, TEL, EMAIL are suggested at a		The fact that a <vcard> element is contained within a <vcards>
	minimum. N SHOULD contain the name of the support group or device		element structurally permits multiple <vcard> elements, however,
	owner as appropriate. If more than one TEL property is provided,		only one <vcard> element SHOULD be provided. If more than one
	a parameter from the vCard Property Value registry MUST be		appears, the first SHOULD be used. There are many fields in the
	specified on each TEL. For encoding of the xCard this		xCard and the creator of the data structure is encouraged to
	specification uses the XML-based encoding specified in [RFC6351],		provide as much information as they have available. N, ORG, ADR,
	referred to in this document as "xCard"		TEL, EMAIL are suggested at a minimum. N SHOULD contain the name
			of the support group or device owner as appropriate. If more than
			one TEL property is provided, a parameter from the vCard Property
			Value registry MUST be specified on each TEL. For encoding of the
			xCard this specification uses the XML-based encoding specified in
			[RFC6351], referred to in this document as "xCard".
	Reason for Need: Information needed to determine additional contact		Reason for Need: Information needed to determine additional contact
	information.		information.
	How Used by Call Taker: Assists the call taker by providing		How Used by Call Taker: Assists the call taker by providing
	additional contact information aside from what may be included in		additional contact information aside from what may be included in
	the SIP INVITE or the PIDF-LO.		the SIP INVITE or the PIDF-LO.
	4.1.8. Subcontractor Principal		4.1.8. Subcontractor Principal
	skipping to change at page 13, line 47 ¶		skipping to change at page 14, line 5 ¶
	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.
	4.1.10. ProviderInfo Example		4.1.10. ProviderInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ad:EmergencyCallData.ProviderInfo		<ad:EmergencyCallData.ProviderInfo
	xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData: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:DataProviderReference>string0987654321@example.org		<ad:DataProviderReference>string0987654321@example.org
	</ad:DataProviderReference>		</ad:DataProviderReference>
	<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>Telecom Provider</ad:TypeOfProvider>		<ad:TypeOfProvider>Telecom Provider</ad:TypeOfProvider>
	<ad:ContactURI>tel:+1-201-555-0123</ad:ContactURI>		<ad:ContactURI>tel:+1-201-555-0123</ad:ContactURI>
	<ad:Language>EN</ad:Language>		<ad:Language>EN</ad:Language>
	<ad:DataProviderContact		<ad:DataProviderContact
	xmlns="urn:ietf:params:xml:ns:vcard-4.0">		xmlns="urn:ietf:params:xml:ns:vcard-4.0">
			<vcards>
	<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 15, line 42 ¶		skipping to change at page 15, line 47 ¶
	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>
			</vcards>
	</ad:DataProviderContact>		</ad:DataProviderContact>
	</ad:EmergencyCallData.ProviderInfo>		</ad:EmergencyCallData.ProviderInfo>
	Figure 2: EmergencyCallData.ProviderInfo Example.		Figure 2: EmergencyCallData.ProviderInfo Example.
	4.2. Service Information		4.2. Service Information
	This block describes the service that the service provider provides		This block describes the service that the service provider provides
	to the caller. It SHOULD be included by all SPs in the path of the		to the caller. It SHOULD be included by all SPs in the path of the
	call. The mime subtype is "application/		call. The mime subtype is "application/
	skipping to change at page 19, line 6 ¶		skipping to change at page 20, line 6 ¶
	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.
	4.2.4. EmergencyCallData.ServiceInfo Example		4.2.4. EmergencyCallData.ServiceInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<svc:EmergencyCallData.ServiceInfo		<svc:EmergencyCallData.ServiceInfo
	xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData.ServiceInfo"		xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org		<svc:DataProviderReference>2468.IBOC.MLTS.1359@example.org
	</svc:DataProviderReference>		</svc:DataProviderReference>
	<svc:id>12345</svc:id>
	<svc:ServiceEnvironment>Business</svc:ServiceEnvironment>		<svc:ServiceEnvironment>Business</svc:ServiceEnvironment>
	<svc:ServiceType>MLTS-hosted</svc:ServiceType>		<svc:ServiceType>MLTS-hosted</svc:ServiceType>
	<svc:ServiceMobility>Fixed</svc:ServiceMobility>		<svc:ServiceMobility>Fixed</svc:ServiceMobility>
	</svc:EmergencyCallData.ServiceInfo>		</svc:EmergencyCallData.ServiceInfo>
	Figure 4: EmergencyCallData.ServiceInfo Example.		Figure 4: EmergencyCallData.ServiceInfo Example.
	4.3. Device Information		4.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
	skipping to change at page 25, line 18 ¶		skipping to change at page 26, line 18 ¶
	(CID).		(CID).
	4.3.9. EmergencyCallData.DeviceInfo Example		4.3.9. EmergencyCallData.DeviceInfo Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<dev:EmergencyCallData.DeviceInfo		<dev:EmergencyCallData.DeviceInfo
	xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"		xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<dev:DataProviderReference>d4b3072df.201409182208075@example.org		<dev:DataProviderReference>d4b3072df.201409182208075@example.org
	</dev:DataProviderReference>		</dev:DataProviderReference>
	<dev:id>12345</dev:id>
	<dev:DeviceClassification>fixed</dev:DeviceClassification>		<dev:DeviceClassification>fixed</dev:DeviceClassification>
	<dev:DeviceMfgr>Nokia</dev:DeviceMfgr>		<dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
	<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>		<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
	<dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104		<dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104
	</dev:UniqueDeviceID>		</dev:UniqueDeviceID>
	</dev:EmergencyCallData.DeviceInfo>		</dev:EmergencyCallData.DeviceInfo>
	Figure 7: EmergencyCallData.DeviceInfo Example.		Figure 7: EmergencyCallData.DeviceInfo Example.
	4.4. Owner/Subscriber Information		4.4. Owner/Subscriber Information
	skipping to change at page 29, line 38 ¶		skipping to change at page 30, line 34 ¶
	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.
	4.5.2. EmergencyCallData.Comment Example		4.5.2. EmergencyCallData.Comment Example
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<com:EmergencyCallData.Comment		<com:EmergencyCallData.Comment
	xmlns:sub="urn:ietf:params:xml:ns:EmergencyCallData:Comment"		xmlns:com="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">
	<com:DataProviderReference>string0987654321@example.org		<com:DataProviderReference>string0987654321@example.org
	</com:DataProviderReference>		</com:DataProviderReference>
	<com:Comment xml:lang="en">This is an example text.</com:Comment>		<com:Comment xml:lang="en">This is an example text.</com:Comment>
	</com:EmergencyCallData.Comment>		</com:EmergencyCallData.Comment>
	Figure 9: EmergencyCallData.Comment Example.		Figure 9: EmergencyCallData.Comment Example.
	5. Data Transport Mechanisms		5. Data Transport Mechanisms
	skipping to change at page 30, line 42 ¶		skipping to change at page 31, line 40 ¶
	may be encoded in XML or not, as identified by their MIME		may be encoded in XML or not, as identified by their MIME
	registration.) As usual, whenever more than one MIME part is		registration.) As usual, whenever more than one MIME part is
	included in the body of a message, MIME-multipart (i.e.,		included in the body of a message, MIME-multipart (i.e.,
	'multipart/mixed') encloses them all. This document defines a		'multipart/mixed') encloses them all. This document defines a
	set of XML schemas and MIME types used for each block defined		set of XML schemas and MIME types used for each block defined
	here. When additional data is passed by value in the SIP		here. When additional data is passed by value in the SIP
	signaling, each CID URL points to one block in the body.		signaling, each CID URL points to one block in the body.
	Multiple URIs are used within a Call-Info header field (or		Multiple URIs are used within a Call-Info header field (or
	multiple Call-Info header fields) to point to multiple blocks.		multiple Call-Info header fields) to point to multiple blocks.
	When additional data is provided by reference (in SIP signaling		When additional data is provided by reference (in SIP signaling
	or Provided-By), each HTTPS URL references one block; the data is		or provided-by), each HTTPS URL references one block; the data is
	retrieved with an HTTPS GET operation, which returns one of the		retrieved with an HTTPS GET operation, which returns one of the
	blocks as an object (the blocks defined here are returned as XML		blocks as an object (the blocks defined here are returned as XML
	objects).		objects).
	2. Second, the ability to embed additional data structures in the		2. Second, the ability to embed additional data structures in the
	<provided-by> element of a PIDF-LO [RFC4119] is defined. In		<provided-by> element of a PIDF-LO [RFC4119] is defined. In
	addition to service providers in the call path, the access		addition to service providers in the call path, the access
	network provider may also have similar information that may be		network provider may also have similar information that may be
	valuable to the PSAP. The access network provider MAY provide		valuable to the PSAP. The access network provider MAY provide
	location in the form of a PIDF-LO from a location server via a		location in the form of a PIDF-LO from a location server via a
	skipping to change at page 31, line 25 ¶		skipping to change at page 32, line 22 ¶
	application layer signaling (and hence cannot add a Call-Info		application layer signaling (and hence cannot add a Call-Info
	header field to the SIP message), but may provide location		header field to the SIP message), but may provide location
	information in a PIDF-LO object to assist in locating the		information in a PIDF-LO object to assist in locating the
	caller's device. The <provided-by> element of the PIDF-LO is a		caller's device. The <provided-by> element of the PIDF-LO is a
	mechanism for the access network provider to supply the		mechanism for the access network provider to supply the
	information about the entity or organization that supplied this		information about the entity or organization that supplied this
	location information. For this reason, this document describes a		location information. For this reason, this document describes a
	namespace per RFC 4119 for inclusion in the <provided-by> element		namespace per RFC 4119 for inclusion in the <provided-by> element
	of a PIDF-LO for adding information known to the access network		of a PIDF-LO for adding information known to the access network
	provider. The access network provider SHOULD provide additional		provider. The access network provider SHOULD provide additional
	data within a Provided-By element of a PDIF-LO it returns for		data within a provided-by element of a PDIF-LO it returns for
	emergency use (e.g., if requested with a HELD "responseTime"		emergency use (e.g., if requested with a HELD "responseTime"
	attribute of "emergencyRouting" or "emergencyDispatch"		attribute of "emergencyRouting" or "emergencyDispatch"
	[RFC5985]).		[RFC5985]).
	One or more blocks of data registered in the Emergency Call		One or more blocks of data registered in the Emergency Call
	Additional Data registry, as defined in Section 10.1, may be included		Additional Data registry, as defined in Section 10.1, may be included
	or referenced in the SIP signaling (using the Call-Info header field)		or referenced in the SIP signaling (using the Call-Info header field)
	or in the <provided-by> element of a PIDF-LO. Every block must be		or in the <provided-by> element of a PIDF-LO. Every block must be
	one of the types in the registry. Since the data of an emergency		one of the types in the registry. Since the data of an emergency
	call may come from multiple sources, the data itself needs		call may come from multiple sources, the data itself needs
	skipping to change at page 32, line 36 ¶		skipping to change at page 33, line 34 ¶
	provider is in the path of the call. The device MAY insert one if it		provider is in the path of the call. The device MAY insert one if it
	uses a service provider. Any service provider in the path of the		uses a service provider. Any service provider in the path of the
	call MUST insert its own. For example, a device, a telematics		call MUST insert its own. For example, a device, a telematics
	service provider in the call path, as well as the mobile carrier		service provider in the call path, as well as the mobile carrier
	handling the call will each provide one. There may be circumstances		handling the call will each provide one. There may be circumstances
	where there is a service provider who is unaware that the call is an		where there is a service provider who is unaware that the call is an
	emergency call and cannot reasonably be expected to determine that it		emergency call and cannot reasonably be expected to determine that it
	is an emergency call. In that case, that service provider is not		is an emergency call. In that case, that service provider is not
	expected to provide EmergencyCallData.		expected to provide EmergencyCallData.
	5.2. Transmitting Blocks by Reference using the Provided-By Element		5.2. Transmitting Blocks by Reference using the provided-by Element
	The 'EmergencyCallDataReference' element is used to transmit an		The 'EmergencyCallDataReference' element is used to transmit an
	additional data block by reference within a 'Provided-By' element of		additional data block by reference within a 'provided-by' element of
	a PIDF-LO. The 'EmergencyCallDataReference' element has two		a PIDF-LO. The 'EmergencyCallDataReference' element has two
	attributes: 'ref' to specify the URL, and 'purpose' to indicate the		attributes: 'ref' to specify the URL, and 'purpose' to indicate the
	type of data block referenced. The value of 'ref' is an HTTPS URL		type of data block referenced. The value of 'ref' is an HTTPS URL
	that resolves to a data structure with information about the call.		that resolves to a data structure with information about the call.
	The value of 'purpose' is the same as used in a 'Call-Info' header		The value of 'purpose' is the same as used in a 'Call-Info' header
	field (as specified in Section 5.1).		field (as specified in Section 5.1).
	For example, to reference a block with MIME type 'application/		For example, to reference a block with MIME type 'application/
	EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set		EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set
	to 'EmergencyCallData.ProviderInfo'. An example		to 'EmergencyCallData.ProviderInfo'. An example
	skipping to change at page 33, line 14 ¶		skipping to change at page 34, line 11 ¶
	<EmergencyCallDataReference ref="https://www.example.com/23sedde3"		<EmergencyCallDataReference ref="https://www.example.com/23sedde3"
	purpose="EmergencyCallData.ProviderInfo"/>		purpose="EmergencyCallData.ProviderInfo"/>
	The 'EmergencyCallDataReference' element transmits one additional		The 'EmergencyCallDataReference' element transmits one additional
	data block; multiple additional data blocks may be transmitted by		data block; multiple additional data blocks may be transmitted by
	using multiple 'EmergencyCallDataReference' elements.		using multiple 'EmergencyCallDataReference' elements.
	For example:		For example:
	<provided-by		<gp:provided-by
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">		xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
	<ad:DataProviderReference>flurbit735@es.example.com
	</ad:DataProviderReference>
	<ad:EmergencyCallDataReference		<ad:EmergencyCallDataReference
	purpose="EmergencyCallData.ServiceInfo"		purpose="EmergencyCallData.ServiceInfo"
	ref="https://example.com/ref2" />		ref="https://example.com/ref2" />
	<ad:EmergencyCallDataReference		<ad:EmergencyCallDataReference
	purpose="EmergencyCallData.ProviderInfo"		purpose="EmergencyCallData.ProviderInfo"
	ref="https://example.com/ref3" />		ref="https://example.com/ref3" />
	<ad:EmergencyCallDataReference		<ad:EmergencyCallDataReference
	purpose="EmergencyCallData.Comment"		purpose="EmergencyCallData.Comment"
	ref="https://example.com/ref4" />		ref="https://example.com/ref4" />
	</provided-by>		</gp:provided-by>
	Example Provided-By by Reference.		Example provided-by by Reference.
	5.3. Transmitting Blocks by Value using the Provided-By Element		5.3. Transmitting Blocks by Value using the provided-by Element
	It is RECOMMENDED that access networks supply the data specified in		It is RECOMMENDED that access networks supply the data specified in
	this document by reference, but they MAY provide the data by value.		this document by reference, but they MAY provide the data by value.
	The 'EmergencyCallDataValue' element is used to transmit one or more		The 'EmergencyCallDataValue' element is used to transmit one or more
	additional data blocks by value within a 'Provided-By' element of a		additional data blocks by value within a 'provided-by' element of a
	PIDF-LO. Each block being transmitted is placed (as a child element)		PIDF-LO. Each block being transmitted is placed (as a child element)
	inside the 'EmergencyCallDataValue' element. (The same XML structure		inside the 'EmergencyCallDataValue' element. (The same XML structure
	as would be contained in the corresponding MIME type body part is		as would be contained in the corresponding MIME type body part is
	placed inside the 'EmergencyCallDataValue' element.)		placed inside the 'EmergencyCallDataValue' element.)
	For example:		For example:
	<provided-by		<gp:provided-by
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">		xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
	<EmergencyCallDataValue>		<EmergencyCallDataValue>
	<EmergencyCallData.ProviderInfo		<EmergencyCallData.ProviderInfo
	xmlns=		xmlns=
	"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">		"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
	<DataProviderReference>flurbit735@es.example.com		<DataProviderReference>flurbit735@es.example.com
	</DataProviderReference>		</DataProviderReference>
	<DataProviderString>Access Network Examples, Inc		<DataProviderString>Access Network Examples, Inc
	</DataProviderString>		</DataProviderString>
	<ProviderID>urn:nena:companyid:Test</ProviderID>		<ProviderID>urn:nena:companyid:Test</ProviderID>
	<ProviderIDSeries>NENA</ProviderIDSeries>		<ProviderIDSeries>NENA</ProviderIDSeries>
	<TypeOfProvider>Access Network Provider		<TypeOfProvider>Access Network Provider
	</TypeOfProvider>		</TypeOfProvider>
	<ContactURI>tel:+1 555-555-0897</ContactURI>		<ContactURI>tel:+1-555-555-0897</ContactURI>
	<Language>EN</Language>		<Language>EN</Language>
	</EmergencyCallData.ProviderInfo>		</EmergencyCallData.ProviderInfo>
	<EmergencyCallData.Comment		<EmergencyCallData.Comment
	xmlns=		xmlns=
	"urn:ietf:params:xml:ns:EmergencyCallData:Comment">		"urn:ietf:params:xml:ns:EmergencyCallData:Comment">
	<DataProviderReference>flurbit735@es.example.com		<DataProviderReference>flurbit735@es.example.com
	</DataProviderReference>		</DataProviderReference>
	<Comment xml:lang="en">This is an example text.		<Comment xml:lang="en">This is an example text.
	</Comment>		</Comment>
	</EmergencyCallData.Comment>		</EmergencyCallData.Comment>
	</EmergencyCallDataValue>		</EmergencyCallDataValue>
	</provided-by>		</gp:provided-by>
	Example Provided-By by Value.		Example provided-by by Value.
	5.4. The Content-Disposition Parameter		5.4. The Content-Disposition Parameter
	RFC 5621 [RFC5621] discusses the handling of message bodies in SIP.		RFC 5621 [RFC5621] discusses the handling of message bodies in SIP.
	It updates and clarifies handling originally defined in RFC 3261		It updates and clarifies handling originally defined in RFC 3261
	[RFC3261] based on implementation experience. While RFC 3261 did not		[RFC3261] based on implementation experience. While RFC 3261 did not
	mandate support for 'multipart' message bodies, 'multipart/mixed'		mandate support for 'multipart' message bodies, 'multipart/mixed'
	MIME bodies are used by many extensions (including this document)		MIME bodies are used by many extensions (including this document)
	today. For example, adding a PIDF-LO, SDP, and additional data in		today. For example, adding a PIDF-LO, SDP, and additional data in
	body of a SIP message requires a 'multipart' message body.		body of a SIP message requires a 'multipart' message body.
	skipping to change at page 37, line 49 ¶		skipping to change at page 38, line 49 ¶
	--boundary1--		--boundary1--
	Content-Type: application/EmergencyCallData.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"?>		<?xml version="1.0" encoding="UTF-8"?>
	<pi:EmergencyCallData.ProviderInfo		<pi:EmergencyCallData.ProviderInfo
	xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"		xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<pi:id>12345</pi:id>
	<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]		<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
	</pi:DataProviderReference>		</pi:DataProviderReference>
	<pi:DataProviderString>Hannes Tschofenig		<pi:DataProviderString>Hannes Tschofenig
	</pi:DataProviderString>		</pi:DataProviderString>
	<pi:TypeOfProvider>Other</pi:TypeOfProvider>		<pi:TypeOfProvider>Other</pi:TypeOfProvider>
	<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>		<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
	<pi:Language>EN</pi:Language>		<pi:Language>EN</pi:Language>
	<xc:DataProviderContact		<xc:DataProviderContact
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcards>
	<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 39, line 37 ¶		skipping to change at page 40, line 37 ¶
	</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://example.com/hannes.tschofenig		<uri>http://example.com/hannes.tschofenig
	</uri>		</uri>
	</url>		</url>
	</vcard>		</vcard>
			</vcards>
	</xc:DataProviderContact>		</xc:DataProviderContact>
	</pi:EmergencyCallData.ProviderInfo>		</pi:EmergencyCallData.ProviderInfo>
	--boundary1--		--boundary1--
	Figure 12: End Device sending SIP INVITE with Additional Data.		Figure 12: End Device sending SIP INVITE with Additional Data.
	In this example, information available to the access network provider		In this example, information available to the access network provider
	is included in the call setup message only indirectly via the use of		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		the location reference. The PSAP has to retrieve it via a separate
	look-up step. Since the access network provider and the VoIP service		look-up step. Since the access network provider and the VoIP service
	skipping to change at page 41, line 37 ¶		skipping to change at page 42, line 39 ¶
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]		<pi:DataProviderReference>d4b3072df09876543@[93.184.216.119]
	</pi:DataProviderReference>		</pi:DataProviderReference>
	<pi:DataProviderString>Hannes Tschofenig		<pi:DataProviderString>Hannes Tschofenig
	</pi:DataProviderString>		</pi:DataProviderString>
	<pi:TypeOfProvider>Other</pi:TypeOfProvider>		<pi:TypeOfProvider>Other</pi:TypeOfProvider>
	<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>		<pi:ContactURI>tel:+1-555-555-0123</pi:ContactURI>
	<pi:Language>EN</pi:Language>		<pi:Language>EN</pi:Language>
	<xc:DataProviderContact		<xc:DataProviderContact
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcards>
	<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 43, line 15 ¶		skipping to change at page 44, line 18 ¶
	</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://example.com/hannes.tschofenig		<uri>http://example.com/hannes.tschofenig
	</uri>		</uri>
	</url>		</url>
	</vcard>		</vcard>
			</vcards>
	</xc:DataProviderContact>		</xc:DataProviderContact>
	</pi:EmergencyCallData.ProviderInfo>		</pi:EmergencyCallData.ProviderInfo>
	--boundary1--		--boundary1--
	Content-Type: application/EmergencyCallData.ServiceInfo+xml		Content-Type: application/EmergencyCallData.ServiceInfo+xml
	Content-ID: <bloorpyhex@atlanta.example.com>		Content-ID: <bloorpyhex@atlanta.example.com>
	Content-Disposition: by-reference;handling=optional		Content-Disposition: by-reference;handling=optional
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<svc:EmergencyCallData.ServiceInfo		<svc:EmergencyCallData.ServiceInfo
	xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData.ServiceInfo"		xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<svc:DataProviderReference>string0987654321@example.org		<svc:DataProviderReference>string0987654321@example.org
	</svc:DataProviderReference>		</svc:DataProviderReference>
	<svc:ServiceEnvironment>Residence</svc:ServiceEnvironment>		<svc:ServiceEnvironment>Residence</svc:ServiceEnvironment>
	<svc:ServiceType>VOIP</svc:ServiceType>		<svc:ServiceType>VOIP</svc:ServiceType>
	<svc:ServiceMobility>Unknown</svc:ServiceMobility>		<svc:ServiceMobility>Unknown</svc:ServiceMobility>
	</svc:EmergencyCallData.ServiceInfo>		</svc:EmergencyCallData.ServiceInfo>
	--boundary1--		--boundary1--
	skipping to change at page 44, line 6 ¶		skipping to change at page 45, line 10 ¶
	</pi:DataProviderReference>		</pi:DataProviderReference>
	<pi:DataProviderString>Example VoIP Provider		<pi:DataProviderString>Example VoIP Provider
	</pi:DataProviderString>		</pi:DataProviderString>
	<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>		<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
	<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>		<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
	<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>		<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>
	<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>		<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>
	<pi:Language>EN</pi:Language>		<pi:Language>EN</pi:Language>
	<xc:DataProviderContact		<xc:DataProviderContact
	xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">		xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
			<vcards>
	<vcard>		<vcard>
	<fn><text>John Doe</text></fn>		<fn><text>John Doe</text></fn>
	<n>		<n>
	<surname>John</surname>		<surname>John</surname>
	<given>Doe</given>		<given>Doe</given>
	<additional/>		<additional/>
	<prefix/>		<prefix/>
	<suffix/>		<suffix/>
	</n>		</n>
	<bday><date>--0203</date></bday>		<bday><date>--0203</date></bday>
	skipping to change at page 45, line 23 ¶		skipping to change at page 46, line 28 ¶
	</parameters>		</parameters>
	<uri>geo:51.503396, 0.127640</uri>		<uri>geo:51.503396, 0.127640</uri>
	</geo>		</geo>
	<tz><text>Europe/London</text></tz>		<tz><text>Europe/London</text></tz>
	<url>		<url>
	<parameters><type><text>home</text></type>		<parameters><type><text>home</text></type>
	</parameters>		</parameters>
	<uri>http://www.example.com/john.doe</uri>		<uri>http://www.example.com/john.doe</uri>
	</url>		</url>
	</vcard>		</vcard>
			</vcards>
	</xc:DataProviderContact>		</xc:DataProviderContact>
	</pi:EmergencyCallData.ProviderInfo>		</pi:EmergencyCallData.ProviderInfo>
	Figure 13: VoIP Provider sending SIP INVITE with Additional Data.		Figure 13: VoIP Provider sending SIP INVITE with Additional Data.
	Finally, the PSAP requests location information from the access		Finally, the PSAP requests location information from the access
	network provider. The response is shown in Figure 14. Along with		network provider. The response is shown in Figure 14. Along with
	the location information, additional data is provided in the		the location information, additional data is provided in the
	<Provided-By> element of the PIDF-LO. This request and response is		<provided-by> element of the PIDF-LO. This request and response is
	step #4.		step #4.
	<?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>
	skipping to change at page 46, line 22 ¶		skipping to change at page 47, line 28 ¶
	</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-12-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		<gp:provided-by
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">		xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
	<EmergencyCallDataReference		<EmergencyCallDataReference
	purpose="EmergencyCallData.ServiceInfo"		purpose="EmergencyCallData.ServiceInfo"
	ref="https://example.com/ref2"/>		ref="https://example.com/ref2"/>
	<EmergencyCallDataValue>		<EmergencyCallDataValue>
	<EmergencyCallData.ProviderInfo		<EmergencyCallData.ProviderInfo
	xmlns=		xmlns=
	"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">		"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
	<DataProviderReference>88QV4FpfZ976T@example.com		<DataProviderReference>88QV4FpfZ976T@example.com
	</DataProviderReference>		</DataProviderReference>
	<DataProviderString>University of Example		<DataProviderString>University of Example
	</DataProviderString>		</DataProviderString>
	<ProviderID>urn:nena:companyid:uoi</ProviderID>		<ProviderID>urn:nena:companyid:uoi</ProviderID>
	<ProviderIDSeries>NENA</ProviderIDSeries>		<ProviderIDSeries>NENA</ProviderIDSeries>
	<TypeOfProvider>Other</TypeOfProvider>		<TypeOfProvider>Other</TypeOfProvider>
	<ContactURI>tel:+1 555-824-5222</ContactURI>		<ContactURI>tel:+1-555-824-5222</ContactURI>
	<Language>EN</Language>		<Language>EN</Language>
	</EmergencyCallData.ProviderInfo>		</EmergencyCallData.ProviderInfo>
	<EmergencyCallData.Comment		<EmergencyCallData.Comment
	xmlns="urn:ietf:params:xml:ns:EmergencyCallData:Comment">		xmlns="urn:ietf:params:xml:ns:EmergencyCallData:Comment">
	<DataProviderReference>88QV4FpfZ976T@example.com		<DataProviderReference>88QV4FpfZ976T@example.com
	</DataProviderReference>		</DataProviderReference>
	<Comment xml:lang="en">This is an example text.</Comment>		<Comment xml:lang="en">This is an example text.</Comment>
	</EmergencyCallData.Comment>		</EmergencyCallData.Comment>
	</EmergencyCallDataValue>		</EmergencyCallDataValue>
			</gp:provided-by>
	</provided-by>
	</gp:geopriv>		</gp:geopriv>
	<dm:deviceID>mac:00-0d-4b-30-72-df</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 14: Access Network Provider returning PIDF-LO with Additional		Figure 14: Access Network Provider returning PIDF-LO with Additional
	Data.		Data.
	7. XML Schemas		7. 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.
	7.1. EmergencyCallData.ProviderInfo XML Schema		7.1. EmergencyCallData.ProviderInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace=		targetNamespace=
	"urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"		"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:EmergencyCallData: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"
	skipping to change at page 47, line 48 ¶		skipping to change at page 49, line 7 ¶
	<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="EmergencyCallData.ProviderInfo"		name="EmergencyCallData.ProviderInfo"
	type="pi:ProviderInfoType"/>		type="pi:ProviderInfoType"/>
	<xs:element name="DataProviderReference"
	type="xs:token" minOccurs="1" maxOccurs="1"/>
	<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"		<xs:element name="DataProviderReference"
	type="xs:string" minOccurs="1" maxOccurs="1"/>		type="xs:token" 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="1" maxOccurs="1"/>
	<xs:element name="ProviderIDSeries"		<xs:element name="ProviderIDSeries"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="1" 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="1" maxOccurs="unbounded" />		minOccurs="1" maxOccurs="unbounded" />
	skipping to change at page 53, line 46 ¶		skipping to change at page 54, line 46 ¶
	<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 19: EmergencyCallData.Comment XML Schema.		Figure 19: EmergencyCallData.Comment XML Schema.
	7.6. Provided-By XML Schema		7.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"		"urn:ietf:params:xml:ns:EmergencyCallData"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ad="urn:ietf:params:xml:ns:EmergencyCallData"		xmlns:ad="urn:ietf:params:xml:ns: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:EmergencyCallData:ProviderInfo"		xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"
	xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"		xmlns:svc="urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo"
	xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"		xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"
	xmlns:sub=		xmlns:sub=
	"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"		"urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo"
	xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"		xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	skipping to change at page 55, line 49 ¶		skipping to change at page 56, line 49 ¶
	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 20: Provided-By XML Schema.		Figure 20: provided-by XML Schema.
	8. Security Considerations		8. Security Considerations
	The data structures described in this document contain information		The data structures described in this document contain information
	usually considered private. When information is provided by value,		usually considered private. When information is provided by value,
	entities that are a party to the SIP signaling (such as proxy servers		entities that are a party to the SIP signaling (such as proxy servers
	and back-to-back user agents) will have access to it and need to		and back-to-back user agents) will have access to it and need to
	protect it against inappropriate disclosure. An entity that is able		protect it against inappropriate disclosure. An entity that is able
	to eavesdrop on the SIP signaling will also have access. Some media		to eavesdrop on the SIP signaling will also have access. Some media
	(such as in the clear Wi-Fi) is more vulnerable than others (such as		(such as in the clear Wi-Fi) is more vulnerable than others (such as
	skipping to change at page 78, line 45 ¶		skipping to change at page 79, line 45 ¶
	large number of participants in NENA standardization efforts,		large number of participants in NENA standardization efforts,
	originally in the Long Term Definition Working Group, the Data		originally in the Long Term Definition Working Group, the Data
	Technical Committee and most recently the Additional Data working		Technical Committee and most recently the Additional Data working
	group. The authors are grateful for the initial work and extended		group. The authors are grateful for the initial work and extended
	comments provided by many NENA participants, including Delaine		comments provided by many NENA participants, including Delaine
	Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James		Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
	Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra,		Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra,
	and Robert (Bob) Sherry.		and Robert (Bob) Sherry.
	We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin		We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
	Thomson, Keith Drage, Laura Liess, Chris Santer, and Barbara Stark		Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris
	for their review comments. Guy Caron deserves special mention for		Santer, and Archie Cobbs for their review comments. Guy Caron
	his detailed and extensive review comments.		deserves special mention for his detailed and extensive review
			comments.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, August 1998.		Locators", RFC 2392, August 1998.
End of changes. 65 change blocks.
	132 lines changed or deleted		136 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/