< draft-ietf-ecrit-held-routing-03.txt		draft-ietf-ecrit-held-routing-04.txt >
	ECRIT J. Winterbottom		ECRIT J. Winterbottom
	Internet-Draft Winterb Consulting Services		Internet-Draft Winterb Consulting Services
	Updates: RFC6881, RFC5985 (if approved) H. Tschofenig		Updates: RFC6881, RFC5985 (if approved) H. Tschofenig
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 21, 2016 L. Liess		Expires: June 11, 2016 L. Liess
	Deutsche Telekom		Deutsche Telekom
	July 20, 2015		December 9, 2015
	A Routing Request Extension for the HELD Protocol		A Routing Request Extension for the HELD Protocol
	draft-ietf-ecrit-held-routing-03.txt		draft-ietf-ecrit-held-routing-04.txt
	Abstract		Abstract
	For cases where location servers have access to emergency routing		For cases where location servers have access to emergency routing
	information they are able to return routing information with the		information they are able to return routing information with the
	location information if the location request includes a request for		location information if the location request includes a request for
	the desired routing information. This document specifies an		the desired routing information. This document specifies an
	extension to the HELD protocol to support this funciton.		extension to the HELD protocol, updating [RFC5985], to support this
			funciton.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 21, 2016.		This Internet-Draft will expire on June 11, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 15 ¶		skipping to change at page 2, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6		3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6
	4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 7		5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9.1. URN sub-namespace registration for		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 11		10.1. URN sub-namespace registration for
	9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11		'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 12		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 13		12.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		12.2. Informative References . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The general ECRIT calling models described in [RFC6443] and		The general ECRIT calling models described in [RFC6443] and
	[RFC6881]require a local LoST server or network of forest guides in		[RFC6881]require a local LoST server or network of forest guides in
	order to determine the address of the PSAP in the best position to		order to determine the address of the PSAP in the best position to
	handle a call. Networks of forest guides have not eventuated and		handle a call. Networks of forest guides have not materialized and
	while PSAPs are moving towards IP networks, LoST server deployment is		while PSAPs are moving towards IP networks, LoST server deployment is
	not ubiquitous. Some regions and countries have expressed reluctance		not ubiquitous. Some regions and countries have expressed reluctance
	to deploy LoST servers making aspects of the current ECRIT		to deploy LoST servers making aspects of the current ECRIT
	architecture hard to realize.		architecture hard to realize.
	Evolving architectures in Europe to address regulatory requirements,		Evolving architectures in Europe to address regulatory requirements,
	such as [M493], couple location and routing information in the access		such as [M493], couple location and routing information in the access
	network whilst using a softswitch-centric approach to emergency call		network whilst using a softswitch-centric approach to emergency call
	processing. This document describes adding an extension to the HELD		processing. This document describes an extension to the HELD
	protocol [RFC5985] so that a location information server can provide		protocol [RFC5985] so that a location information server can provide
	emergency routing information in the absence of a LoST server or		emergency routing information in the absence of a LoST server or
	network of forest guides.		network of forest guides.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].		The terms Location Information Server (LIS), Emergency Services
			Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety
			Answering Point (PSAP) are used as defined in [RFC6443].
	The term "Access Network Provider" is used as defined in [RFC5687]		The term "Access Network Provider" is used as defined in [RFC5687]
	and incompasses both the Internet Access Provider (IAP) and Internet		and incompasses both the Internet Access Provider (IAP) and Internet
	Service Provider (ISP).		Service Provider (ISP).
	3. Motivation		3. Motivation
	The Internet emergency calling architecture specified in [RFC6881]		The Internet emergency calling architecture specified in [RFC6881]
	describes two main models for emergency call processing. The first		describes two main models for emergency call processing. The first
	is a device-centric model, where a device obtains location		is a device-centric model, where a device obtains location
	information using a location configuration protocol, such a HELD		information using a location configuration protocol, such as HELD
	[RFC5985], and then proceeds to determine the address of the next hop		[RFC5985], and then proceeds to determine the address of the next hop
	closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this		closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this
	model in a simplified form.		model in a simplified form.
	+---Location Request---+		+---Location Request---+
	| (1) |		| (1) |
	+---+----+ +---V---+		+---+----+ +---V---+
	| |<--Location--| LIS |		| |<--Location--| LIS |
	| Caller | (2) +-------+ +--------+		| Caller | (2) +-------+ +--------+
	| | | ESRP/ |		| | | ESRP/ |
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 38 ¶
	If the routing request is sent with no attribute then URIs for		If the routing request is sent with no attribute then URIs for
	urn:service:sos are returned. If the requestor wants routing		urn:service:sos are returned. If the requestor wants routing
	information for a specific service then they may include an optional		information for a specific service then they may include an optional
	service URN. If a service is specified, and the LIS does not		service URN. If a service is specified, and the LIS does not
	understand the requested service then URIs for urn:service:sos are		understand the requested service then URIs for urn:service:sos are
	returned.		returned.
	If the LIS understands the routing request and has routing		If the LIS understands the routing request and has routing
	information for the location then it includes the information in a		information for the location then it includes the information in a
	routingInformation element returned in the locationResponse. How the		routingInformation element returned in the locationResponse. How the
	LIS obtains this information is left to implementation, one possible		LIS obtains this information is left to implementation.
	option is that the LIS acquires it from a LoST server, other		Possibilities are described in Section 3.
	possibilities are described in Section 3.
	A LIS that does not understand the routing request element ignores it		A LIS that does not understand the routing request element ignores it
	and returns location as normal.		and returns location as normal.
	A LIS that does support the routing request element MUST support		A LIS that does support the routing request element MUST support
	returning URIs for urn:service:sos and any regionally defined sub-		returning URIs for urn:service:sos and any regionally defined sub-
	services while following the URN traversal rules defined in		services while following the URN traversal rules defined in
	[RFC5031].		[RFC5031].
	A LIS that does understand the routing request element but can't		A LIS that does understand the routing request element but can't
	obtain any routing information for the end-device's location MUST		obtain any routing information for the end-device's location MUST set
	only return location information.		the defaultRoute attribute to true and return a default PSAP or
			gateway URI along with the determined location information in the
			locationResponse.
	A LIS that understands the routing request element but not the		A LIS that understands the routing request element but not the
	specified service URN, MUST follow the URN traversal rules defined in		specified service URN, MUST follow the URN traversal rules defined in
	[RFC5031].		[RFC5031].
	A LIS that receives a request for emergency routing information that		A LIS that receives a request for emergency routing information that
	it understands MUST return the correct emergency routing information		it understands MUST return the correct emergency routing information
	if it has or is able to acquire the routing information for the		if it has or is able to acquire the routing information for the
	location of the target device.		location of the target device.
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 28 ¶
	urn and might contain a general emergency service urn such as		urn and might contain a general emergency service urn such as
	urn:service:sos or might contain a specific service urn depending on		urn:service:sos or might contain a specific service urn depending on
	what was requested and what the LIS is able to provide. A list of		what was requested and what the LIS is able to provide. A list of
	one or more service destinations is provided for the service name.		one or more service destinations is provided for the service name.
	Each destination is expressed as a URI and each URI scheme should		Each destination is expressed as a URI and each URI scheme should
	only appear once in this list. The routing URIs are intended to be		only appear once in this list. The routing URIs are intended to be
	used at the time they are received. To avoid any risks of using		used at the time they are received. To avoid any risks of using
	stale routing URIs the values MUST NOT be cached by the receiving		stale routing URIs the values MUST NOT be cached by the receiving
	entity.		entity.
	5. HELD Schema Extension		5. Modification to Phone BCP
			This section describes the normative updates to Phone BCP [RFC6881].
			It is important for devices and intermediaries to take all steps
			possible to ensure that emergency calls are routed to the correct
			PSAPS. In absence of global forest guides or local LoST servers and
			the possibility that the local network may be configured with PSAP
			address information, this specification updates Phone BCP [RFC6881].
			The update requires devices and intermediaries using the HELD
			protocol to always include the HELD routing extension. If the LIS is
			configured with the routing information it can provide it, if it is
			not then the device or intermediary tries LoST to acquire the PSAP
			URI.
			Section 6.5 of [RFC6881] defines "End System Location Configuration".
			Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
			LCP such that "the request MUST include the requestRoutingInformation
			element". The remainder of the requirement remains unchanged.
			This document adds a new requirement to section 7 of [RFC6881].
			"ED-51a : Endpoints MUST support the HELD requestRoutingInformation
			element and be able and be able to interpret and use any routing
			information returned in the locationResponse."
			This document adds two new requirements to section 8 of [RFC6881].
			"ED-52a : Endpoints that acquire routing information in a HELD
			locationResponse SHOULD use this routing information but MAY perform
			a LoST findService request if they have a location value."
			"ED-52b : Endpoints that acquire routing information in a HELD
			locationResponse with a defaultRoute attribute of true MUST perform a
			LoST findService request if they have a location value. If a route
			is provided by the LoST server then this route MUST be used,
			otherwise the routing information provided in the HELD response
			SHOULD be used."
			This document amends SP-26 from Section 8 of [RFC6881] such that a
			LoST mapping need not be requested if non-default routing information
			is provided in the HELD locationResponse.
			6. HELD Schema Extension
	This section describes the schema extension to HELD.		This section describes the schema extension to HELD.
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"		targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"		xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
	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">
	skipping to change at page 8, line 29 ¶		skipping to change at page 9, line 29 ¶
	<xs:complexType name="service">		<xs:complexType name="service">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="dest" type="xs:anyURI"		<xs:element name="dest" type="xs:anyURI"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
			<xs:attribute name="defaultRoute" type="xs:boolean"
			use="optional" default="false"/>
	<xs:attribute name="serviceUri" type="xs:anyURI"		<xs:attribute name="serviceUri" type="xs:anyURI"
	use="required"/>		use="required"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:element name="routingInformation" type="ri:riType"/>		<xs:element name="routingInformation" type="ri:riType"/>
	<xs:complexType name="riType">		<xs:complexType name="riType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="service" type="ri:service"/>		<xs:element name="service" type="ri:service"/>
	<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:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	6. Examples		7. Examples
	Figure 3 illustrates a <locationRequest> example that contains IP		Figure 3 illustrates a <locationRequest> example that contains IP
	flow information in the request.		flow information in the request.
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
	responseTime="emergencyRouting">		responseTime="emergencyRouting">
	<requestRoutingInformation		<requestRoutingInformation
	xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>		xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
	skipping to change at page 10, line 32 ¶		skipping to change at page 12, line 5 ¶
	<dest>sip:112@example.com</dest>		<dest>sip:112@example.com</dest>
	<dest>sips:112@example.com</dest>		<dest>sips:112@example.com</dest>
	<dest>xmpp:112@example.com</dest>		<dest>xmpp:112@example.com</dest>
	</service>		</service>
	</routingInformation>		</routingInformation>
	</locationResponse>		</locationResponse>
	Figure 4: Example Location Response		Figure 4: Example Location Response
	7. Privacy Considerations		Figure 5 illustrates the <locationResponse> message containing
			default routing information and an HTTPS location URI.
			<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
			<locationUriSet expires="2016-01-01T13:00:00.0Z">
			<locationURI>
			https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
			</locationURI>
			</locationUriSet>
			<routingInformation
			xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
			<service defaultRoute="true" serviceUri="urn:service:sos">
			<dest>sip:112@example.com</dest>
			<dest>sips:112@example.com</dest>
			<dest>xmpp:112@example.com</dest>
			</service>
			</routingInformation>
			</locationResponse>
			Figure 5: Example Location Response with default routing information
			8. Privacy Considerations
	This document makes no changes that require privacy considerations		This document makes no changes that require privacy considerations
	beyond those already described in [RFC5687]. It does however extend		beyond those already described in [RFC5687]. It does however extend
	those described in [RFC6155].		those described in [RFC6155].
	[RFC5687] describes the issues surrounding Layer 7 location		[RFC5687] describes the issues surrounding Layer 7 location
	configuration protocols, which this document makes no specific		configuration protocols, which this document makes no specific
	changes to.		changes to.
	[RFC6155] extends HELD beyond a simple LCP by enabling authorized		[RFC6155] extends HELD beyond a simple location configuration
	third-parties to acquire location information and describes the		protocol (LCP) by enabling authorized third-parties to acquire
	issues in Section 4. The HELD Routing extension supports returning		location information and describes the issues in Section 4. The HELD
	URIs that represent specific services operating in the Target's		Routing extension supports returning URIs that represent specific
	vicinity. This represents additional information about the Target,		services operating in the Target's vicinity. This represents
	as a consequence it is recommended that this option only be used when		additional information about the Target, as a consequence it is
	a location URI is returned by the LIS.		recommended that this option only be used when the LIS returns a
			location URI, not a location value.
	8. Security Considerations		9. Security Considerations
	This document imposes no additional security considerations beyond		This document imposes no additional security considerations beyond
	those already described in [RFC5687] and [RFC6155].		those already described in [RFC5687] and [RFC6155].
	9. IANA Considerations		10. IANA Considerations
	9.1. URN sub-namespace registration for		10.1. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:geopriv:held:ri'		'urn:ietf:params:xml:ns:geopriv:held:ri'
	This document calls for IANA to register a new XML namespace, as per		This document calls for IANA to register a new XML namespace, as per
	the guidelines in [RFC3688].		the guidelines in [RFC3688].
	URI: urn:ietf:params:xml:ns:geopriv:held:ri		URI: urn:ietf:params:xml:ns:geopriv:held:ri
	Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org),		Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org),
	James Winterbottom (a.james.winterbottom@gmail.com).		James Winterbottom (a.james.winterbottom@gmail.com).
	XML:		XML:
	skipping to change at page 11, line 43 ¶		skipping to change at page 13, line 38 ¶
	<body>		<body>
	<h1>Additional Element for HELD Routing Information</h1>		<h1>Additional Element for HELD Routing Information</h1>
	<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>		<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
	[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX		[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
	with the RFC number for this specification.]]		with the RFC number for this specification.]]
	<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>		<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.2. XML Schema Registration		10.2. XML Schema Registration
	This section registers an XML schema as per the procedures in		This section registers an XML schema as per the procedures in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:schema:geopriv:held:ri		URI: urn:ietf:params:xml:schema:geopriv:held:ri
	Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),		Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),
	James Winterbottom (a.james.winterbottom@gmail.com).		James Winterbottom (a.james.winterbottom@gmail.com).
	The XML for this schema can be found as the entirety of Section 5		The XML for this schema can be found as the entirety of Section 6
	of this document.		of this document.
	10. Acknowledgements		11. Acknowledgements
	We would like to thank Wilfried Lange for sharing his views with us.		We would like to thank Wilfried Lange for sharing his views with us.
	We would also like to thank Bruno Chatras for his early review		We would also like to thank Bruno Chatras for his early review
	comments and Keith Drage ofr his more detailed review. Thanks to		comments and Keith Drage for his more detailed review. Thanks to
	Roger Marshall and Randy Gellens for their helpful suggestions.		Roger Marshall and Randy Gellens for their helpful suggestions.
	11. References		12. References
	11.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
			RFC 5985, DOI 10.17487/RFC5985, September 2010,
			<http://www.rfc-editor.org/info/rfc5985>.
			[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
			Communications Services in Support of Emergency Calling",
			BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
			<http://www.rfc-editor.org/info/rfc6881>.
			12.2. Informative References
			[M493] European Telecommunications Standards Institute,
			"Functional architecture to support European requirements
			on emergency caller location determination and transport",
			ES 203 178, V 1.0.5, December 2014.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for		[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	Emergency and Other Well-Known Services", RFC 5031,		Emergency and Other Well-Known Services", RFC 5031,
	DOI 10.17487/RFC5031, January 2008,		DOI 10.17487/RFC5031, January 2008,
	<http://www.rfc-editor.org/info/rfc5031>.		<http://www.rfc-editor.org/info/rfc5031>.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.		[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation		Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,		Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
	<http://www.rfc-editor.org/info/rfc5222>.		<http://www.rfc-editor.org/info/rfc5222>.
	[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol: Problem Statement and		Location Configuration Protocol: Problem Statement and
	Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,		Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,
	<http://www.rfc-editor.org/info/rfc5687>.		<http://www.rfc-editor.org/info/rfc5687>.
	[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
	RFC 5985, DOI 10.17487/RFC5985, September 2010,
	<http://www.rfc-editor.org/info/rfc5985>.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
	2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
	<http://www.rfc-editor.org/info/rfc6881>.
	11.2. Informative References
	[M493] European Telecommunications Standards Institute,
	"Functional architecture to support European requirements
	on emergency caller location determination and transport",
	ES 203 178, V 1.0.5, December 2014.
	[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local		[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
	Location Information Server (LIS)", RFC 5986,		Location Information Server (LIS)", RFC 5986,
	DOI 10.17487/RFC5986, September 2010,		DOI 10.17487/RFC5986, September 2010,
	<http://www.rfc-editor.org/info/rfc5986>.		<http://www.rfc-editor.org/info/rfc5986>.
	[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.		[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
	Barnes, "Use of Device Identity in HTTP-Enabled Location		Barnes, "Use of Device Identity in HTTP-Enabled Location
	Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March		Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March
	2011, <http://www.rfc-editor.org/info/rfc6155>.		2011, <http://www.rfc-editor.org/info/rfc6155>.
			[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
			"Framework for Emergency Calling Using Internet
			Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
			2011, <http://www.rfc-editor.org/info/rfc6443>.
	[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled		[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled
	Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915,		Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915,
	April 2013, <http://www.rfc-editor.org/info/rfc6915>.		April 2013, <http://www.rfc-editor.org/info/rfc6915>.
	[RFC7216] Thomson, M. and R. Bellis, "Location Information Server		[RFC7216] Thomson, M. and R. Bellis, "Location Information Server
	(LIS) Discovery Using IP Addresses and Reverse DNS",		(LIS) Discovery Using IP Addresses and Reverse DNS",
	RFC 7216, DOI 10.17487/RFC7216, April 2014,		RFC 7216, DOI 10.17487/RFC7216, April 2014,
	<http://www.rfc-editor.org/info/rfc7216>.		<http://www.rfc-editor.org/info/rfc7216>.
	Authors' Addresses		Authors' Addresses
End of changes. 30 change blocks.
	68 lines changed or deleted		143 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/