Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)

By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

Abstract

The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP).

1. Introduction
2. Terminology
3. The 'common-alerting-protocol' Event Package
    3.1. Package Name
    3.2. Event Package Parameters
    3.3. SUBSCRIBE Bodies
    3.4. Subscription Duration
    3.5. NOTIFY Bodies
    3.6. Notifier Processing of SUBSCRIBE Requests
    3.7. Notifier Generation of NOTIFY Requests
    3.8. Subscriber Processing of NOTIFY Requests
    3.9. Handling of Forked Requests
    3.10. Rate of Notifications
    3.11. State Agents
    3.12. Examples
    3.13. Use of URIs to Retrieve State
    3.14. PUBLISH Bodies
    3.15. PUBLISH Response Bodies
    3.16. Multiple Sources for Event State
    3.17. Event State Segmentation
    3.18. Rate of Publication
4. Examples
5. Security Considerations
6. Known Open Issues
7. IANA Considerations
    7.1. Registration of the 'common-alerting-protocol' Event Package
    7.2. Registration of the 'application/common-alerting-protocol+xml' MIME type
8. Acknowledgments
9. References
    9.1. Normative References
    9.2. Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements

1. Introduction

2. Terminology

3. The 'common-alerting-protocol' Event Package

RFC 3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) defines a SIP extension for subscribing to remote nodes and receiving notifications of changes (events) in their states. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document defines such an event package. This section fills in the information required for all event packages by RFC 3265.

We define a new "common-alerting-protocol" event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the common-alerting-protocol event package. Acting as a notifier, the ESC notifies subscribers about emergency alerts and public warnings.

3.1. Package Name

3.2. Event Package Parameters

3.3. SUBSCRIBE Bodies

[Editor's Note: It is an open issue whether subscriptions to the "common-alerting-protocol" event package carry information in their body, such as a polygon defining an area for which notifications should be received. See Section 6 (Known Open Issues).]

3.4. Subscription Duration

3.5. NOTIFY Bodies

For an initial notify, unlike for other event packages, there is no current initial state, unless there's a pending alert. Hence, returning a NOTIFY with a non-empty body only makes sense if there are indeed active alerts.

All subscribers and notifiers of the "common-alerting-protocol" event package MUST support the "application/common-alerting-protocol+xml" data format. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/common-alerting-protocol+xml" (assuming that the Event header field contains a value of "common-alerting-protocol"). If the Accept header field is present, it MUST include "application/common-alerting-protocol+xml".

3.6. Notifier Processing of SUBSCRIBE Requests

The contents of a CAP document contains public information. Hence, providing CAP documents may not require authorization by subscribers.

3.7. Notifier Generation of NOTIFY Requests

RFC 3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the common-alerting-protocol event package.

A notifier MAY send a NOTIFY at any time. Typically, it will send one when an alert or early warning message is available. The NOTIFY request contains a body containing one or multiple CAP document(s). The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription.

In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a complete CAP document. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), the Subscription-State header field indicates the state of the subscription.

The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/common-alerting-protocol+xml" if no Accept header field was present.

Notifiers will typically act as Event State Compositors (ESC) and thus will learn the 'common-alerting-protocol' event state via PUBLISH requests sent from authorized Event Publication Agents (EPAs).

3.8. Subscriber Processing of NOTIFY Requests

3.9. Handling of Forked Requests

This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request.

3.10. Rate of Notifications

Notifiers SHOULD NOT generate notifications for a single user at a rate of more than once every five seconds.

3.11. State Agents

3.12. Examples

3.13. Use of URIs to Retrieve State

CAP documents are fairly small. This event package does not provide a mechanism to use URIs to retrieve large state documents.

3.14. PUBLISH Bodies

In this event package, the body of a PUBLISH request may contain a CAP document. A CAP document describes an emergency alert or an early warning event.

All EPAs and ESCs MUST support the "application/common-alerting-protocol+xml" data format and MAY support other formats.

Note that this document does not mandate how CAP documents are made available to the Public Warning System, for example by authorities or similar organizations. The PUBLISH mechanism is one way.

3.15. PUBLISH Response Bodies

This specification assumes that a PUBLISH also conveys a CAP document that is later sent further on to watchers.

3.16. Multiple Sources for Event State

This event package allows different EPAs to publish CAP documents for a particular user. The concept of composition is not applicable for this application usage.

3.17. Event State Segmentation

3.18. Rate of Publication

There are no rate-limiting recommendations for common-alerting-protocol publication. Since emergency alerts and early warning events are typically rare there is no periodicity, nor a minimum or maximum rate of publication.

4. Examples


<?xml version="1.0" encoding="UTF-8"?>

