< draft-rosen-sipping-cap-02.txt		draft-rosen-sipping-cap-03.txt >
	SIPPING B. Rosen		SIPPING B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: January 13, 2009 Columbia U.		Expires: September 8, 2009 Columbia U.
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	July 12, 2008		March 7, 2009
	Session Initiation Protocol (SIP) Event Package for the Common Alerting		Session Initiation Protocol (SIP) Event Package for the Common Alerting
	Protocol (CAP)		Protocol (CAP)
	draft-rosen-sipping-cap-02.txt		draft-rosen-sipping-cap-03.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
	The Common Alerting Protocol (CAP) is an XML document format for		The Common Alerting Protocol (CAP) is an XML document format for
	exchanging emergency alerts and public warnings. This document		exchanging emergency alerts and public warnings. This document
	allows CAP documents to be distributed via the event notification		allows CAP documents to be distributed via the event notification
	mechanism available with the Session Initiation Protocol (SIP).		mechanism available with the Session Initiation Protocol (SIP).
	Table of Contents		Table of Contents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 36 ¶
	3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6		3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6
	3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6		3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6
	3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 6		3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 6
	3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 6		3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 6
	3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7		3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7
	3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7		3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7
	3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7		3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7
	3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 7		3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 7
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. Known Open Issues . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5.2. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Registration of the 'common-alerting-protocol' Event		5.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
	Package . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.4. Unauthorized Distribution . . . . . . . . . . . . . . . . 10
	7.2. Registration of the		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	'application/common-alerting-protocol+xml' MIME type . . . 9		6.1. Registration of the 'common-alerting-protocol' Event
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		Package . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. Registration of the
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 10		'application/common-alerting-protocol+xml' MIME type . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	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. This document		for exchanging emergency alerts and public warnings. This document
	allows CAP documents to be distributed via the event notification		allows CAP documents to be distributed via the event notification
	mechanism available with the Session Initiation Protocol (SIP).		mechanism available with the Session Initiation Protocol (SIP).
			Additionally, a MIME object is registered to allow CAP documents to
			be exchanged in other SIP documents.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. The 'common-alerting-protocol' Event Package		3. The 'common-alerting-protocol' Event Package
	RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote		RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote
	nodes and receiving notifications of changes (events) in their		nodes and receiving notifications of changes (events) in their
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 37 ¶
	such an event package. This section fills in the information		such an event package. This section fills in the information
	required for all event packages by RFC 3265.		required for all event packages by RFC 3265.
	Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP		Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP
	User Agents to publish event state. According to RFC 3903, any event		User Agents to publish event state. According to RFC 3903, any event
	package intended to be used in conjunction with the SIP PUBLISH		package intended to be used in conjunction with the SIP PUBLISH
	method has to include a considerations section. This section also		method has to include a considerations section. This section also
	fills the information for all event packages to be used with PUBLISH		fills the information for all event packages to be used with PUBLISH
	requests.		requests.
	We define a new "common-alerting-protocol" event package. Event		This document defines a new "common-alerting-protocol" event package.
	Publication Agents (EPA) use PUBLISH requests to inform an Event		Event Publication Agents (EPA) use PUBLISH requests to inform an
	State Compositor (ESC) of changes in the common-alerting-protocol		Event State Compositor (ESC) of changes in the common-alerting-
	event package. Acting as a notifier, the ESC notifies subscribers		protocol event package. Acting as a notifier, the ESC notifies
	about emergency alerts and public warnings.		subscribers about emergency alerts and public warnings.
	3.1. Package Name		3.1. Package Name
	The name of this package is "common-alerting-protocol". As specified		The name of this package is "common-alerting-protocol". As specified
	in RFC 3265 [RFC3265], this value appears in the Event header field		in RFC 3265 [RFC3265], this value appears in the Event header field
	present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903		present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903
	[RFC3903], this value also appears in the Event header field present		[RFC3903], this value also appears in the Event header field present
	in PUBLISH requests.		in PUBLISH requests.
	3.2. Event Package Parameters		3.2. Event Package Parameters
	RFC 3265 [RFC3265] allows event packages to define additional		RFC 3265 [RFC3265] allows event packages to define additional
	parameters carried in the Event header field. This event package,		parameters carried in the Event header field. This event package,
	"common-alerting-protocol", does not define additional parameters.		"common-alerting-protocol", does not define additional parameters.
	3.3. SUBSCRIBE Bodies		3.3. SUBSCRIBE Bodies
	According to RFC 3265 [RFC3265], a SUBSCRIBE request can contain a		RFC 3265 [RFC3265] allows a SUBSCRIBE request to contain a body.
	body. The purpose of the body depends on its type.		This document allows the body to contain civic and geodetic location
			information to be carried. The 2D location shapes listed in
	[Editor's Note: It is an open issue whether subscriptions to the		[I-D.ietf-geopriv-pdif-lo-profile], e.g., <Point> <Polygon>,
	"common-alerting-protocol" event package carry information in their		<Circle>, <Ellipse>, <ArcBand>, and a <civicAddress> element, defined
	body, such as a polygon defining an area for which notifications		in [RFC5139], in the body of the message. The recipient of the
	should be received. See Section 6.]		SUBSCRIBE message SHOULD use this information to restrict the warning
			messages that are being delivered. [Editor's note: Information about
			the type of alerts that shall be received may need to be indicated as
			well.]
	3.4. Subscription Duration		3.4. Subscription Duration
	The default expiration time for subscriptions within this package is		The default expiration time for subscriptions within this package is
	3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify		3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify
	an alternate expiration in the Expires header field.		an alternate expiration in the Expires header field.
	3.5. NOTIFY Bodies		3.5. NOTIFY Bodies
	As described in RFC 3265 [RFC3265], the NOTIFY message will contain		As described in RFC 3265 [RFC3265], the NOTIFY message will contain
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	<sender>KSTO@NWS.NOAA.GOV</sender>		<sender>KSTO@NWS.NOAA.GOV</sender>
	<sent>2003-06-17T14:57:00-07:00</sent>		<sent>2003-06-17T14:57:00-07:00</sent>
	<status>Actual</status>		<status>Actual</status>
	<msgType>Alert</msgType>		<msgType>Alert</msgType>
	<scope>Public</scope>		<scope>Public</scope>
	<info>		<info>
	<category>Met</category>		<category>Met</category>
	<event>SEVERE THUNDERSTORM</event>		<event>SEVERE THUNDERSTORM</event>
	<urgency>Severe</urgency>		<urgency>Severe</urgency>
	<certainty>Likely</certainty>		<certainty>Likely</certainty>
	<eventCode>same=SVR</eventCode>
	<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>		<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
	<headline>SEVERE THUNDERSTORM WARNING</headline>		<headline>SEVERE THUNDERSTORM WARNING</headline>
	<description> AT 254 PM PDT...		<description> AT 254 PM PDT...
	NATIONAL WEATHER SERVICE		NATIONAL WEATHER SERVICE
	DOPPLER RADAR INDICATED A SEVERE		DOPPLER RADAR INDICATED A SEVERE
	THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...		THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
	OR ABOUT 18 MILES SOUTHEAST OF		OR ABOUT 18 MILES SOUTHEAST OF
	KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...		KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
	INTENSE RAIN AND STRONG DAMAGING WINDS		INTENSE RAIN AND STRONG DAMAGING WINDS
	ARE LIKELY WITH THIS STORM </description>		ARE LIKELY WITH THIS STORM </description>
	<instruction> TAKE COVER IN A SUBSTANTIAL SHELTER		<instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
	UNTIL THE STORM PASSES </instruction>		UNTIL THE STORM PASSES </instruction>
	<contact>BARUFFALDI/JUSKIE</contact>		<contact>BARUFFALDI/JUSKIE</contact>
	<area>		<area>
	<areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY		<areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
	IN CALIFORNIA, EXTREME NORTHEASTERN		IN CALIFORNIA, EXTREME NORTHEASTERN
	CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN		CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
	ALPINE COUNTY IN CALIFORNIA </areaDesc>		ALPINE COUNTY IN CALIFORNIA </areaDesc>
	<polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74		<polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
	38.62,-119.89 38.47,-120.14 </polygon>		38.62,-119.89 38.47,-120.14 </polygon>
	<geocode>fips6=006109</geocode>
	<geocode>fips6=006109</geocode>
	<geocode>fips6=006103</geocode>
	</area>		</area>
	</info>		</info>
	</alert>		</alert>
	Example for a Severe Thunderstorm Warning		Example for a Severe Thunderstorm Warning
	5. Security Considerations		5. Security Considerations
	[Editor's Note: A future version of this document will describe		This section discusses security considerations when using SIP to
	security considerations.]		distribute warning messages using CAP.
	6. Known Open Issues		5.1. Man-in-the-Middle Attacks
	Frequently, alerting events are only of regional interest since they		Threat:
	only have regional impact. For example: The public in NYC does not
	really need to be alerted about a wild fire at Lake Tahoe. One
	possible solution is the ability to allow SUBSCRIBE bodies to have a
	region description that describes the geographic region of interest,
	as a polygon.
	LoST may also play a role here, namely to get back a list of URLs		The attacker could then conceivably attempt to impersonate the
	where I can send the SUBSCRIBE requests to. There may be a need for		subject (the putative caller) to some SIP-based target entity.
	urn:service:alerts service URN registry.
	7. IANA Considerations		Countermeasures:
	7.1. Registration of the 'common-alerting-protocol' Event Package		Such an attack is implausible for several reasons. The subject's
			assertion:
			* should be signed, thus causing any alterations to break its
			integrity and make such alterations detectable.
			* the intended recipients may be listed in the optionally present
			audience restriction, which is a cleartext field. As such, it
			would not allow automatic processing but could give the
			receiving user further hints.
			* Issuer is represented in the CAP document (in the <sender>
			element).
			* validity period for the CAP document may be restricted.
			5.2. Forgery
			Threat:
			A malicious user could forge or alter a CAP document in order to
			convey messages to SIP entities that get immediate attention of
			users.
			Countermeasures:
			To avoid this kind of attack, the entities must assure that proper
			mechanisms for protecting the CAP documents are employed, e.g.,
			signing the CAP document itself. Section 3.3.2.1 of [cap]
			specifies the signing of CAP documents.
			5.3. Replay Attack
			Threat:
			Theft of CAP documents described in this document and replay of it
			at a later time.
			Countermeasures:
			A CAP document contains the mandatory <identifier>, <sender>,
			<sent> elements and an optional <expire> element. These
			attributes make the CAP document unique for a specific sender and
			provide time restrictions. An entity that has received a CAP
			message already within the indicated timeframe is able to detect a
			replayed message and, if the content of that message is unchanged,
			then no additional security vulnerability is created. Nodes that
			enter the area of a disaster after the initial distribution of
			warnings have not yet seen the CAP message and, as such, would not
			be able to distinguish a replay from the initial message being
			sent around. However, if the threat that lead to the distribution
			of warning messages is still imminent then there is no reason not
			to worry about that message. The source distributing the early
			warning messages is, however, adviced to carefully select a value
			for the <expires> element and it is RECOMMENDED to set this
			element.
			5.4. Unauthorized Distribution
			Threat:
			When an entity receives a CAP message it has to determine whether
			the entity distributing the CAP messages is genuine to avoid
			accepting messages that are injected by malicious users with the
			potential desire to at least get the users immediate attention.
			Countermeasures:
			When receiving a CAP document a couple of verification steps must
			be performed. First, it needs to be ensured that the message was
			delivered via a trusted entitiy (such as a trusted SIP proxy) and
			that the communication channel between the User Agent and it's SIP
			proxy is properly secured to exclude various attacks at the SIP
			level. Then, the message contains the <sender> that may contain
			an entity that falls within the white list of the entity receiving
			the message. Finally, the message is protected by a digital
			signature and the entity signing the CAP message may again be
			listed in a white list of the receiving entity and may therefore
			be trusted. If none of these verification checks lead to a
			positive indication of a known sender then the CAP document should
			be treated as suspicious and configuration at the receiving entity
			may dictate how to process and display CAP documents in such a
			case.
			6. IANA Considerations
			6.1. Registration of the 'common-alerting-protocol' Event Package
	This specification registers an event package, based on the		This specification registers an event package, based on the
	registration procedures defined in RFC 3265 [RFC3265]. The following		registration procedures defined in RFC 3265 [RFC3265]. The following
	is the information required for such a registration:		is the information required for such a registration:
	Package Name: common-alerting-protocol		Package Name: common-alerting-protocol
	Package or Template-Package: This is a package.		Package or Template-Package: This is a package.
	Published Document: RFC XXX [Replace by the RFC number of this		Published Document: RFC XXX [Replace by the RFC number of this
	specification].		specification].
	Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com		Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com
	7.2. Registration of the 'application/common-alerting-protocol+xml'		6.2. Registration of the 'application/common-alerting-protocol+xml'
	MIME type		MIME type
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type application/ common-		Subject: Registration of MIME media type application/ common-
	alerting-protocol+xml		alerting-protocol+xml
	MIME media type name: application		MIME media type name: application
	MIME subtype name: common-alerting-protocol+xml		MIME subtype name: common-alerting-protocol+xml
	Required parameters: (none)		Required parameters: (none)
	Optional parameters: charset; Indicates the character encoding of		Optional parameters: charset; Indicates the character encoding of
	enclosed XML. Default is UTF-8 [RFC3629].		enclosed XML. Default is UTF-8 [RFC3629].
	skipping to change at page 10, line 4 ¶		skipping to change at page 11, line 22 ¶
	MIME type		MIME type
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type application/ common-		Subject: Registration of MIME media type application/ common-
	alerting-protocol+xml		alerting-protocol+xml
	MIME media type name: application		MIME media type name: application
	MIME subtype name: common-alerting-protocol+xml		MIME subtype name: common-alerting-protocol+xml
	Required parameters: (none)		Required parameters: (none)
	Optional parameters: charset; Indicates the character encoding of		Optional parameters: charset; Indicates the character encoding of
	enclosed XML. Default is UTF-8 [RFC3629].		enclosed XML. Default is UTF-8 [RFC3629].
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See RFC		characters, depending on the character encoding used. See RFC
	3023 [RFC3023], Section 3.2.		3023 [RFC3023], Section 3.2.
	Security considerations: This content type is designed to carry		Security considerations: This content type is designed to carry
	payloads of the Common Alerting Protocol (CAP).		payloads of the Common Alerting Protocol (CAP).
	Interoperability considerations: This content type provides a way to		Interoperability considerations: This content type provides a way to
	convey CAP payloads.		convey CAP payloads.
	Published specification: RFC XXX [Replace by the RFC number of this		Published specification: RFC XXX [Replace by the RFC number of this
	specification].		specification].
	Applications which use this media type: Applications that convey		Applications which use this media type: Applications that convey
	alerts and early warnings according to the CAP standard.		alerts and early warnings according to the CAP standard.
	Additional information: OASIS has published the Common Alerting		Additional information: OASIS has published the Common Alerting
	Protocol at http://www.oasis-open.org/committees/		Protocol at [cap].
	documents.php&wg_abbrev=emergency
	Person & email address to contact for further information: Hannes		Person & email address to contact for further information: Hannes
	Tschofenig, Hannes.Tschofenig@nsn.com		Tschofenig, Hannes.Tschofenig@nsn.com
	Intended usage: Limited use		Intended usage: Limited use
	Author/Change controller: IETF SIPPING working group		Author/Change controller: IETF SIPPING working group
	Other information: This media type is a specialization of		Other information: This media type is a specialization of
	application/xml RFC 3023 [RFC3023], and many of the considerations		application/xml RFC 3023 [RFC3023], and many of the considerations
	described there also apply to application/		described there also apply to application/
	common-alerting-protocol+xml.		common-alerting-protocol+xml.
	8. Acknowledgments		7. Acknowledgments
	The authors would like to thank Cullen Jennings for supporting this		The authors would like to thank Cullen Jennings for supporting this
	work. We would also like to thank the participants of the Early		work. We would also like to thank the participants of the Early
	Warning Adhoc meeting at IETF#69.		Warning Adhoc meeting at IETF#69.
	9. References		8. Normative References
	9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.		[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
	1.1", October 2005.		1.1", October 2005.
	[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific		[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
	Event Notification", RFC 3265, June 2002.		Event Notification", RFC 3265, June 2002.
	[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension		[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
	for Event State Publication", RFC 3903, October 2004.		for Event State Publication", RFC 3903, October 2004.
	[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		[I-D.ietf-geopriv-pdif-lo-profile]
			Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
			PIDF-LO Usage Clarification, Considerations and
			Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
			(work in progress), November 2008.
			[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
			Format for Presence Information Data Format Location
			Object (PIDF-LO)", RFC 5139, February 2008.
	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 11, line 21 ¶		skipping to change at page 13, line 4 ¶
	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:
	Email: br@brianrosen.net		Email: br@brianrosen.net
	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
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	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. 25 change blocks.
	61 lines changed or deleted		151 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/