draft-ietf-ecrit-requirements-04.txt		draft-ietf-ecrit-requirements-05.txt
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Expires: August 23, 2006 R. Marshall, Ed.		Expires: August 31, 2006 R. Marshall, Ed.
	TCS		TCS
	February 19, 2006		February 27, 2006
	Requirements for Emergency Context Resolution with Internet		Requirements for Emergency Context Resolution with Internet
	Technologies		Technologies
	draft-ietf-ecrit-requirements-04.txt		draft-ietf-ecrit-requirements-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 23, 2006.		This Internet-Draft will expire on August 31, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document enumerates requirements for emergency calls placed by		This document enumerates requirements for emergency calls placed by
	the public using voice-over-IP (VoIP) and general Internet multimedia		the public using voice-over-IP (VoIP) and general Internet multimedia
	systems, where Internet protocols are used end-to-end.		systems, where Internet protocols are used end-to-end.
	skipping to change at page 16, line 18		skipping to change at page 16, line 18
	identifiers MUST be recognized by any device or network element		identifiers MUST be recognized by any device or network element
	for call setup purposes		for call setup purposes
	Motivation: There must be some way for any device or element to		Motivation: There must be some way for any device or element to
	recognize an emergency call throughout the call setup. This is		recognize an emergency call throughout the call setup. This is
	regardless of the device location, the application (voice) service		regardless of the device location, the application (voice) service
	provider used (if any at all), or of any other factor. Examples		provider used (if any at all), or of any other factor. Examples
	of these might include: 911, 112, and sos.*.		of these might include: 911, 112, and sos.*.
	Id2. Universal Identifier Resolution: Where multiple emergency		Id2. Universal Identifier Resolution: Where multiple emergency
	service types exist, it MUST be possible to treat each emergency		service types exist, the mapping protocol MUST support (i.e.
	identifier separately, based on the specific type of emergency		implement, though not necessarily use) the individual treatment of
	help requested.		each emergency identifier used, based on the specific type of
			emergency help requested.
	Id2. Universal Identifier Resolution: Where multiple emergency
	service types exist, the mapping protocol MUST support the
	individual treatment of each emergency identifier used, based on
	the specific type of emergency help requested.
	Motivation: Some jurisdictions may have multiple types of		Motivation: Some jurisdictions may have multiple types of
	emergency services available at the same level, (e.g. fire,		emergency services available at the same level, (e.g. fire,
	police, ambulance), in which case it is important that any one		police, ambulance), in which case it is important that any one
	could be selected directly.		could be selected directly.
	Id3. Emergency Marking: Any device in the signaling path that		Id3. Emergency Marking: Any device in the signaling path that
	recognizes by some means that the signaling is associated with an		recognizes by some means that the signaling is associated with an
	emergency call MUST add a specific emergency indication, if it		emergency call MUST add a specific emergency indication, if it
	doesn't already exist, to the signaling before forwarding it.		doesn't already exist, to the signaling before forwarding it.
	skipping to change at page 21, line 14		skipping to change at page 21, line 14
	Ma6. URI - Alternate Contact: The mapping protocol MUST support		Ma6. URI - Alternate Contact: The mapping protocol MUST support
	(i.e. implement, though not necessarily use), the return of a URI		(i.e. implement, though not necessarily use), the return of a URI
	or contact method explicitly marked as an alternate contact.		or contact method explicitly marked as an alternate contact.
	Motivation: In response to a mapping request, if an expected URI		Motivation: In response to a mapping request, if an expected URI
	is unable to be returned, then mapping server may return an		is unable to be returned, then mapping server may return an
	alternate URI. When and how this would be used will be described		alternate URI. When and how this would be used will be described
	in an operational document.		in an operational document.
	Ma7. Multiple PSAP URIs: The mapping protocol MUST be able to return
	multiple URIs for different PSAPs that cover the same area.
	Ma7. Multiple PSAP URIs: The mapping protocol MUST support (i.e.		Ma7. Multiple PSAP URIs: The mapping protocol MUST support (i.e.
	implement, though not necessarily use), a method to be able to		implement, though not necessarily use), a method to be able to
	return multiple URIs for different PSAPs that cover the same area.		return multiple URIs for different PSAPs that cover the same area.
	Ma8. URL properties: The mapping protocol must provide additional
	information that allows the querying entity to determine relevant
	properties of the URL.
	Ma8. URL properties: The mapping protocol MUST support (i.e.		Ma8. URL properties: The mapping protocol MUST support (i.e.
	implement, thought not necessarily use), the ability to provide		implement, though not necessarily use), the ability to provide
	additional information that allows the querying entity to		additional information that allows the querying entity to
	determine relevant properties of the URL.		determine relevant properties of the URL.
	Motivation: In some cases, the same geographic area is served by		Motivation: In some cases, the same geographic area is served by
	several PSAPs, for example, a corporate campus might be served by		several PSAPs, for example, a corporate campus might be served by
	both a corporate security department and the municipal PSAP. The		both a corporate security department and the municipal PSAP. The
	mapping protocol should then return URLs for both, with		mapping protocol should then return URLs for both, with
	information allowing the querying entity to choose one or the		information allowing the querying entity to choose one or the
	other. This determination could be made by either an ESRP, based		other. This determination could be made by either an ESRP, based
	on local policy, or by direct user choice, in the case of caller-		on local policy, or by direct user choice, in the case of caller-
End of changes. 8 change blocks.
	20 lines changed or deleted		9 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/