idnits 2.17.00 (12 Aug 2021) /tmp/idnits54425/draft-rosen-ecrit-lost-early-warning-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 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 422. 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 26, 2008) is 4954 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) == Outdated reference: A later version (-04) exists of draft-rosen-sipping-cap-02 == Outdated reference: A later version (-02) exists of draft-forte-ecrit-lost-extensions-00 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 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: April 29, 2009 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 26, 2008 10 A Uniform Resource Name (URN) for Early Warning Emergency Services and 11 Location-to-Service Translation (LoST) Protocol Usage 12 draft-rosen-ecrit-lost-early-warning-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 April 29, 2009. 39 Abstract 41 The Common Alerting Protocol (CAP) is an XML document format for 42 exchanging emergency alerts and public warnings. Different 43 organizations issue alerts for specific geographic regions. The 44 Location-to-Service Translation (LoST) protocol provides a way to 45 discover servers that distribute these alerts for a geographical 46 region. This document defines the Service Uniform Resource Names 47 (URN)s for warnings in the same way as they have been defined with 48 RFC 5031 for citizen-to-authority emergency services. Additionally, 49 this document suggests to use LoST for the discovery of servers 50 distributing alerts. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Semantics . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6.1. Sub-Services for the 'warning' Service . . . . . . . . . . 7 61 6.2. Initial IANA Registration . . . . . . . . . . . . . . . . 8 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 The Common Alerting Protocol (CAP) is an XML document format for 72 exchanging emergency alerts and public warnings. Different 73 organizations issue alerts for specific geographical regions. The 74 Location-to-Service Translation (LoST) protocol provides a way to 75 discover servers that distribute these alerts for a geographical 76 region. This document defines the Service Uniform Resource Names 77 (URN)s for warnings in the same way as they have been defined with 78 RFC 5031 for citizen-to-authority emergency services. Additionally, 79 this document suggests to use LoST for the discovery of servers 80 distributing alerts. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 3. Protocol Semantics 90 This document makes use of LoST, RFC 5222 [RFC5222]. However, 91 instead of performing a translation from location information and a 92 Service URN to a PSAP URI (plus supplementary information), as used 93 with [I-D.ietf-ecrit-phonebcp] for the citizen-to-authority emergency 94 services use case, the LoST client asks the LoST server for a URI to 95 receive further information on how to obtain warning alerts. In a 96 response the URIs in the element MUST be from the following 97 format: sip, xmpp or http. The SIP URI MUST subsequently be used 98 with [I-D.rosen-sipping-cap]. An XMPP URI MUST be used as described 99 in [XEP-0127]. An HTTP URI MUST be used with GeoRSS ([Reference to 100 be added.]). 102 In a LoST response the optional element is not used 103 by this specification. In mapping citizen-to-authority services, 104 receiving multiple mappings is an exception. However, since many 105 organizations may provide warnings for the same area, this is likely 106 to be more common for alerts. As such, the extensions defined in 107 [I-D.forte-ecrit-lost-extensions] (e.g., the ability to limit the 108 number of returned mappings) are useful in this context. 110 4. Examples 112 Figure 1 shows a regular LoST query including geodetic location 113 information with the Service URN pointing to 'urn:service:warning'. 115 The semantic of the query is: "I am at location (point,"37.775 116 -122.422"). Please give me a URI where I can obtain information for 117 warnings under the category 'urn:service:warning'. 119 120 126 127 128 37.775 -122.422 129 130 131 urn:service:warning 133 135 Figure 1: A geodetic query 137 In response to the query in Figure 1 the LoST server returns a 138 regular LoST response, as shown in Figure 2. The returned mapping 139 information indicates that the URIs (sip:alerts@example.com and 140 xmpp:alerts@example.com) can be contacted to subscribe to warning 141 events. The service boundary indicates that subsequent requests to 142 the same service will lead to the same response for the geodetic 143 region indicated by the polygon in the element. 145 146 148 153 154 Austrian Early Warning Center 155 156 urn:service:warning 157 158 159 160 161 37.775 -122.4194 162 37.555 -122.4194 163 37.555 -122.4264 164 37.775 -122.4264 165 37.775 -122.4194 166 167 168 169 170 sip:alerts@example.com 171 xmpp:alerts@example.com 172 173 174 175 176 177 178 180 Figure 2: A geodetic answer 182 Figure 3 shows a query asking for the 183 services that are available at a given location; in this example at a 184 point (-34.407 150.883). 186 187 191 192 193 -34.407 150.883 194 195 196 urn:service:warning 197 199 Figure 3: Example of query 201 Figure 4 lists a possible response to the 202 query with 6 subservices being offered for the indicated geographical 203 region. 205 206 208 209 urn:service:warning.geo 210 urn:service:warning.met 211 urn:service:warning.safety 212 urn:service:warning.security 213 urn:service:warning.rescue 214 urn:service:warning.fire 215 216 217 218 219 220 221 223 Figure 4: Example of 225 5. Security Considerations 227 The security considerations of RFC 5031 [RFC5031], RFC 5222 [RFC5222] 228 and [I-D.rosen-sipping-cap] are relevant to this document. This 229 document does not introduce new security vulnerabilities. 231 6. IANA Considerations 233 6.1. Sub-Services for the 'warning' Service 235 This section defines the service registration within the IANA 236 registry defined in Section 4.1 of [RFC5031], using the top-level 237 service label 'warning'. 239 The 'warning' service type describes services providing public safety 240 alerts, i.e., alerts that can warn members of the public about 241 dangers to life, health and property. Additional sub-services can be 242 added after expert review and must be of general public interest and 243 have a similar emergency nature. The expert is designated by the 244 ECRIT working group, its successor, or, in their absence, the IESG. 245 The expert review should only approve early warning based emergency 246 services that are offered widely and in different countries, with 247 approximately the same caller expectation in terms of services 248 rendered. The 'warning' service is not meant to be used by non- 249 emergency services related information. 251 The warning classification (including description) in the list below 252 is taken from the CAP specification [cap]: 254 'urn:service:warning': The generic 'warning' service denotes a 255 generic early warning message of any type encompassing all of the 256 services listed below. 258 'urn:service:warning:geo': Geophysical (inc. landslide) 260 'urn:service:warning:met': Meteorological (inc. flood) 262 'urn:service:warning:safety': General emergency and public safety 264 'urn:service:warning:security': Law enforcement, military, homeland 265 and local/private security 267 'urn:service:warning:rescue': Rescue and recovery 269 'urn:service:warning:fire': Fire suppression and rescue 271 'urn:service:warning:health': Medical and public health 273 'urn:service:warning:env': Pollution and other environmental 274 'urn:service:warning:transport': Public and private transportation 276 'urn:service:warning:infra': Utility, telecommunication, other non- 277 transport infrastructure 279 'urn:service:warning:cbrne': Chemical, Biological, Radiological, 280 Nuclear or High-Yield Explosive threat or attack 282 6.2. Initial IANA Registration 284 The following table contains the initial IANA registration for early 285 warning services. 287 Service Reference Description 288 ------------------------------------------------------------------------ 289 warning RFC TBD Early Warning Services 290 warning.geo RFC TBD Geophysical (inc. landslide) 291 warning.met RFC TBD Meteorological (inc. flood) 292 warning.safety RFC TBD General emergency and public safety 293 warning.security RFC TBD Law enforcement, military, 294 homeland and local/private security 295 warning.rescue RFC TBD Rescue and recovery 296 warning.fire RFC TBD Fire suppression and rescue 297 warning.health RFC TBD Medical and public health 298 warning.env RFC TBD Pollution and other environmental 299 warning.transport RFC TBD Public and private transportation 300 warning.infra RFC TBD Utility, telecommunication, other 301 non-transport infrastructure 302 warning.cbrne RFC TBD Chemical, Biological, 303 Radiological, Nuclear or High-Yield 304 Explosive threat or attack 306 7. Acknowledgments 308 We would also like to thank the participants of the Early Warning 309 Adhoc meeting at IETF#69. 311 8. References 313 8.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", March 1997. 318 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 319 1.1", October 2005. 321 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 322 Tschofenig, "LoST: A Location-to-Service Translation 323 Protocol", RFC 5222, August 2008. 325 [I-D.rosen-sipping-cap] 326 Rosen, B., Schulzrinne, H., and H. Tschofenig, "Session 327 Initiation Protocol (SIP) Event Package for the Common 328 Alerting Protocol (CAP)", draft-rosen-sipping-cap-02 329 (work in progress), July 2008. 331 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 332 Emergency and Other Well-Known Services", RFC 5031, 333 January 2008. 335 8.2. Informative References 337 [XEP-0127] 338 Saint-Andre, P. and B. Fletcher, "Common Alerting Protocol 339 (CAP) Over XMPP", XSF XEP 0127, December 2004. 341 [I-D.forte-ecrit-lost-extensions] 342 Forte, A. and H. Schulzrinne, "Location-to-Service 343 Translation Protocol (LoST) Extensions", 344 draft-forte-ecrit-lost-extensions-00 (work in progress), 345 March 2008. 347 [I-D.ietf-ecrit-phonebcp] 348 Rosen, B. and J. Polk, "Best Current Practice for 349 Communications Services in support of Emergency Calling", 350 draft-ietf-ecrit-phonebcp-05 (work in progress), 351 July 2008. 353 Authors' Addresses 355 Brian Rosen 356 NeuStar, Inc. 357 470 Conrad Dr 358 Mars, PA 16046 359 US 361 Phone: 362 Email: br@brianrosen.net 363 Henning Schulzrinne 364 Columbia University 365 Department of Computer Science 366 450 Computer Science Building 367 New York, NY 10027 368 US 370 Phone: +1 212 939 7004 371 Email: hgs+ecrit@cs.columbia.edu 372 URI: http://www.cs.columbia.edu 374 Hannes Tschofenig 375 Nokia Siemens Networks 376 Linnoitustie 6 377 Espoo 02600 378 Finland 380 Phone: +358 (50) 4871445 381 Email: Hannes.Tschofenig@gmx.net 382 URI: http://www.tschofenig.priv.at 384 Full Copyright Statement 386 Copyright (C) The IETF Trust (2008). 388 This document is subject to the rights, licenses and restrictions 389 contained in BCP 78, and except as set forth therein, the authors 390 retain all their rights. 392 This document and the information contained herein are provided on an 393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 395 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 396 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 397 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 400 Intellectual Property 402 The IETF takes no position regarding the validity or scope of any 403 Intellectual Property Rights or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; nor does it represent that it has 407 made any independent effort to identify any such rights. Information 408 on the procedures with respect to rights in RFC documents can be 409 found in BCP 78 and BCP 79. 411 Copies of IPR disclosures made to the IETF Secretariat and any 412 assurances of licenses to be made available, or the result of an 413 attempt made to obtain a general license or permission for the use of 414 such proprietary rights by implementers or users of this 415 specification can be obtained from the IETF on-line IPR repository at 416 http://www.ietf.org/ipr. 418 The IETF invites any interested party to bring to its attention any 419 copyrights, patents or patent applications, or other proprietary 420 rights that may cover technology that may be required to implement 421 this standard. Please address the information to the IETF at 422 ietf-ipr@ietf.org.