< draft-ietf-ecrit-psap-callback-06.txt		draft-ietf-ecrit-psap-callback-07.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: April 25, 2013 Nokia Siemens Networks		Expires: June 21, 2013 Nokia Siemens Networks
	C. Holmberg		C. Holmberg
	Ericsson		Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	October 22, 2012		December 18, 2012
	Public Safety Answering Point (PSAP) Callback		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-06.txt		draft-ietf-ecrit-psap-callback-07.txt
	Abstract		Abstract
	After an emergency call is completed (either prematurely terminated		After an emergency call is completed (either prematurely terminated
	by the emergency caller or normally by the call taker) it is possible		by the emergency caller or normally by the call taker) it is possible
	that the call taker feels the need for further communication. For		that the call taker feels the need for further communication. For
	example, the call may have been dropped by accident without the call		example, the call may have been dropped by accident without the call
	taker having sufficient information about the current situation of a		taker having sufficient information about the current situation of a
	wounded person. A call taker may trigger a callback towards the		wounded person. A call taker may trigger a callback towards the
	emergency caller using the contact information provided with the		emergency caller using the contact information provided with the
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 25, 2013.		This Internet-Draft will expire on June 21, 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 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
	4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 14		5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Security Requirements . . . . . . . . . . . . . . . . . . 14		5.2. Security Requirements . . . . . . . . . . . . . . . . . . 14
	5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 14		5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Summoning police, the fire department or an ambulance in emergencies		Summoning police, the fire department or an ambulance in emergencies
	is one of the fundamental and most-valued functions of the telephone.		is one of the fundamental and most-valued functions of the telephone.
	As telephone functionality moves from circuit-switched telephony to		As telephone functionality moves from circuit-switched telephony to
	Internet telephony, its users rightfully expect that this core		Internet telephony, its users rightfully expect that this core
	functionality will continue to work at least as well as it has for		functionality will continue to work at least as well as it has for
	the legacy technology. New devices and services are being made		the legacy technology. New devices and services are being made
	available that could be used to make a request for help, which are		available that could be used to make a request for help, which are
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 7 ¶
	simple. For SIP UAs there is no need to maintain a list of PSAPs.		simple. For SIP UAs there is no need to maintain a list of PSAPs.
	Instead SIP UAs are assumed to trust the correct processing of their		Instead SIP UAs are assumed to trust the correct processing of their
	VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,		VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,
	if it cannot be verified, the PSAP callback marking is removed. If		if it cannot be verified, the PSAP callback marking is removed. If
	it is left untouched then the SIP UA should assume that it has been		it is left untouched then the SIP UA should assume that it has been
	verified successfully by the VSP/ASP and it should therefore be		verified successfully by the VSP/ASP and it should therefore be
	obeyed.		obeyed.
	6. IANA Considerations		6. IANA Considerations
	[Editor's Note: There is currently no registry available for the SIP		This document adds the "psap-callback" value to the SIP Priority
	Priority header. A registry needs to be created and the value		header IANA registry allocated by [I-D.ietf-sipcore-priority]. The
	defined in this document needs to be added.]		semantic of the newly defined "psap-callback" value is defined in
			Section 4.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank members from the ECRIT working group, in		We would like to thank members from the ECRIT working group, in
	particular Brian Rosen, for their discussions around PSAP callbacks.		particular Brian Rosen, for their discussions around PSAP callbacks.
	The working group discussed the topic of callbacks at their virtual		The working group discussed the topic of callbacks at their virtual
	interim meeting in February 2010 and the following persons provided		interim meeting in February 2010 and the following persons provided
	valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith		valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
	Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,		Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
	Janet Gunn.		Janet Gunn.
	skipping to change at page 18, line 9 ¶		skipping to change at page 18, line 9 ¶
	We would like to thank the following persons for their feedback on		We would like to thank the following persons for their feedback on
	the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert		the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert
	Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,		Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,
	Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John		Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John
	Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn		Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to		[I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the
	Indicate Requirement Levels", BCP 14,		Session Initiation Protocol (SIP)
	RFC 2119, March 1997.		"Priority" Header Field",
			draft-ietf-sipcore-priority-00 (work in
			progress), December 2012.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo,		[RFC2119] Bradner, S., "Key words for use in RFCs
	G., Johnston, A., Peterson, J., Sparks,		to Indicate Requirement Levels", BCP 14,
	R., Handley, M., and E. Schooler, "SIP:		RFC 2119, March 1997.
	Session Initiation Protocol", RFC 3261,
	June 2002.
	[RFC3325] Jennings, C., Peterson, J., and M. Watson,		[RFC3261] Rosenberg, J., Schulzrinne, H.,
	"Private Extensions to the Session		Camarillo, G., Johnston, A., Peterson,
	Initiation Protocol (SIP) for Asserted		J., Sparks, R., Handley, M., and E.
	Identity within Trusted Networks",		Schooler, "SIP: Session Initiation
	RFC 3325, November 2002.		Protocol", RFC 3261, June 2002.
	[RFC3966] Schulzrinne, H., "The tel URI for		[RFC3325] Jennings, C., Peterson, J., and M.
	Telephone Numbers", RFC 3966,		Watson, "Private Extensions to the
	December 2004.		Session Initiation Protocol (SIP) for
			Asserted Identity within Trusted
			Networks", RFC 3325, November 2002.
	[RFC3969] Camarillo, G., "The Internet Assigned		[RFC3966] Schulzrinne, H., "The tel URI for
	Number Authority (IANA) Uniform Resource		Telephone Numbers", RFC 3966,
	Identifier (URI) Parameter Registry for		December 2004.
	the Session Initiation Protocol (SIP)",
	BCP 99, RFC 3969, December 2004.
	[RFC4474] Peterson, J. and C. Jennings,		[RFC3969] Camarillo, G., "The Internet Assigned
	"Enhancements for Authenticated Identity		Number Authority (IANA) Uniform Resource
	Management in the Session Initiation		Identifier (URI) Parameter Registry for
	Protocol (SIP)", RFC 4474, August 2006.		the Session Initiation Protocol (SIP)",
			BCP 99, RFC 3969, December 2004.
	[RFC5627] Rosenberg, J., "Obtaining and Using		[RFC4474] Peterson, J. and C. Jennings,
	Globally Routable User Agent URIs (GRUUs)		"Enhancements for Authenticated Identity
	in the Session Initiation Protocol (SIP)",		Management in the Session Initiation
	RFC 5627, October 2009.		Protocol (SIP)", RFC 4474, August 2006.
			[RFC5627] Rosenberg, J., "Obtaining and Using
			Globally Routable User Agent URIs
			(GRUUs) in the Session Initiation
			Protocol (SIP)", RFC 5627, October 2009.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current		[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current
	Practice for Communications Services in		Practice for Communications Services in
	support of Emergency Calling",		support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-20 (work in		draft-ietf-ecrit-phonebcp-20 (work in
	progress), September 2011.		progress), September 2011.
	[RFC4484] Peterson, J., Polk, J., Sicker, D., and H.		[RFC4484] Peterson, J., Polk, J., Sicker, D., and
	Tschofenig, "Trait-Based Authorization		H. Tschofenig, "Trait-Based
	Requirements for the Session Initiation		Authorization Requirements for the
	Protocol (SIP)", RFC 4484, August 2006.		Session Initiation Protocol (SIP)",
			RFC 4484, August 2006.
	[RFC5012] Schulzrinne, H. and R. Marshall,		[RFC5012] Schulzrinne, H. and R. Marshall,
	"Requirements for Emergency Context		"Requirements for Emergency Context
	Resolution with Internet Technologies",		Resolution with Internet Technologies",
	RFC 5012, January 2008.		RFC 5012, January 2008.
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name		[RFC5031] Schulzrinne, H., "A Uniform Resource
	(URN) for Emergency and Other Well-Known		Name (URN) for Emergency and Other Well-
	Services", RFC 5031, January 2008.		Known Services", RFC 5031, January 2008.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF		[RFC5234] Crocker, D. and P. Overell, "Augmented
	for Syntax Specifications: ABNF", STD 68,		BNF for Syntax Specifications: ABNF",
	RFC 5234, January 2008.		STD 68, RFC 5234, January 2008.
	[RFC6444] Schulzrinne, H., Liess, L., Tschofenig,		[RFC6444] Schulzrinne, H., Liess, L., Tschofenig,
	H., Stark, B., and A. Kuett, "Location		H., Stark, B., and A. Kuett, "Location
	Hiding: Problem Statement and		Hiding: Problem Statement and
	Requirements", RFC 6444, January 2012.		Requirements", RFC 6444, January 2012.
	Authors' Addresses		Authors' Addresses
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
End of changes. 19 change blocks.
	60 lines changed or deleted		68 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/