< draft-winterbottom-ecrit-priv-loc-02.txt		draft-winterbottom-ecrit-priv-loc-03.txt >
	ECRIT J. Winterbottom		ECRIT J. Winterbottom
	Internet-Draft CommScope		Internet-Draft CommScope
	Intended status: Standards Track H. Tschofenig		Updates: I-D.ietf.ecrit.phonebcp H. Tschofenig
	Expires: April 19, 2013 Nokia Siemens Networks		(if approved) Nokia Siemens Networks
	L. Liess		Intended status: Standards Track L. Liess
	Deutsche Telekom		Expires: April 19, 2013 Deutsche Telekom
	October 16, 2012		October 16, 2012
	Out of Jurisdiction Emergency Routing		Out of Jurisdiction Emergency Routing
	draft-winterbottom-ecrit-priv-loc-02.txt		draft-winterbottom-ecrit-priv-loc-03
	Abstract		Abstract
	Some countries and regions require location information be		Some countries and regions require location information be
	constrained to emergency service applications and do not permit		constrained to emergency service applications and do not permit
	location information to traverse the end-point at all. This document		location information to traverse the end-point at all. This document
	describes the requirements of these countries and provides a solution		describes the requirements of these countries and provides a solution
	based on an extension to the HELD location protocol.		based on an extension to the HELD location protocol.
	Status of this Memo		Status of this Memo
	skipping to change at page 11, line 43 ¶		skipping to change at page 11, line 43 ¶
	| | +-----------+ |		| | +-----------+ |
	| +--(7)-locReq(Auth)--+ | |		| +--(7)-locReq(Auth)--+ | |
	| | ESRP/PSAP |<--(6)-Call(locURI)-+		| | ESRP/PSAP |<--(6)-Call(locURI)-+
	+---(8)-locResp(Loc)--->| |		+---(8)-locResp(Loc)--->| |
	+-----------+		+-----------+
	Figure 5: Emergency Call Domains		Figure 5: Emergency Call Domains
	7. HELD Extensions to Support Emergency Routing Information		7. HELD Extensions to Support Emergency Routing Information
	Figure 4 describes the enhancements needed to support the new calling		Figure 4 shows the enhancements needed to support the new calling
	model. Since the VSP has no means of determining if the LIS in the		model. If the LIS implements this specification then it responds as
	access network supports this modified calling model or not, there is		shown in Figure 4, otherwise it responds with standard HELD [RFC5985]
	no need to modify the syntax of locationRequest message sent to the		[RFC6155] semantics. Consequently, the locationRequest message is
	LIS. The location request MUST include a responseTime of		not modified.
			It is recommended that the location request include a responseTime of
	emergencyRouting to ensure that the LIS provides a response to the		emergencyRouting to ensure that the LIS provides a response to the
	VSP as quickly as possible. When using IP related information		VSP as quickly as possible.
	identify the UA to the LIS then the identify information MUST be
	expressed using the IP flow representation specified in
	[I-D.ietf-geopriv-flow-identity]. This approach ensures that any
	issues caused by address translation entities in the path can be
	mitigated as far as possible. It also supports the LIS returning a
	location allowing invocation of the standard switch-centric calling
	procedures. A new optional "emergencyRoutingInformation" element is
	added to the locationResponse message containing the relevant
	destination URLs.
	The list of destination URLs provided in the		When using IP related information to identify the UA to the LIS then
	"emergencyRoutingInformation" element MUST conform to the same		the identity information MUST be expressed using the IP flow
	contraints as the service URLs returned in the LoST [RFC5222] in the		representation specified in [I-D.ietf-geopriv-flow-identity]. This
	findServiceResponse. For clarity these constraints are repreated		minimizes any issues caused by address translation entities in the
	here:		location path.
			A new optional "emergencyRoutingInformation" element containing the
			relevant destination URLs is added to the locationResponse message.
			The list of destination URLs provided MUST conform to the same
			contraints as the service URLs returned in the LoST protocol
			[RFC5222] in the findServiceResponse. For clarity these constraints
			are repreated here:
	1. The URLs MUST be absolute URLs		1. The URLs MUST be absolute URLs
	2. The ordering of the URLs has no particular significance		2. The ordering of the URLs has no particular significance
	3. Each URL scheme MUST only appear at most once		3. Each URL scheme MUST only appear at most once
	4. It is permissible to include both secured and regular versions of		4. It is permissible to include both secured and regular versions of
	a protocol		a protocol
			This specification updates the switch-centric call model in
			[I-D.ietf-ecrit-phonebcp]. In addition to supporting the return of a
			location value or location URI set from the LIS, the VSP MUST support
			receiving only a location URI set and a set of URLs identifying the
			emergency service routing proxies associated with the UA's location.
	7.1. HELD Schema Extension		7.1. 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:eri"		targetNamespace="urn:ietf:params:xml:ns:geopriv:held:eri"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:eri="urn:ietf:params:xml:ns:geopriv:held:eri"		xmlns:eri="urn:ietf:params:xml:ns:geopriv:held:eri"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
End of changes. 6 change blocks.
	25 lines changed or deleted		31 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/