< draft-rosen-ecrit-ecall-01.txt		draft-rosen-ecrit-ecall-02.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: BCP H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: January 13, 2009 Nokia Siemens Networks		Expires: September 8, 2009 Nokia Siemens Networks
	U. Dietz		U. Dietz
	Vodafone		Vodafone
	July 12, 2008		March 7, 2009
	Best Current Practice for IP-based In-Vehicle Emergency Calls		Best Current Practice for IP-based In-Vehicle Emergency Calls
	draft-rosen-ecrit-ecall-01.txt		draft-rosen-ecrit-ecall-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 January 13, 2009.		This Internet-Draft will expire on September 8, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This document describes how to use a subset of the IETF-based		This document describes how to use a subset of the IETF-based
	emergency call framework for accomplishing emergency calling support		emergency call framework for accomplishing emergency calling support
	in vehicles. Simplifications are possible due to the nature of the		in vehicles. Simplifications are possible due to the nature of the
	functionality that is going to be provided in vehicles with the usage		functionality that is going to be provided in vehicles with the usage
	of GPS. Additionally, further profiling needs to be done regarding		of GPS. Additionally, further profiling needs to be done regarding
	the encoding of location information.		the encoding of location information.
	skipping to change at page 2, line 29 ¶		skipping to change at page 3, line 4 ¶
	4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative references . . . . . . . . . . . . . . . . . 15		10.2. Informative references . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Emergency calls made from vehicles can assist with the objective of		Emergency calls made from vehicles can assist with the objective of
	significantly reducing road deaths and injuries. Unfortunately,		significantly reducing road deaths and injuries. Unfortunately,
	drivers often have a poor location-awareness, especially on urban		drivers often have a poor location-awareness, especially on urban
	roads (also during night) and abroad. In the most crucial cases, the		roads (also during night) and abroad. In the most crucial cases, the
	victim(s) may not be able to call because they have been injured or		victim(s) may not be able to call because they have been injured or
	trapped.		trapped.
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	8. Acknowledgements		8. Acknowledgements
	We would like to thank Michael Montag for his feedback.		We would like to thank Michael Montag for his feedback.
	9. Open Issues		9. Open Issues
	While working on this document a few aspects where discovered that		While working on this document a few aspects where discovered that
	require further discussion:		require further discussion:
	o Today's work on the eCall system does not necessary require a		o Today's work on the eCall system does not necessarily require a
	voice call to be established; a voice call may be established		voice call to be established; a voice call may be established
	whenever possible by the functionality offered by the device.		whenever possible by the functionality offered by the device.
	From a protocol mechanims, however, the design for establishing an		From a protocol mechanims, however, the design for establishing an
	emergency call including voice and without voice support are		emergency call including voice and without voice support are
	somewhat different. Further discussion on the design aspects are		somewhat different. Further discussion on the design aspects are
	needed to align this aspect.		needed to align this aspect.
	o This document currently defines a new service URN to differentiate		o This document currently defines a new service URN to differentiate
	it from ordinary calls as in-vehicular emergency calls are, in		it from ordinary calls as in-vehicular emergency calls are, in
	some countries, routed to different PSAPs than regular emergency		some countries, routed to different PSAPs than regular emergency
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Rosen, B. and J. Polk, "Best Current Practice for		[2] 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-05 (work in progress), July 2008.		draft-ietf-ecrit-phonebcp-08 (work in progress), February 2009.
	[3] Peterson, J., "A Presence-based GEOPRIV Location Object		[3] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[4] Polk, J. and B. Rosen, "Location Conveyance for the Session		[4] Polk, J. and B. Rosen, "Location Conveyance for the Session
	Initiation Protocol", draft-ietf-sip-location-conveyance-10		Initiation Protocol", draft-ietf-sip-location-conveyance-12
	(work in progress), February 2008.		(work in progress), November 2008.
	[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller		[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
	Preferences for the Session Initiation Protocol (SIP)",		Preferences for the Session Initiation Protocol (SIP)",
	RFC 3841, August 2004.		RFC 3841, August 2004.
	[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	PIDF-LO Usage Clarification, Considerations and		PIDF-LO Usage Clarification, Considerations and
	Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work		Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work
	in progress), February 2008.		in progress), November 2008.
	[7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic		[7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic
	Feature Extensions to the Presence Information Data Format		Feature Extensions to the Presence Information Data Format
	Location Object (PIDF-LO)",		Location Object (PIDF-LO)",
	draft-singh-geopriv-pidf-lo-dynamic-02 (work in progress),		draft-singh-geopriv-pidf-lo-dynamic-04 (work in progress),
	November 2007.		October 2008.
	[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency		[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
	and Other Well-Known Services", RFC 5031, January 2008.		and Other Well-Known Services", RFC 5031, January 2008.
	10.2. Informative references		10.2. Informative references
	[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies", RFC 5012,		Context Resolution with Internet Technologies", RFC 5012,
	January 2008.		January 2008.
	[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,		[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
	"Security Threats and Requirements for Emergency Call Marking		"Security Threats and Requirements for Emergency Call Marking
	and Mapping", RFC 5069, January 2008.		and Mapping", RFC 5069, January 2008.
	[11] Tschofenig, H. and H. Schulzrinne, "Trustworthy Location		[11] Tschofenig, H. and H. Schulzrinne, "Trustworthy Location
	Information", draft-tschofenig-ecrit-trustworthy-location-00		Information", draft-tschofenig-ecrit-trustworthy-location-01
	(work in progress), July 2008.		(work in progress), March 2009.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar, Inc.		NeuStar, Inc.
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone:		Phone:
	skipping to change at page 18, line 4 ¶		skipping to change at line 430 ¶
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Ulrich Dietz		Ulrich Dietz
	Vodafone		Vodafone
	Chiemgaustrasse 116		Chiemgaustrasse 116
	Munich 81549		Munich 81549
	Germany		Germany
	Email: Ulrich.Dietz@vodafone.com		Email: Ulrich.Dietz@vodafone.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 13 change blocks.
	20 lines changed or deleted		28 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/