idnits 2.17.1 draft-rosen-sipping-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Standards Track H. Schulzrinne 5 Expires: January 3, 2008 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 July 2, 2007 10 Session Initiation Protocol (SIP) Event Package for the Common Alerting 11 Protocol (CAP) 12 draft-rosen-sipping-cap-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 3, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Common Alerting Protocol (CAP) is an XML document format for 46 exchanging emergency alerts and public warnings. This document 47 allows CAP documents to be distributed via the event notification 48 mechanism available with the Session Initiation Protocol (SIP). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The 'common-alerting-protocol' Event Package . . . . . . . . . 3 55 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 57 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 4 58 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 4 59 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 4 60 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 5 61 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 5 62 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 5 63 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 6 64 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6 65 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 6 68 3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 6 69 3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7 70 3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7 71 3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7 72 3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 7 73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6. Known Open Issues . . . . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 7.1. Registration of the 'common-alerting-protocol' Event 78 Package . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.2. Registration of the 80 'application/common-alerting-protocol+xml' MIME type . . . 9 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 Intellectual Property and Copyright Statements . . . . . . . . . . 12 88 1. Introduction 90 The Common Alerting Protocol (CAP) [cap] is an XML document format 91 for exchanging emergency alerts and public warnings. This document 92 allows CAP documents to be distributed via the event notification 93 mechanism available with the Session Initiation Protocol (SIP). 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. The 'common-alerting-protocol' Event Package 103 RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote 104 nodes and receiving notifications of changes (events) in their 105 states. It leaves the definition of many aspects of these events to 106 concrete extensions, known as event packages. This document defines 107 such an event package. This section fills in the information 108 required for all event packages by RFC 3265. 110 Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP 111 User Agents to publish event state. According to RFC 3903, any event 112 package intended to be used in conjunction with the SIP PUBLISH 113 method has to include a considerations section. This section also 114 fills the information for all event packages to be used with PUBLISH 115 requests. 117 We define a new "common-alerting-protocol" event package. Event 118 Publication Agents (EPA) use PUBLISH requests to inform an Event 119 State Compositor (ESC) of changes in the common-alerting-protocol 120 event package. Acting as a notifier, the ESC notifies subscribers 121 about emergency alerts and public warnings. 123 3.1. Package Name 125 The name of this package is "common-alerting-protocol". As specified 126 in RFC 3265 [RFC3265], this value appears in the Event header field 127 present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903 128 [RFC3903], this value also appears in the Event header field present 129 in PUBLISH requests. 131 3.2. Event Package Parameters 133 RFC 3265 [RFC3265] allows event packages to define additional 134 parameters carried in the Event header field. This event package, 135 "common-alerting-protocol", does not define additional parameters. 137 3.3. SUBSCRIBE Bodies 139 According to RFC 3265 [RFC3265], a SUBSCRIBE request can contain a 140 body. The purpose of the body depends on its type. 142 [Editor's Note: It is an open issue whether subscriptions to the 143 "common-alerting-protocol" event package carry information in their 144 body, such as a polygon defining an area for which notifications 145 should be received. See Section 6.] 147 3.4. Subscription Duration 149 The default expiration time for subscriptions within this package is 150 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify 151 an alternate expiration in the Expires header field. 153 3.5. NOTIFY Bodies 155 As described in RFC 3265 [RFC3265], the NOTIFY message will contain 156 bodies describing the state of the subscribed resource. This body is 157 in a format listed in the Accept header field of the SUBSCRIBE 158 request, or a package-specific default format if the Accept header 159 field was omitted from the SUBSCRIBE request. 161 In this event package, the body of the notification contains a Common 162 Alerting Protocol (CAP) document, i.e., an XML document. The format 163 of the XML documents used by CAP are described in [cap]. 165 For an initial notify, unlike for other event packages, there is no 166 current initial state, unless there's a pending alert. Hence, 167 returning a NOTIFY with a non-empty body only makes sense if there 168 are indeed active alerts. 170 All subscribers and notifiers of the "common-alerting-protocol" event 171 package MUST support the "application/common-alerting-protocol+xml" 172 data format. The SUBSCRIBE request MAY contain an Accept header 173 field. If no such header field is present, it has a default value of 174 "application/common-alerting-protocol+xml" (assuming that the Event 175 header field contains a value of "common-alerting-protocol"). If the 176 Accept header field is present, it MUST include "application/ 177 common-alerting-protocol+xml". 179 3.6. Notifier Processing of SUBSCRIBE Requests 181 The contents of a CAP document contains public information. Hence, 182 providing CAP documents may not require authorization by subscribers. 184 3.7. Notifier Generation of NOTIFY Requests 186 RFC 3265 [RFC3265] details the formatting and structure of NOTIFY 187 messages. However, packages are mandated to provide detailed 188 information on when to send a NOTIFY, how to compute the state of the 189 resource, how to generate neutral or fake state information, and 190 whether state information is complete or partial. This section 191 describes those details for the common-alerting-protocol event 192 package. 194 A notifier MAY send a NOTIFY at any time. Typically, it will send 195 one when an alert or early warning message is available. The NOTIFY 196 request contains a body containing one or multiple CAP document(s). 197 The times at which the NOTIFY is sent for a particular subscriber, 198 and the contents of the body within that notification, are subject to 199 any rules specified by the authorization policy that governs the 200 subscription. 202 In the case of a pending subscription, when final authorization is 203 determined, a NOTIFY can be sent. If the result of the authorization 204 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 205 complete CAP document. If the subscription is rejected, a NOTIFY MAY 206 be sent. As described in RFC 3265 [RFC3265], the Subscription-State 207 header field indicates the state of the subscription. 209 The body of the NOTIFY MUST be sent using one of the types listed in 210 the Accept header field in the most recent SUBSCRIBE request, or 211 using the type "application/common-alerting-protocol+xml" if no 212 Accept header field was present. 214 Notifiers will typically act as Event State Compositors (ESC) and 215 thus will learn the 'common-alerting-protocol' event state via 216 PUBLISH requests sent from authorized Event Publication Agents 217 (EPAs). 219 3.8. Subscriber Processing of NOTIFY Requests 221 RFC 3265 [RFC3265] leaves it to event packages to describe the 222 process followed by the subscriber upon receipt of a NOTIFY request, 223 including any logic required to form a coherent resource state. 225 3.9. Handling of Forked Requests 227 RFC 3265 [RFC3265] requires each package to describe handling of 228 forked SUBSCRIBE requests. 230 This specification only allows a single dialog to be constructed as a 231 result of emitting an initial SUBSCRIBE request. 233 3.10. Rate of Notifications 235 RFC 3265 [RFC3265] requires each package to specify the maximum rate 236 at which notifications can be sent. 238 Notifiers SHOULD NOT generate notifications for a single user at a 239 rate of more than once every five seconds. 241 3.11. State Agents 243 RFC 3265 [RFC3265] requires each package to consider the role of 244 state agents in the package and, if they are used, to specify how 245 authentication and authorization are done. This specification allows 246 state agents to be located in the network. 248 3.12. Examples 250 An example is provided in Section 4. 252 3.13. Use of URIs to Retrieve State 254 RFC 3265 [RFC3265] allows packages to use URIs to retrieve large 255 state documents. 257 CAP documents are fairly small. This event package does not provide 258 a mechanism to use URIs to retrieve large state documents. 260 3.14. PUBLISH Bodies 262 RFC 3903 [RFC3903] requires event packages to define the content 263 types expected in PUBLISH requests. 265 In this event package, the body of a PUBLISH request may contain a 266 CAP document. A CAP document describes an emergency alert or an 267 early warning event. 269 All EPAs and ESCs MUST support the "application/ 270 common-alerting-protocol+xml" data format and MAY support other 271 formats. 273 Note that this document does not mandate how CAP documents are made 274 available to the Public Warning System, for example by authorities or 275 similar organizations. The PUBLISH mechanism is one way. 277 3.15. PUBLISH Response Bodies 279 This specification assumes that a PUBLISH also conveys a CAP document 280 that is later sent further on to watchers. 282 3.16. Multiple Sources for Event State 284 RFC 3903 [RFC3903] requires event packages to specify whether 285 multiple sources can contribute to the event state view at the ESC. 287 This event package allows different EPAs to publish CAP documents for 288 a particular user. The concept of composition is not applicable for 289 this application usage. 291 3.17. Event State Segmentation 293 RFC 3903 [RFC3903] defines segments within a state document. Each 294 segment is defined as one of potentially many identifiable sections 295 in the published event state. 297 This event package defines does not differentiate between different 298 segments. 300 3.18. Rate of Publication 302 RFC 3903 [RFC3903] allows event packages to define their own rate of 303 publication. 305 There are no rate-limiting recommendations for common-alerting- 306 protocol publication. Since emergency alerts and early warning 307 events are typically rare there is no periodicity, nor a minimum or 308 maximum rate of publication. 310 4. Examples 312 Here is an example of a CAP document. 314 316 317 KSTO1055887203 318 KSTO@NWS.NOAA.GOV 319 2003-06-17T14:57:00-07:00 320 Actual 321 Alert 322 Public 323 324 Met 325 SEVERE THUNDERSTORM 326 Severe 327 Likely 328 same=SVR 329 NATIONAL WEATHER SERVICE SACRAMENTO 330 SEVERE THUNDERSTORM WARNING 331 AT 254 PM PDT... 332 NATIONAL WEATHER SERVICE 333 DOPPLER RADAR INDICATED A SEVERE 334 THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... 335 OR ABOUT 18 MILES SOUTHEAST OF 336 KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... 337 INTENSE RAIN AND STRONG DAMAGING WINDS 338 ARE LIKELY WITH THIS STORM 339 TAKE COVER IN A SUBSTANTIAL SHELTER 340 UNTIL THE STORM PASSES 341 BARUFFALDI/JUSKIE 342 343 EXTREME NORTH CENTRAL TUOLUMNE COUNTY 344 IN CALIFORNIA, EXTREME NORTHEASTERN 345 CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN 346 ALPINE COUNTY IN CALIFORNIA 347 38.47,-120.14 38.34,-119.95 38.52,-119.74 348 38.62,-119.89 38.47,-120.14 349 fips6=006109 350 fips6=006109 351 fips6=006103 352 353 354 356 Example for a Severe Thunderstorm Warning 358 5. Security Considerations 360 [Editor's Note: A future version of this document will describe 361 security considerations.] 363 6. Known Open Issues 365 Frequently, alerting events are only of regional interest since they 366 only have regional impact. For example: The public in NYC does not 367 really need to be alerted about a wild fire at Lake Tahoe. One 368 possible solution is the ability to allow SUBSCRIBE bodies to have a 369 region description that describes the geographic region of interest, 370 as a polygon. 372 LoST may also play a role here, namely to get back a list of URLs 373 where I can send the SUBSCRIBE requests to. There may be a need for 374 urn:service:alerts service URN registry. 376 7. IANA Considerations 378 7.1. Registration of the 'common-alerting-protocol' Event Package 380 This specification registers an event package, based on the 381 registration procedures defined in RFC 3265 [RFC3265]. The following 382 is the information required for such a registration: 383 Package Name: common-alerting-protocol 384 Package or Template-Package: This is a package. 385 Published Document: RFC XXX [Replace by the RFC number of this 386 specification]. 387 Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com 389 7.2. Registration of the 'application/common-alerting-protocol+xml' 390 MIME type 392 To: ietf-types@iana.org 393 Subject: Registration of MIME media type application/ common- 394 alerting-protocol+xml 395 MIME media type name: application 396 MIME subtype name: common-alerting-protocol+xml 397 Required parameters: (none) 398 Optional parameters: charset; Indicates the character encoding of 399 enclosed XML. Default is UTF-8 [RFC3629]. 401 Encoding considerations: Uses XML, which can employ 8-bit 402 characters, depending on the character encoding used. See RFC 403 3023 [RFC3023], Section 3.2. 404 Security considerations: This content type is designed to carry 405 payloads of the Common Alerting Protocol (CAP). 406 Interoperability considerations: This content type provides a way to 407 convey CAP payloads. 408 Published specification: RFC XXX [Replace by the RFC number of this 409 specification]. 410 Applications which use this media type: Applications that convey 411 alerts and early warnings according to the CAP standard. 412 Additional information: OASIS has published the Common Alerting 413 Protocol at http://www.oasis-open.org/committees/ 414 documents.php&wg_abbrev=emergency 415 Person & email address to contact for further information: Hannes 416 Tschofenig, Hannes.Tschofenig@nsn.com 417 Intended usage: Limited use 418 Author/Change controller: IETF SIPPING working group 419 Other information: This media type is a specialization of 420 application/xml RFC 3023 [RFC3023], and many of the considerations 421 described there also apply to application/ 422 common-alerting-protocol+xml. 424 8. Acknowledgments 426 The authors would like to thank Cullen Jennings for supporting this 427 work. 429 9. References 431 9.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", March 1997. 436 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 437 1.1", October 2005. 439 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 440 Event Notification", RFC 3265, June 2002. 442 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 443 for Event State Publication", RFC 3903, October 2004. 445 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 446 Types", RFC 3023, January 2001. 448 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 449 10646", STD 63, RFC 3629, November 2003. 451 9.2. Informative References 453 Authors' Addresses 455 Brian Rosen 456 NeuStar, Inc. 457 470 Conrad Dr 458 Mars, PA 16046 459 US 461 Phone: 462 Email: br@brianrosen.net 464 Henning Schulzrinne 465 Columbia University 466 Department of Computer Science 467 450 Computer Science Building 468 New York, NY 10027 469 US 471 Phone: +1 212 939 7004 472 Email: hgs+ecrit@cs.columbia.edu 473 URI: http://www.cs.columbia.edu 475 Hannes Tschofenig 476 Nokia Siemens Networks 477 Otto-Hahn-Ring 6 478 Munich, Bavaria 81739 479 Germany 481 Email: Hannes.Tschofenig@nsn.com 482 URI: http://www.tschofenig.com 484 Full Copyright Statement 486 Copyright (C) The IETF Trust (2007). 488 This document is subject to the rights, licenses and restrictions 489 contained in BCP 78, and except as set forth therein, the authors 490 retain all their rights. 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 495 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 496 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org. 524 Acknowledgment 526 Funding for the RFC Editor function is provided by the IETF 527 Administrative Support Activity (IASA).