< draft-rosen-ecrit-data-only-ea-00.txt		draft-rosen-ecrit-data-only-ea-01.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Experimental H. Schulzrinne		Intended status: Experimental H. Schulzrinne
	Expires: April 22, 2010 Columbia U.		Expires: September 7, 2010 Columbia U.
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	October 19, 2009		March 6, 2010
	Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using		Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using
	the Session Initiation Protocol (SIP)		the Session Initiation Protocol (SIP)
	draft-rosen-ecrit-data-only-ea-00.txt		draft-rosen-ecrit-data-only-ea-01.txt
			Abstract
			The Common Alerting Protocol (CAP) is an XML document format for
			exchanging emergency alerts and public warnings. CAP is mainly used
			for conveying alerts and warnings between authorities and from
			authorities to citizen/individuals. This document describes how
			data-only emergency alerts allow to utilize the same CAP document
			format.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), 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.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 45 ¶
	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 April 22, 2010.		This Internet-Draft will expire on September 7, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The Common Alerting Protocol (CAP) is an XML document format for		described in the BSD License.
	exchanging emergency alerts and public warnings. CAP is mainly used
	for conveying alerts and warnings between authorities and from
	authorities to citizen/individuals. This document describes how
	data-only emergency alerts allow to utilize the same CAP document
	format.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 3		3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5
	4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5		4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 7
	4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 5		4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Profiling of the CAP Document Content . . . . . . . . . . 6		4.2. Profiling of the CAP Document Content . . . . . . . . . . 7
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 8		6.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
	6.3. Injecting False Alerts . . . . . . . . . . . . . . . . . . 8		6.3. Injecting False Alerts . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Registration of the		7.1. Registration of the
	'application/common-alerting-protocol+xml' MIME type . . . 9		'application/common-alerting-protocol+xml' MIME type . . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Common Alerting Protocol (CAP) [cap] is an XML document format		The Common Alerting Protocol (CAP) [cap] is an XML document format
	for exchanging emergency alerts and public warnings. CAP is mainly		for exchanging emergency alerts and public warnings. CAP is mainly
	used for conveying alerts and warnings between authorities and from		used for conveying alerts and warnings between authorities and from
	authorities to citizen/individuals. This document describes how		authorities to citizen/individuals. This document describes how
	data-only emergency calls are able to utilize the same CAP document		data-only emergency calls are able to utilize the same CAP document
	format. Data-only emergency alerts may be similar to regular		format. Data-only emergency alerts may be similar to regular
	emergency calls in the sense that they have the same emergency call		emergency calls in the sense that they have the same emergency call
	skipping to change at page 6, line 24 ¶		skipping to change at page 7, line 32 ¶
	sender: When the CAP was created by a SIP-based entity then the		sender: When the CAP was created by a SIP-based entity then the
	element MUST be populated with the SIP URI of that entity.		element MUST be populated with the SIP URI of that entity.
	incidents: The <incidents> element MUST be present whenever there is		incidents: The <incidents> element MUST be present whenever there is
	a possibility that alert information needs to be updated. The		a possibility that alert information needs to be updated. The
	initial message will then contain an incident identifier carried		initial message will then contain an incident identifier carried
	in the <incidents> element. This incident identifier MUST be		in the <incidents> element. This incident identifier MUST be
	chosen in such a way that it is unique for a given sender /		chosen in such a way that it is unique for a given sender /
	expires combination.		expires combination.
	scope: The value of the <scope> element MUST be set to private as
	the alert is not meant for public consumption.		scope: The value of the <scope> element MUST be set to "private" as
			the alert is not meant for public consumption. The <addresses>
			element is, however, not used by this specification since the
			message routing is performed by SIP and the respective address
			information is already available there. Populating address
			information twice into different parts of the message can quickly
			lead to inconsistency.
	parameter: The <parameter> element MAY contain additional		parameter: The <parameter> element MAY contain additional
	information specific to the sensor.		information specific to the sensor.
	area: For geodetic information the polygon and circle location		area: For geodetic information the polygon and circle location
	shapes are available. The ability to conveying a structured		shapes are available. The ability to conveying a structured
	format of civic location information is missing and hence civic		format of civic location information is missing and hence civic
	information is encoded as a text string in the <areaDesc> element.		information is encoded as a text string in the <areaDesc> element.
	[Editor's Note: The usage of a number of CAP elements is unclear
	and/or insufficient and requires further discussion with the authors
	of the CAP specification. Based on the outcome of these discussions
	more fields might require profiling.]
	5. Example		5. Example
	Figure 3 shows a CAP document indicating a BURLARY alert issued by		Figure 3 shows a CAP document indicating a BURLARY alert issued by
	sensor1@example.com indicating that the alert was issued from the		sensor1@example.com indicating that the alert was issued from the
	civic address NATURAL HISTORY MUSEUM, BURGRING 7, 1010 VIENNA,		civic address NATURAL HISTORY MUSEUM, BURGRING 7, 1010 VIENNA,
	AUSTRIA. Additionally, the sensor provided some additional data long		AUSTRIA. Additionally, the sensor provided some additional data long
	with the alert message using non-standardized information elements.		with the alert message using non-standardized information elements.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	skipping to change at page 10, line 47 ¶		skipping to change at page 14, line 31 ¶
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-ecrit-phonebcp]		[I-D.ietf-ecrit-phonebcp]
	Rosen, B. and J. Polk, "Best Current Practice for		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-13 (work in progress),		draft-ietf-ecrit-phonebcp-14 (work in progress),
	July 2009.		January 2010.
	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:
End of changes. 11 change blocks.
	45 lines changed or deleted		50 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/