< draft-ietf-ecrit-additional-data-03.txt		draft-ietf-ecrit-additional-data-04.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: September 14, 2012 Nokia Siemens Networks		Expires: January 17, 2013 Nokia Siemens Networks
	R. Marshall		R. Marshall
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	March 13, 2012		July 16, 2012
	Additional Data related to an Emergency Call		Additional Data related to an Emergency Call
	draft-ietf-ecrit-additional-data-03.txt		draft-ietf-ecrit-additional-data-04.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 service provider in		(PSAP), the device that sends it, as well as any service provider in
	the path of the call, or access network may have information about		the path of the call, or access network may have information about
	the call which the PSAP may be able to use. This document describes		the call which the PSAP may be able to use. This document describes
	an XML data structure that contains this kind of information in a		an XML data structure that contains this kind of information in a
	standardized form. A Uniform Resource Identifier (URI) that points		standardized form. A Uniform Resource Identifier (URI) that points
	to the structure can be included in the SIP signaling with the call,		to the structure can be included in the SIP signaling with the call,
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 September 14, 2012.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 16 ¶		skipping to change at page 2, line 16 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 8		3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 8
	4. Data Provider Information . . . . . . . . . . . . . . . . . . 9		4. Data Provider Information . . . . . . . . . . . . . . . . . . 10
	4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 9		4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 10
	4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 9		4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Type of Data Provider ID . . . . . . . . . . . . . . . . . 10		4.3. Type of Data Provider ID . . . . . . . . . . . . . . . . . 11
	4.4. Data Provider Contact URI . . . . . . . . . . . . . . . . 10		4.4. Data Provider Contact URI . . . . . . . . . . . . . . . . 12
	4.5. Data Provider Languages(s) Supported . . . . . . . . . . . 11		4.5. Data Provider Languages(s) Supported . . . . . . . . . . . 12
	4.6. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 12		4.6. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 13
	4.7. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 12		4.7. Subcontractor Principal . . . . . . . . . . . . . . . . . 13
	5. Service Information . . . . . . . . . . . . . . . . . . . . . 14		4.8. Subcontractor Priority . . . . . . . . . . . . . . . . . . 14
	5.1. Service Environment . . . . . . . . . . . . . . . . . . . 14		4.9. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 14
	5.2. Service Delivered by Provider to End User . . . . . . . . 14		5. Service Information . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Service Mobility Environment . . . . . . . . . . . . . . . 16		5.1. Service Environment . . . . . . . . . . . . . . . . . . . 16
	5.4. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 17		5.2. Service Delivered by Provider to End User . . . . . . . . 16
	6. Device Information . . . . . . . . . . . . . . . . . . . . . . 18		5.3. Service Mobility Environment . . . . . . . . . . . . . . . 18
	6.1. Device Classification . . . . . . . . . . . . . . . . . . 18		5.4. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 19
	6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 20		6. Device Information . . . . . . . . . . . . . . . . . . . . . . 20
	6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 20		6.1. Device Classification . . . . . . . . . . . . . . . . . . 20
	6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 21		6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 22
	6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 21		6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 22
	6.6. Device/Service Specific Additional Data Structure . . . . 22		6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 23
	6.7. Device/Service Specific Additional Data Structure Type . . 23		6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 23
	6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 23		6.6. Device/Service Specific Additional Data Structure . . . . 24
	7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 25		6.7. Device/Service Specific Additional Data Structure Type . . 25
	7.1. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 25		6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 25
	7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 25		7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 27
	8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		7.1. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 27
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 28		7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 27
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29		8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		9. Main Telephone Number . . . . . . . . . . . . . . . . . . . . 30
	11.1. Registry creation . . . . . . . . . . . . . . . . . . . . 30		10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	11.1.1. Additional Call Data Service Delivered Registry . . . 30		11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32
	11.1.2. Additional Call Data Device Classification		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	Registry . . . . . . . . . . . . . . . . . . . . . . 31		12.1. Registry creation . . . . . . . . . . . . . . . . . . . . 33
	11.1.3. Additional Call Data Device ID Type Registry . . . . 32		12.1.1. Additional Call Data Blocks Registry . . . . . . . . 33
	11.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 32		12.1.2. Additional Call Data Service Delivered Registry . . . 33
	11.3. URN Sub-Namespace Registration for provided-by		12.1.3. Additional Call Data Device Classification
	Registry Entry . . . . . . . . . . . . . . . . . . . . . . 32		Registry . . . . . . . . . . . . . . . . . . . . . . 34
	11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 33		12.1.4. Additional Call Data Device ID Type Registry . . . . 35
	11.4.1. MIME Content-type Registration for		12.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 36
	'application/addDataProviderInfo+xml' . . . . . . . . 33		12.3. URN Sub-Namespace Registration for provided-by
	11.4.2. MIME Content-type Registration for		Registry Entry . . . . . . . . . . . . . . . . . . . . . . 36
	'application/addCallSvcInfo+xml' . . . . . . . . . . 34		12.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 36
	11.4.3. MIME Content-type Registration for		12.4.1. MIME Content-type Registration for
	'application/addDataDevInfo+xml' . . . . . . . . . . 35		'application/addDataProviderInfo+xml' . . . . . . . . 36
	11.4.4. MIME Content-type Registration for		12.4.2. MIME Content-type Registration for
	'application/addCallSub+xml' . . . . . . . . . . . . 36		'application/addCallSvcInfo+xml' . . . . . . . . . . 38
	11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 38		12.4.3. MIME Content-type Registration for
	11.5.1. Registration for		'application/addDataDevInfo+xml' . . . . . . . . . . 39
	urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 38		12.4.4. MIME Content-type Registration for
	11.5.2. Registration for		'application/addCallSub+xml' . . . . . . . . . . . . 40
	urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 38		12.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 41
	11.5.3. Registration for		12.5.1. Registration for
	urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 39		urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 41
	11.5.4. Registration for urn:ietf:params:xml:ns:addCallSub . 40		12.5.2. Registration for
	11.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 41		urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 42
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43		12.5.3. Registration for
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44		urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 43
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 44		12.5.4. Registration for urn:ietf:params:xml:ns:addCallSub . 44
	13.2. Informational References . . . . . . . . . . . . . . . . . 44		12.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46		12.7. VCard Parameter Value Registration . . . . . . . . . . . . 46
			13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
			14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
			14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
			14.2. Informational References . . . . . . . . . . . . . . . . . 48
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Introduction		1. Introduction
	As communications devices increasingly utilize the Internet to		As communications devices increasingly utilize the Internet to
	interconnect and communicate, users will expect to use such devices		interconnect and communicate, users will expect to use such devices
	to request help. The Internet Protocol suite provides many		to request help. The Internet Protocol suite provides many
	advantages but also requires re-thinking of the traditional emergency		advantages but also requires re-thinking of the traditional emergency
	calling architecture. The IETF emergency services architecture, as		calling architecture. The IETF emergency services architecture, as
	described in [RFC6443] and [I-D.ietf-ecrit-phonebcp], offers a much		described in [RFC6443] and [I-D.ietf-ecrit-phonebcp], offers a much
	richer communication exchange and thereby better situational		richer communication exchange and thereby better situational
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	one. There may be circumstances where there is a service provider		one. There may be circumstances where there is a service provider
	who is unaware that the call is an emergency call and cannot		who is unaware that the call is an emergency call and cannot
	reasonably be expected to determine that it is an emergency call. In		reasonably be expected to determine that it is an emergency call. In
	that case, that service provider is not expected to provide		that case, that service provider is not expected to provide
	emergencyCallData.		emergencyCallData.
	Note: The access network MAY supply additional data as well. For		Note: The access network MAY supply additional data as well. For
	this purpose, this document defines a namespace and adds the		this purpose, this document defines a namespace and adds the
	namespace to the "provided-by" registry defined by PIDF-LO [RFC4119].		namespace to the "provided-by" registry defined by PIDF-LO [RFC4119].
			In regions where callers can elect to suppress certain personally
			identifying information, the network or PSAP functionality can
			inspect privacy flags within the SIP headers to determine what
			information may be passed, stored, or displayed to comply with local
			policy or law.
	Additional data about a call is defined as a series of MIME objects,		Additional data about a call is defined as a series of MIME objects,
	each with an XML data structure contained inside. MIME-multipart is		each with an XML data structure contained inside. MIME-multipart is
	used to enclose the XML documents and the sections below define them.		used to enclose the XML documents and the sections below define them.
			When additional data is passed by value, the CID URL points to one of
			the blocks, and a link is provided in each of the other blocks to
			link to the next block. When additional data is provided by
			reference, the data is retrieved with an HTTP Get operation, which
			returns a multi-part MIME header and a set of MIME blocks threaded
			with the links. A registry of allowed types is created by this
			document. Every block MUST be one of the types in the registry.
	4. Data Provider Information		4. Data Provider Information
	This block is intended to be provided by any service provider in the		This block is intended to be provided by any service provider in the
	path of the call or the access network provider. It includes		path of the call or the access network provider. It includes
	identification and contact information. This block SHOULD be		identification and contact information. This block SHOULD be
	provided for every service provider in the path of the call, and the		provided for every service provider in the path of the call, and the
	access network provider. Devices also use this block to provide		access network provider. Devices also use this block to provide
	identifying information. The MIME type is "addDataProviderInfo+xml".		identifying information. The MIME type is "addDataProviderInfo+xml".
	skipping to change at page 10, line 30 ¶		skipping to change at page 11, line 30 ¶
	Use: Conditional. If Data Provider ID is provided, Type of Data		Use: Conditional. If Data Provider ID is provided, Type of Data
	Provider ID is required.		Provider ID is required.
	XML Element: <TypeOfProviderID>		XML Element: <TypeOfProviderID>
	Description: Identifies the type of data provider id being supplied		Description: Identifies the type of data provider id being supplied
	in the ProviderId data element. A registry will reflect the		in the ProviderId data element. A registry will reflect the
	following valid entries:		following valid entries:
	* NENA (CDMA)		* Access Provider
			* Origination Network Provider
			* ServiceProviderSubcontractor
	* Other		* Other
	Reason for Need: Identifies how to interpret the Data Provider ID.		Reason for Need: Identifies how to interpret the Data Provider ID.
	How Used by Call Taker: Determines which provider ID registry to		How Used by Call Taker: Determines which provider ID registry to
	consult for more information		consult for more information
	4.4. Data Provider Contact URI		4.4. 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: For a service provider the contact SHOULD be a contact		Description: For a service provider the contact SHOULD be a contact
	URI. This must be a SIP URI. If a telephone number is the		URI. This must be a SIP URI. If a telephone number is the
	contact address it should be provided in the form of		contact address it should be provided in the form of
	sip:telephonenumber@serviceprovider:user=phone. If the call is		sip:telephonenumber@serviceprovider:user=phone. If the call is
	skipping to change at page 12, line 25 ¶		skipping to change at page 13, line 25 ¶
	Data Element: vCARD of Data Provider		Data Element: vCARD of Data Provider
	Use: Optional		Use: Optional
	XML Element: <DataProviderContact>		XML Element: <DataProviderContact>
	Description: There are many fields in the xCARD and the creator of		Description: There are many fields in the xCARD and the creator of
	the data structure is encouraged to provide as much information as		the data structure is encouraged to provide as much information as
	they have available. N, ORG, ADR, TEL, EMAIL are suggested at a		they have available. N, ORG, ADR, TEL, EMAIL are suggested at a
	minimum. N should contain name of support group or device owner		minimum. N should contain name of support group or device owner
	as appropriate. For encoding of the vCard this specification uses		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 vCard this specification uses
	the XML-based encoding specified in [RFC6351].		the XML-based encoding specified in [RFC6351].
	and is hereinafter referred to as "xCard"		and is hereinafter referred to as "xCard"
	Reason for Need: Information needed to determine additional contact		Reason for Need: Information needed to determine additional contact
	information.		information.
	How Used by Call Taker: Assists call taker by providing additional		How Used by Call Taker: Assists call taker by providing additional
	contact information that may not be included in the SIP invite or		contact information that may not be included in the SIP invite or
	the PIDF-LO.		the PIDF-LO.
	4.7. addDataProviderInfo XML Schema		4.7. Subcontractor Principal
			Data Element: Subcontractor Principal
			XML Element: <SubcontratorPrincipal>
			Description: If the data provider is a subcontractor to an access
			provider or origination network, this element contains the
			DataProviderString of the access provider or origination network
			to indicate which provider the subcontractor is working for. This
			data is required if the Data Provider type is subcontractor.
			Reason for Need: Identify the entity the subcontractor works for.
			How Used by Call Taker: Allows the call taker to understand what the
			relationship between data providers and the service providers in
			the path of the call are.
			4.8. Subcontractor Priority
			Data Element: Subcontractor Priority
			Use: Required
			XML Element: <SubcontractorPriority>
			Description: If the subcontractor should be contacted first, this
			element should have a "sub" value. If the access or origination
			service provider should be contacted first, this element should
			have a "main" value. This data is required if the Data Provider
			type is "subcontractor".
			Reason for Need: Inform the call taker whether the network operator
			or the subcontractor should be contacted first if support is
			needed.
			How Used by Call Taker: To decide which entity to contact first if
			assistance is needed.
			4.9. addDataProviderInfo XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:addDataProviderInfo"		targetNamespace="urn:ietf:params:xml:ns:addDataProviderInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ad="urn:ietf:params:xml:ns:addDataProviderInfo"		xmlns:ad="urn:ietf:params:xml:ns:addDataProviderInfo"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"		xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
	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"
	skipping to change at page 13, line 37 ¶		skipping to change at page 15, line 37 ¶
	<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="TypeOfProvider"		<xs:element name="TypeOfProvider"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="ContactURI" type="xs:anyURI"		<xs:element name="ContactURI" type="xs:anyURI"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:element name="Language" type="ad:iso3166a2"		<xs:element name="Language" type="ad:iso3166a2"
	minOccurs="0" maxOccurs="unbounded" />		minOccurs="0" maxOccurs="unbounded" />
	<xs:element name="DataProviderContact"		<xs:element name="DataProviderContact"
	type="vc:vcards" minOccurs="0" maxOccurs="1">		type="vc:vcards" minOccurs="0" maxOccurs="1">
			<xs:element name="Link"
			type="xs:string" minOccurs="0" maxOccurs="1">
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	Figure 1: addDataProviderInfo XML Schema		Figure 1: addDataProviderInfo XML Schema
	5. Service Information		5. Service Information
	This block describes the service that the service provider provides		This block describes the service that the service provider provides
	skipping to change at page 17, line 27 ¶		skipping to change at page 19, line 27 ¶
	<xs:element name="addCallSvcInfo">		<xs:element name="addCallSvcInfo">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="SvcEnvironment"		<xs:element name="SvcEnvironment"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="SvcDelByProvider"		<xs:element name="SvcDelByProvider"
	type="xs:string" minOccurs="0" maxOccurs="unbounded"/>		type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="SvcMobility"		<xs:element name="SvcMobility"
	type="xs:string" minOccurs="0" maxOccurs="unbounded"/>		type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="Link"
			type="xs:string" minOccurs="0" maxOccurs="1">
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	Figure 2: addCallSvcInfo XML Schema		Figure 2: addCallSvcInfo XML Schema
	6. Device Information		6. 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 24, line 15 ¶		skipping to change at page 26, line 15 ¶
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:addDataDevInfo"		targetNamespace="urn:ietf:params:xml:ns:addDataDevInfo"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:svc="urn:ietf:params:xml:ns:addDataDevInfo"		xmlns:svc="urn:ietf:params:xml:ns:addDataDevInfo"
	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="addCallSvcInfo">		<xs:element name="addDataDevInfo">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceClassification"		<xs:element name="DeviceClassification"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceMfgr"		<xs:element name="DeviceMfgr"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="DeviceModelNr"		<xs:element name="DeviceModelNr"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="UniqueDeviceID"		<xs:element name="UniqueDeviceID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xs:element name="TypeOfDeviceID"		<xs:element name="TypeOfDeviceID"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xsd:element name="devicespecificType"		<xsd:element name="devicespecificType"
	type="xs:string" minOccurs="0" maxOccurs="1"/>		type="xs:string" minOccurs="0" maxOccurs="1"/>
	<xsd:element name="devicespecificSchema"		<xsd:element name="devicespecificSchema"
	type="xsd:anyURI" minOccurs="0" maxOccurs="1"/>		type="xsd:anyURI" minOccurs="0" maxOccurs="1"/>
			<xs:element name="Link"
			type="xs:string" minOccurs="0" maxOccurs="1">
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	Figure 3: addDataDevInfo XML Schema		Figure 3: addDataDevInfo XML Schema
	7. Owner/Subscriber Information		7. 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
	skipping to change at page 25, line 25 ¶		skipping to change at page 27, line 25 ¶
	Data Element: xCARD for Subscriber's Data		Data Element: xCARD for Subscriber's Data
	Use: Conditional: Some services (e.g. prepaid phones, initialized		Use: Conditional: Some services (e.g. prepaid phones, initialized
	phones, etc.) may not have this information.		phones, etc.) may not have this information.
	XML Element: <SubscriberData>		XML Element: <SubscriberData>
	Description: Information known by the service provider or device		Description: Information known by the service provider or device
	about the subscriber; i.e., Name, Address, Individual Telephone		about the subscriber; i.e., Name, Address, Individual Telephone
	Number, Main Telephone Number and any other data. N, ORG (if		Number, Main Telephone Number and any other data. N, ORG (if
	appropriate), ADR, TEL, EMAIL are suggested at a minimum.		appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more
			than one TEL property is provided, a parameter from the vCard
			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.
	7.2. addCallSub XML Schema		7.2. addCallSub XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	skipping to change at page 26, line 21 ¶		skipping to change at page 28, line 21 ¶
	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="addCallSub">		<xs:element name="addCallSub">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="SubscriberData"		<xs:element name="SubscriberData"
	type="vc:vcards" minOccurs="0" maxOccurs="1">		type="vc:vcards" minOccurs="0" maxOccurs="1">
	</xs:sequence>		<xs:element name="Link"
			type="xs:string" minOccurs="0" maxOccurs="1">
			</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	Figure 4: addCallSub XML Schema		Figure 4: addCallSub XML Schema
	8. Example		8. Example
	INVITE sips:bob@biloxi.example.com SIP/2.0		INVITE sips:bob@biloxi.example.com SIP/2.0
	Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: Bob <sips:bob@biloxi.example.com>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,		Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
	<http://www.example.com/alice/> ;purpose=info,		<http://www.example.com/alice/> ;purpose=info,
	<cid:1234567890@atlanta.example.com> ;purpose=emergencyCallData		<cid:1234567890@atlanta.example.com> ;purpose=emergencyCallData
	Geolocation: <cid:target123@atlanta.example.com>		Geolocation: <cid:target123@atlanta.example.com>
	Geolocation-Routing: no		Geolocation-Routing: no
	Accept: application/sdp, application/pidf+xml		Accept: application/sdp, application/pidf+xml,
			application/addDataProviderinfo+xml
	CSeq: 31862 INVITE		CSeq: 31862 INVITE
	Contact: <sips:alice@atlanta.example.com>		Contact: <sips:alice@atlanta.example.com>
	Content-Type: multipart/mixed; boundary=boundary1		Content-Type: multipart/mixed; boundary=boundary1
	Content-Length: ...		Content-Length: ...
	--boundary1		--boundary1
	Content-Type: application/sdp		Content-Type: application/sdp
	skipping to change at page 27, line 40 ¶		skipping to change at page 29, line 41 ¶
	--boundary1		--boundary1
	Content-Type: application/pidf+xml		Content-Type: application/pidf+xml
	Content-ID: <target123@atlanta.example.com>		Content-ID: <target123@atlanta.example.com>
	...PIDF-LO goes here		...PIDF-LO goes here
	--boundary1--		--boundary1--
	Content-Type: application/pidf+xml		Content-Type: application/addDataProviderinfo+xml
	Content-ID: <1234567890@atlanta.example.com>		Content-ID: <1234567890@atlanta.example.com>
	...Additional Data goes here		...Additional Data goes here
	--boundary1--		--boundary1--
	Example: Attaching Additional Data via CID to a SIP INVITE		Example: Attaching Additional Data via CID to a SIP INVITE
	9. Security Considerations		9. Main Telephone Number
			In a vCard, used extensively in this document, there is no way to
			specify a "Main" telephone number. These numbers are useful to
			emergency responders who are called to a large enterprise. This
			document adds a new Property Value to the "tel" property of the TYPE
			parameter called "main". It can be used in any vCard in additional
			data.
			10. Security Considerations
	The information in this data structure will usually be considered		The information in this data structure will usually be considered
	private. HTTPS is specified to require the provider of the		private. HTTPS is specified to require the provider of the
	information to validate the credentials of the requester. While the		information to validate the credentials of the requester. While the
	creation of a PKI that has global scope may be difficult, the		creation of a PKI that has global scope may be difficult, the
	alternatives to creating devices and services that can provide		alternatives to creating devices and services that can provide
	critical information securely are more daunting.		critical information securely are more daunting.
	The Call-info header with purpose='emergencyCallData' MUST only be		The Call-info header with purpose='emergencyCallData' MUST only be
	sent on an emergency call, which can be ascertained by the presence		sent on an emergency call, which can be ascertained by the presence
	of an emergency service urn in a Route header of a SIP message.		of an emergency service urn in a Route header of a SIP message.
	<how recipient validates credentials of sender>		<how recipient validates credentials of sender>
	<how sender validates credentials of recipient>		<how sender validates credentials of recipient>
	<how sender validates credentials of anyone requesting device		<how sender validates credentials of anyone requesting device
	dependent data>		dependent data>
	10. Privacy Considerations		11. Privacy Considerations
	[Editor's Note: The privacy considerations outlined in		[Editor's Note: The privacy considerations outlined in
	[I-D.iab-privacy-considerations] need to be addressed here in a		[I-D.iab-privacy-considerations] need to be addressed here in a
	future version of this document.		future version of this document.
	There is much private data in this information. Local regulations		There is much private data in this information. Local regulations
	may govern what data must be provided in emergency calls, but in		may govern what data must be provided in emergency calls, but in
	general, the emergency call system is often aided by the kinds of		general, the emergency call system is often aided by the kinds of
	information described in this document. There is a tradeoff between		information described in this document. There is a tradeoff between
	the privacy considerations and the utility of the data. Certainly,		the privacy considerations and the utility of the data. Certainly,
	if the data cannot be protected, due to failure of the TLS mechanisms		if the data cannot be protected, due to failure of the TLS mechanisms
	described here, data not required by regulation SHOULD not be sent.		described here, data not required by regulation SHOULD not be sent.
	11. IANA Considerations		12. IANA Considerations
	11.1. Registry creation		12.1. Registry creation
	11.1.1. Additional Call Data Service Delivered Registry		12.1.1. Additional Call Data Blocks Registry
			This document creates a new registry called 'Additional Call Data
			Blocks'. As defined in [RFC5226], this registry operates under
			"Expert Review" and "Specification Required" rules.
			The content of this registry includes:
			Name: Element Name of enclosing block.
			Reference: The document that describes the block
			The values defined are:
			+---------------------+-----------+
			| Name | Reference |
			+---------------------+-----------+
			| addDataProviderInfo | RFCXXXX |
			| addCallSvcInfo | RFCXXXX |
			| addCallSvcInfo | RFCXXXX |
			| addCallSub | RFCXXXX |
			+---------------------+-----------+
			RFC Editor Note:
			replace XXXX in the table above with this documents RFC number
			12.1.2. Additional Call Data Service Delivered Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new registry called 'Additional Call Data
	Service Delivered'. As defined in [RFC5226], this registry operates		Service Delivered'. As defined in [RFC5226], this registry operates
	under "Expert Review" rules.		under "Expert Review" rules.
	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.
	skipping to change at page 31, line 5 ¶		skipping to change at page 34, line 36 ¶
	| | that are supported by a monitoring |		| | that are supported by a monitoring |
	| | service provider or automatically |		| | service provider or automatically |
	| | open a two-way communication path |		| | open a two-way communication path |
	| POTS | Wireline: Plain Old Telephone Service |		| POTS | Wireline: Plain Old Telephone Service |
	| VOIP | VoIP Telephone Service: A type of |		| VOIP | VoIP Telephone Service: A type of |
	| | service that offers communication |		| | service that offers communication |
	| | over internet protocol, such as Fixed|		| | over internet protocol, such as Fixed|
	| | Nomadic, Mobile, ... |		| | Nomadic, Mobile, ... |
	+--------+-------+--------------------------------+		+--------+-------+--------------------------------+
	11.1.2. Additional Call Data Device Classification Registry		12.1.3. Additional Call Data Device Classification Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new registry called 'Additional Call Data
	Device Classification'. As defined in [RFC5226], this registry		Device Classification'. As defined in [RFC5226], this registry
	operates under "Expert Review" rules.		operates under "Expert Review" rules.
	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.
	skipping to change at page 32, line 5 ¶		skipping to change at page 35, line 36 ¶
	| PDA | Personal digital assistant |		| PDA | Personal digital assistant |
	| PND | Personal navigation device) |		| PND | Personal navigation device) |
	| SmrtPhn| Smart phone |		| SmrtPhn| Smart phone |
	| Itab | Internet tablet |		| Itab | Internet tablet |
	| Game | Gaming console |		| Game | Gaming console |
	| Video | Video phone |		| Video | Video phone |
	| Text | Other text device |		| Text | Other text device |
	| NA | Not Available |		| NA | Not Available |
	+--------+----------------------------------------+		+--------+----------------------------------------+
	11.1.3. Additional Call Data Device ID Type Registry		12.1.4. Additional Call Data Device ID Type Registry
	This document creates a new registry called 'Additional Call Data		This document creates a new 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.		under "Expert Review" rules.
	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 the type of device id.		Description: Short description identifying the type of device id.
	skipping to change at page 32, line 34 ¶		skipping to change at page 36, line 20 ¶
	| MAC | Media Access Control Address (IEEE) |		| MAC | Media Access Control Address (IEEE) |
	| WiMAX | device certificate unique id |		| WiMAX | device certificate unique id |
	| IMEI | International Mobile Equipment ID (GSM)|		| IMEI | International Mobile Equipment ID (GSM)|
	| UDI | Unique Device Identifier (medical) |		| UDI | Unique Device Identifier (medical) |
	| RFID | Radio Frequency Identification |		| RFID | Radio Frequency Identification |
	| Sense | Sensors (types to be identified ) |		| Sense | Sensors (types to be identified ) |
	| SN | Manufacturer Serial Number |		| SN | Manufacturer Serial Number |
	| Other | Other |		| Other | Other |
	+--------+----------------------------------------+		+--------+----------------------------------------+
	11.2. 'emergencyCallData' Purpose Parameter Value		12.2. 'emergencyCallData' Purpose Parameter Value
	This document defines the 'emergencyCallData' 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 emergencyCallData [This RFC]		Call-Info purpose emergencyCallData [This RFC]
	11.3. URN Sub-Namespace Registration for provided-by Registry Entry		12.3. URN Sub-Namespace Registration for provided-by Registry Entry
	This section registers the namespace specified in ??? in the		This section registers the namespace specified in ??? in the
	provided-by registry established by RFC 4119.		provided-by registry established by RFC 4119.
	11.4. MIME Registrations		12.4. MIME Registrations
	11.4.1. MIME Content-type Registration for 'application/		12.4.1. MIME Content-type Registration for 'application/
	addDataProviderInfo+xml'		addDataProviderInfo+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: addDataProviderInfo+xml		MIME subtype name: addDataProviderInfo+xml
	skipping to change at page 33, line 19 ¶		skipping to change at page 37, line 4 ¶
	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: addDataProviderInfo+xml		MIME subtype name: addDataProviderInfo+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset
	Indicates the character encoding of enclosed XML.		Indicates the character encoding of enclosed XML.
	Encoding considerations:		Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the		Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].		character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:		Security considerations:
	This content type is designed to carry the data provider		This content type is designed to carry the data provider
	information, which is a sub-category of additional data about an		information, which is a sub-category of additional data about an
	emergency call.		emergency call.
	Since this data contains personal information appropriate		Since this data contains personal information appropriate
	precautions have to be taken to limit unauthorized access,		precautions have to be taken to limit unauthorized access,
	inappropriate disclosure to third parties, and eavesdropping of		inappropriate disclosure to third parties, and eavesdropping of
	this information. Please refer to Section 9 and Section 10 for		this information. Please refer to Section 10 and Section 11 for
	more information.		more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	skipping to change at page 34, line 4 ¶		skipping to change at page 37, line 36 ¶
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	Magic Number: None		Magic Number: None
	File Extension: .xml		File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information: Hannes		Personal and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	11.4.2. MIME Content-type Registration for 'application/		12.4.2. MIME Content-type Registration for 'application/
	addCallSvcInfo+xml'		addCallSvcInfo+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: addCallSvcInfo+xml		MIME subtype name: addCallSvcInfo+xml
	skipping to change at page 34, line 47 ¶		skipping to change at page 38, line 36 ¶
	Security considerations:		Security considerations:
	This content type is designed to carry the service information,		This content type is designed to carry the service information,
	which is a sub-category of additional data about an emergency		which is a sub-category of additional data about an emergency
	call.		call.
	Since this data contains personal information appropriate		Since this data contains personal information appropriate
	precautions have to be taken to limit unauthorized access,		precautions have to be taken to limit unauthorized access,
	inappropriate disclosure to third parties, and eavesdropping of		inappropriate disclosure to third parties, and eavesdropping of
	this information. Please refer to Section 9 and Section 10 for		this information. Please refer to Section 10 and Section 11 for
	more information.		more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	skipping to change at page 35, line 18 ¶		skipping to change at page 39, line 4 ¶
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	Magic Number: None		Magic Number: None
	File Extension: .xml		File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information: Hannes		Personal and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	11.4.3. MIME Content-type Registration for 'application/		12.4.3. MIME Content-type Registration for 'application/
	addDataDevInfo+xml'		addDataDevInfo+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: addDataDevInfo+xml		MIME subtype name: addDataDevInfo+xml
	skipping to change at page 36, line 14 ¶		skipping to change at page 39, line 45 ¶
	Security considerations:		Security considerations:
	This content type is designed to carry the device information		This content type is designed to carry the device information
	information, which is a sub-category of additional data about an		information, which is a sub-category of additional data about an
	emergency call.		emergency call.
	Since this data contains personal information appropriate		Since this data contains personal information appropriate
	precautions have to be taken to limit unauthorized access,		precautions have to be taken to limit unauthorized access,
	inappropriate disclosure to third parties, and eavesdropping of		inappropriate disclosure to third parties, and eavesdropping of
	this information. Please refer to Section 9 and Section 10 for		this information. Please refer to Section 10 and Section 11 for
	more information.		more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	Magic Number: None		Magic Number: None
	File Extension: .xml		File Extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information: Hannes		Personal and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	11.4.4. MIME Content-type Registration for 'application/addCallSub+xml'		12.4.4. MIME Content-type Registration for 'application/addCallSub+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: addCallSub+xml		MIME subtype name: addCallSub+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset
	Indicates the character encoding of enclosed XML.		Indicates the character encoding of enclosed XML.
	Encoding considerations:		Encoding considerations:
	Uses XML, which can employ 8-bit characters, depending on the		Uses XML, which can employ 8-bit characters, depending on the
	character encoding used. See Section 3.2 of RFC 3023 [RFC3023].		character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
	Security considerations:		Security considerations:
	This content type is designed to carry owner/subscriber		This content type is designed to carry owner/subscriber
	information, which is a sub-category of additional data about an		information, which is a sub-category of additional data about an
	emergency call.		emergency call.
	Since this data contains personal information appropriate		Since this data contains personal information appropriate
	precautions have to be taken to limit unauthorized access,		precautions have to be taken to limit unauthorized access,
	inappropriate disclosure to third parties, and eavesdropping of		inappropriate disclosure to third parties, and eavesdropping of
	this information. Please refer to Section 9 and Section 10 for		this information. Please refer to Section 10 and Section 11 for
	more information.		more information.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: [TBD: This specification]		Published specification: [TBD: This specification]
	Applications which use this media type: Emergency Services		Applications which use this media type: Emergency Services
	Additional information:		Additional information:
	skipping to change at page 38, line 5 ¶		skipping to change at page 41, line 35 ¶
	Personal and email address for further information: Hannes		Personal and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@gmx.net		Tschofenig, Hannes.Tschofenig@gmx.net
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF ECRIT		Author: This specification is a work item of the IETF ECRIT
	working group, with mailing list address <ecrit@ietf.org>.		working group, with mailing list address <ecrit@ietf.org>.
	Change controller: The IESG <ietf@ietf.org>		Change controller: The IESG <ietf@ietf.org>
	11.5. URN Sub-Namespace Registration		12.5. URN Sub-Namespace Registration
	11.5.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo		12.5.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo
	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:addDataProviderInfo		URI: urn:ietf:params:xml:ns:addDataProviderInfo
	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:
	skipping to change at page 38, line 38 ¶		skipping to change at page 42, line 24 ¶
	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
	11.5.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo		12.5.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo
	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:addCallSvcInfo		URI: urn:ietf:params:xml:ns:addCallSvcInfo
	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:
	skipping to change at page 39, line 26 ¶		skipping to change at page 43, line 24 ¶
	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
	11.5.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo		12.5.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo
	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:addDataDevInfo		URI: urn:ietf:params:xml:ns:addDataDevInfo
	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:
	skipping to change at page 40, line 24 ¶		skipping to change at page 44, line 24 ¶
	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
	11.5.4. Registration for urn:ietf:params:xml:ns:addCallSub		12.5.4. Registration for urn:ietf:params:xml:ns:addCallSub
	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:addCallSub		URI: urn:ietf:params:xml:ns:addCallSub
	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:
	skipping to change at page 41, line 24 ¶		skipping to change at page 45, line 24 ¶
	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
	11.6. Schema Registrations		12.6. Schema Registrations
	This specification registers four schemas, as per the guidelines in		This specification registers four schemas, as per the guidelines in
	RFC 3688 [RFC3688].		RFC 3688 [RFC3688].
	URI:		URI:
	urn:ietf:params:xml:schema:additional-data:addDataProviderInfo		urn:ietf:params:xml:schema:additional-data:addDataProviderInfo
	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).
	skipping to change at page 43, line 5 ¶		skipping to change at page 46, line 14 ¶
	XML: The XML schema can be found in Figure 3.		XML: The XML schema can be found in Figure 3.
	URI: urn:ietf:params:xml:schema:additional-data:addCallSub		URI: urn:ietf:params:xml:schema:additional-data:addCallSub
	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 4.		XML: The XML schema can be found in Figure 4.
	12. Acknowledgments		12.7. VCard Parameter Value Registration
	The authors would like to thank the following persons for their work		This document registers a new value in the vCARD Parameter Values
	in the NENA Data Technical Committee: Delaine Arnold (Data Technical		registry as defined by [RFC6350] with the following template:
	Committee Chair), Marc Berryman, Erica Aubut (Data Technical
	Committee Vice-Chair), Susan Sherwood, Ric Atkins, Patty Bluhm,
	Eileen Boroski, David Connel, Maryls Davis, Paul-David de la Rosby,
	Gordon Chinander, David Froneberger, Marilyn Haroutunian, Roger
	Hixson, Rick Jones, Roger Marshall, Tom Muehleisen, Ira Pyles, Carl
	Reed, Susan Seet, and Skip Walls. The authors would also like to
	thank Tom Breen, Technical Committee Chair/Liaison; Busam, Technical
	Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee
	Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison;
	Roger Hixson, Technical Director; and Rick Jones, Operations Issues
	Director for their support and assistance.
	[Editor's Note: Add the participants of the NENA Additional Data		Value: main
	Working group lead by Matt Serra.]
	13. References		Purpose: The main telephone number, typically of an enterprise, as
			opposed to a direct dial number of an individual employee
	13.1. Normative References		Conformance: This value can be used with the "TYPE" parameter
			applied on the "TEL" property.
			Example(s):
			TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-9000
			13. Acknowledgments
			This work was originally started in NENA and has benefitted from a
			large number of participants in NENA standardization efforts,
			originally in the Long Term Definition Working Group, the Data
			Technical Committee and most recently the Additional Data working
			group. The authors are grateful for the initial work and extended
			comments provided by the many NENA participants.
			14. References
			14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, August 1998.		Locators", RFC 2392, August 1998.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	skipping to change at page 44, line 36 ¶		skipping to change at page 48, line 36 ¶
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
			August 2011.
	[RFC6351] Perreault, S., "xCard: vCard XML Representation",		[RFC6351] Perreault, S., "xCard: vCard XML Representation",
	RFC 6351, August 2011.		RFC 6351, August 2011.
	13.2. Informational References		14.2. Informational References
	[I-D.iab-privacy-considerations]		[I-D.iab-privacy-considerations]
	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and		Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	J. Morris, "Privacy Considerations for Internet		Morris, J., Hansen, M., and R. Smith, "Privacy
	Protocols", draft-iab-privacy-considerations-02 (work in		Considerations for Internet Protocols",
	progress), March 2012.		draft-iab-privacy-considerations-03 (work in progress),
			July 2012.
	[I-D.ietf-ecrit-phonebcp]		[I-D.ietf-ecrit-phonebcp]
	Rosen, B. and J. Polk, "Best Current Practice for		Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-20 (work in progress),		draft-ietf-ecrit-phonebcp-20 (work in progress),
	September 2011.		September 2011.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, December 2011.		Multimedia", RFC 6443, December 2011.
End of changes. 56 change blocks.
	122 lines changed or deleted		239 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/