<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>KSTO1055887203</identifier>
    <sender>KSTO@NWS.NOAA.GOV</sender>
    <sent>2003-06-17T14:57:00-07:00</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Public</scope>
    <info>
        <category>Met</category>
        <event>SEVERE THUNDERSTORM</event>
        <urgency>Severe</urgency>
        <certainty>Likely</certainty>
        <eventCode>same=SVR</eventCode>
        <senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
        <headline>SEVERE THUNDERSTORM WARNING</headline>
        <description> AT 254 PM PDT...
            NATIONAL WEATHER SERVICE
            DOPPLER RADAR INDICATED A SEVERE
            THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
            OR ABOUT 18 MILES SOUTHEAST OF
            KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
            INTENSE RAIN AND STRONG DAMAGING WINDS
            ARE LIKELY WITH THIS STORM </description>
        <instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
            UNTIL THE STORM PASSES </instruction>
        <contact>BARUFFALDI/JUSKIE</contact>
        <area>
            <areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
                IN CALIFORNIA, EXTREME NORTHEASTERN
                CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
                ALPINE COUNTY IN CALIFORNIA </areaDesc>
            <polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
                38.62,-119.89 38.47,-120.14 </polygon>
            <geocode>fips6=006109</geocode>
            <geocode>fips6=006109</geocode>
            <geocode>fips6=006103</geocode>
        </area>
    </info>
</alert>

5. Security Considerations

[Editor's Note: A future version of this document will describe security considerations.]

6. Known Open Issues

Frequently, alerting events are only of regional interest since they 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 where I can send the SUBSCRIBE requests to. There may be a need for urn:service:alerts service URN registry.

7. IANA Considerations

7.1. Registration of the 'common-alerting-protocol' Event Package

7.2. Registration of the 'application/common-alerting-protocol+xml' MIME type

8. Acknowledgments

The authors would like to thank Cullen Jennings for supporting this work. We would also like to thank the participants of the Early Warning Adhoc meeting at IETF#69.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses

Full Copyright Statement

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.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.
[cap]	Jones, E. and A. Botterell, “Common Alerting Protocol v. 1.1,” October 2005.
[RFC3265]	Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002 (TXT).
[RFC3903]	Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” RFC 3903, October 2004 (TXT).
[RFC3023]	Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” RFC 3023, January 2001 (TXT).
[RFC3629]	Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).

	Brian Rosen
	NeuStar, Inc.
	470 Conrad Dr
	Mars, PA 16046
	US
Phone:
Email:	br@brianrosen.net

	Henning Schulzrinne
	Columbia University
	Department of Computer Science
	450 Computer Science Building
	New York, NY 10027
	US
Phone:	+1 212 939 7004
Email:	hgs+ecrit@cs.columbia.edu
URI:	http://www.cs.columbia.edu

	Hannes Tschofenig
	Nokia Siemens Networks
	Linnoitustie 6
	Espoo 02600
	Finland
Phone:	+358 (50) 4871445
Email:	Hannes.Tschofenig@gmx.net
URI:	http://www.tschofenig.priv.at

Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)
draft-rosen-sipping-cap-02.txt

Status of this Memo

Abstract

Table of Contents

1. Introduction

2. Terminology

3. The 'common-alerting-protocol' Event Package

3.1. Package Name

3.2. Event Package Parameters

3.3. SUBSCRIBE Bodies

3.4. Subscription Duration

3.5. NOTIFY Bodies

3.6. Notifier Processing of SUBSCRIBE Requests

3.7. Notifier Generation of NOTIFY Requests

3.8. Subscriber Processing of NOTIFY Requests

3.9. Handling of Forked Requests

3.10. Rate of Notifications

3.11. State Agents

3.12. Examples

3.13. Use of URIs to Retrieve State

3.14. PUBLISH Bodies

3.15. PUBLISH Response Bodies

3.16. Multiple Sources for Event State

3.17. Event State Segmentation

3.18. Rate of Publication

4. Examples

5. Security Considerations

6. Known Open Issues

7. IANA Considerations

7.1. Registration of the 'common-alerting-protocol' Event Package

7.2. Registration of the 'application/common-alerting-protocol+xml' MIME type

8. Acknowledgments

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses

Full Copyright Statement

Intellectual Property

Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)draft-rosen-sipping-cap-02.txt

Status of this Memo

Abstract

Table of Contents

1. Introduction

2. Terminology

3. The 'common-alerting-protocol' Event Package

3.1. Package Name

3.2. Event Package Parameters

3.3. SUBSCRIBE Bodies

3.4. Subscription Duration

3.5. NOTIFY Bodies

3.6. Notifier Processing of SUBSCRIBE Requests

3.7. Notifier Generation of NOTIFY Requests

3.8. Subscriber Processing of NOTIFY Requests

3.9. Handling of Forked Requests

3.10. Rate of Notifications

3.11. State Agents

3.12. Examples

3.13. Use of URIs to Retrieve State

3.14. PUBLISH Bodies

3.15. PUBLISH Response Bodies

3.16. Multiple Sources for Event State

3.17. Event State Segmentation

3.18. Rate of Publication

4. Examples

5. Security Considerations

6. Known Open Issues

7. IANA Considerations

7.1. Registration of the 'common-alerting-protocol' Event Package

7.2. Registration of the 'application/common-alerting-protocol+xml' MIME type

8. Acknowledgments

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses

Full Copyright Statement

Intellectual Property

Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)
draft-rosen-sipping-cap-02.txt