idnits 2.17.1 draft-rosen-sipping-cap-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 12, 2009) is 5395 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 (==), 2 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 13, 2010 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 July 12, 2009 10 Session Initiation Protocol (SIP) Event Package for the Common Alerting 11 Protocol (CAP) 12 draft-rosen-sipping-cap-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The Common Alerting Protocol (CAP) is an XML document format for 51 exchanging emergency alerts and public warnings. This document 52 allows CAP documents to be distributed via the event notification 53 mechanism available with the Session Initiation Protocol (SIP). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The 'common-alerting-protocol' Event Package . . . . . . . . . 3 60 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 62 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 4 64 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5 65 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 5 66 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 5 67 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 6 68 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 6 69 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6 70 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 7 73 3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 7 74 3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7 75 3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7 76 3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7 77 3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 8 78 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 5.1. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 10 81 5.2. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 10 83 5.4. Unauthorized Distribution . . . . . . . . . . . . . . . . 11 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Registration of the 'common-alerting-protocol' Event 86 Package . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.2. Registration of the 88 'application/common-alerting-protocol+xml' MIME type . . . 12 89 6.3. Early Warning Service URNs . . . . . . . . . . . . . . . . 12 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The Common Alerting Protocol (CAP) [cap] is an XML document format 97 for exchanging emergency alerts and public warnings. This document 98 allows CAP documents to be distributed via the event notification 99 mechanism available with the Session Initiation Protocol (SIP). 101 Additionally, a MIME object is registered to allow CAP documents to 102 be exchanged in other SIP documents. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 3. The 'common-alerting-protocol' Event Package 112 RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote 113 nodes and receiving notifications of changes (events) in their 114 states. It leaves the definition of many aspects of these events to 115 concrete extensions, known as event packages. This document defines 116 such an event package. This section fills in the information 117 required for all event packages by RFC 3265. 119 Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP 120 User Agents to publish event state. According to RFC 3903, any event 121 package intended to be used in conjunction with the SIP PUBLISH 122 method has to include a considerations section. This section also 123 fills the information for all event packages to be used with PUBLISH 124 requests. 126 This document defines a new "common-alerting-protocol" event package. 127 Event Publication Agents (EPA) use PUBLISH requests to inform an 128 Event State Compositor (ESC) of changes in the common-alerting- 129 protocol event package. Acting as a notifier, the ESC notifies 130 subscribers about emergency alerts and public warnings. 132 3.1. Package Name 134 The name of this package is "common-alerting-protocol". As specified 135 in RFC 3265 [RFC3265], this value appears in the Event header field 136 present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903 137 [RFC3903], this value also appears in the Event header field present 138 in PUBLISH requests. 140 3.2. Event Package Parameters 142 RFC 3265 [RFC3265] allows event packages to define additional 143 parameters carried in the Event header field. This event package, 144 "common-alerting-protocol", does not define additional parameters. 146 3.3. SUBSCRIBE Bodies 148 RFC 3265 [RFC3265] allows a SUBSCRIBE request to contain a body. 149 This document allows the body to contain the XML element with the following child elements: 152 Civic and geodetic location information: The 2D location shapes 153 listed in [I-D.ietf-geopriv-pdif-lo-profile] (e.g., 154 , , , ) and the 155 element, defined in [RFC5139]. Repeating these elements is 156 allowed and the semantic is equivalent to a union. 158 Type of Warning Message: One or more elements that contain 159 Service URNs [RFC5031] may be added as a child element of the 160 element. They Service URNs indicate the 161 type of alerts the recipient is interested in. The registered 162 alerts can be found in Section 6. 164 An example of such a body can be found below. 166 167 168 170 DE 171 172 urn:service:warning:security 173 175 Example of a SIP SUBSCRIBE Body 177 3.4. Subscription Duration 179 The default expiration time for subscriptions within this package is 180 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify 181 an alternate expiration in the Expires header field. 183 3.5. NOTIFY Bodies 185 As described in RFC 3265 [RFC3265], the NOTIFY message will contain 186 bodies describing the state of the subscribed resource. This body is 187 in a format listed in the Accept header field of the SUBSCRIBE 188 request, or a package-specific default format if the Accept header 189 field was omitted from the SUBSCRIBE request. 191 In this event package, the body of the notification contains a Common 192 Alerting Protocol (CAP) document, i.e., an XML document. The format 193 of the XML documents used by CAP are described in [cap]. 195 For an initial notify, unlike for other event packages, there is no 196 current initial state, unless there's a pending alert. Hence, 197 returning a NOTIFY with a non-empty body only makes sense if there 198 are indeed active alerts. 200 All subscribers and notifiers of the "common-alerting-protocol" event 201 package MUST support the "application/common-alerting-protocol+xml" 202 data format. The SUBSCRIBE request MAY contain an Accept header 203 field. If no such header field is present, it has a default value of 204 "application/common-alerting-protocol+xml" (assuming that the Event 205 header field contains a value of "common-alerting-protocol"). If the 206 Accept header field is present, it MUST include "application/ 207 common-alerting-protocol+xml". 209 3.6. Notifier Processing of SUBSCRIBE Requests 211 The contents of a CAP document may contain public information, 212 depending on the alert message type and the intended recipient of the 213 alert message. It is, however, expected that in many cases providing 214 CAP documents does not require authorization by subscribers. 216 3.7. Notifier Generation of NOTIFY Requests 218 RFC 3265 [RFC3265] details the formatting and structure of NOTIFY 219 messages. However, packages are mandated to provide detailed 220 information on when to send a NOTIFY, how to compute the state of the 221 resource, how to generate neutral or fake state information, and 222 whether state information is complete or partial. This section 223 describes those details for the common-alerting-protocol event 224 package. 226 A notifier MAY send a NOTIFY at any time. Typically, it will send 227 one when an alert or early warning message is available. The NOTIFY 228 request contains a body containing one or multiple CAP document(s). 229 The times at which the NOTIFY is sent for a particular subscriber, 230 and the contents of the body within that notification, are subject to 231 any rules specified by the authorization policy that governs the 232 subscription. 234 In the case of a pending subscription, when final authorization is 235 determined, a NOTIFY can be sent. If the result of the authorization 236 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 237 complete CAP document. If the subscription is rejected, a NOTIFY MAY 238 be sent. As described in RFC 3265 [RFC3265], the Subscription-State 239 header field indicates the state of the subscription. 241 The body of the NOTIFY MUST be sent using one of the types listed in 242 the Accept header field in the most recent SUBSCRIBE request, or 243 using the type "application/common-alerting-protocol+xml" if no 244 Accept header field was present. 246 Notifiers will typically act as Event State Compositors (ESC) and 247 thus will learn the 'common-alerting-protocol' event state via 248 PUBLISH requests sent from authorized Event Publication Agents 249 (EPAs). 251 3.8. Subscriber Processing of NOTIFY Requests 253 RFC 3265 [RFC3265] leaves it to event packages to describe the 254 process followed by the subscriber upon receipt of a NOTIFY request, 255 including any logic required to form a coherent resource state. 257 3.9. Handling of Forked Requests 259 RFC 3265 [RFC3265] requires each package to describe handling of 260 forked SUBSCRIBE requests. 262 This specification only allows a single dialog to be constructed as a 263 result of emitting an initial SUBSCRIBE request. 265 3.10. Rate of Notifications 267 RFC 3265 [RFC3265] requires each package to specify the maximum rate 268 at which notifications can be sent. 270 Notifiers SHOULD NOT generate notifications for a single user at a 271 rate of more than once every five seconds. 273 3.11. State Agents 275 RFC 3265 [RFC3265] requires each package to consider the role of 276 state agents in the package and, if they are used, to specify how 277 authentication and authorization are done. This specification allows 278 state agents to be located in the network. 280 3.12. Examples 282 An example is provided in Section 4. 284 3.13. Use of URIs to Retrieve State 286 RFC 3265 [RFC3265] allows packages to use URIs to retrieve large 287 state documents. 289 CAP documents are fairly small. This event package does not provide 290 a mechanism to use URIs to retrieve large state documents. 292 3.14. PUBLISH Bodies 294 RFC 3903 [RFC3903] requires event packages to define the content 295 types expected in PUBLISH requests. 297 In this event package, the body of a PUBLISH request may contain a 298 CAP document. A CAP document describes an emergency alert or an 299 early warning event. 301 All EPAs and ESCs MUST support the "application/ 302 common-alerting-protocol+xml" data format and MAY support other 303 formats. 305 Note that this document does not mandate how CAP documents are made 306 available to the Public Warning System, for example by authorities or 307 similar organizations. The PUBLISH mechanism is one way. 309 3.15. PUBLISH Response Bodies 311 This specification assumes that a PUBLISH also conveys a CAP document 312 that is later sent further on to watchers. 314 3.16. Multiple Sources for Event State 316 RFC 3903 [RFC3903] requires event packages to specify whether 317 multiple sources can contribute to the event state view at the ESC. 319 This event package allows different EPAs to publish CAP documents for 320 a particular user. The concept of composition is not applicable for 321 this application usage. 323 3.17. Event State Segmentation 325 RFC 3903 [RFC3903] defines segments within a state document. Each 326 segment is defined as one of potentially many identifiable sections 327 in the published event state. 329 This event package defines does not differentiate between different 330 segments. 332 3.18. Rate of Publication 334 RFC 3903 [RFC3903] allows event packages to define their own rate of 335 publication. 337 There are no rate-limiting recommendations for common-alerting- 338 protocol publication. Since emergency alerts and early warning 339 events are typically rare there is no periodicity, nor a minimum or 340 maximum rate of publication. 342 4. Examples 344 Here is an example of a CAP document. 346 348 349 KSTO1055887203 350 KSTO@NWS.NOAA.GOV 351 2003-06-17T14:57:00-07:00 352 Actual 353 Alert 354 Public 355 356 Met 357 SEVERE THUNDERSTORM 358 Severe 359 Likely 360 NATIONAL WEATHER SERVICE SACRAMENTO 361 SEVERE THUNDERSTORM WARNING 362 AT 254 PM PDT... 363 NATIONAL WEATHER SERVICE 364 DOPPLER RADAR INDICATED A SEVERE 365 THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... 366 OR ABOUT 18 MILES SOUTHEAST OF 367 KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... 368 INTENSE RAIN AND STRONG DAMAGING WINDS 369 ARE LIKELY WITH THIS STORM 370 TAKE COVER IN A SUBSTANTIAL SHELTER 371 UNTIL THE STORM PASSES 372 BARUFFALDI/JUSKIE 373 374 EXTREME NORTH CENTRAL TUOLUMNE COUNTY 375 IN CALIFORNIA, EXTREME NORTHEASTERN 376 CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN 377 ALPINE COUNTY IN CALIFORNIA 378 38.47,-120.14 38.34,-119.95 38.52,-119.74 379 38.62,-119.89 38.47,-120.14 380 381 382 384 Example for a Severe Thunderstorm Warning 386 5. Security Considerations 388 This section discusses security considerations when using SIP to 389 distribute warning messages using CAP. 391 5.1. Man-in-the-Middle Attacks 393 Threat: 395 The attacker could then conceivably attempt to impersonate the 396 subject (the putative caller) to some SIP-based target entity. 398 Countermeasures: 400 Such an attack is implausible for several reasons. The subject's 401 assertion: 402 * should be signed, thus causing any alterations to break its 403 integrity and make such alterations detectable. 404 * the intended recipients may be listed in the optionally present 405 audience restriction, which is a cleartext field. As such, it 406 would not allow automatic processing but could give the 407 receiving user further hints. 408 * Issuer is represented in the CAP document (in the 409 element). 410 * validity period for the CAP document may be restricted. 412 5.2. Forgery 414 Threat: 416 A malicious user could forge or alter a CAP document in order to 417 convey messages to SIP entities that get immediate attention of 418 users. 420 Countermeasures: 422 To avoid this kind of attack, the entities must assure that proper 423 mechanisms for protecting the CAP documents are employed, e.g., 424 signing the CAP document itself. Section 3.3.2.1 of [cap] 425 specifies the signing of CAP documents. 427 5.3. Replay Attack 429 Threat: 431 Theft of CAP documents described in this document and replay of it 432 at a later time. 434 Countermeasures: 436 A CAP document contains the mandatory , , 437 elements and an optional element. These 438 attributes make the CAP document unique for a specific sender and 439 provide time restrictions. An entity that has received a CAP 440 message already within the indicated timeframe is able to detect a 441 replayed message and, if the content of that message is unchanged, 442 then no additional security vulnerability is created. Nodes that 443 enter the area of a disaster after the initial distribution of 444 warnings have not yet seen the CAP message and, as such, would not 445 be able to distinguish a replay from the initial message being 446 sent around. However, if the threat that lead to the distribution 447 of warning messages is still imminent then there is no reason not 448 to worry about that message. The source distributing the early 449 warning messages is, however, adviced to carefully select a value 450 for the element and it is RECOMMENDED to set this 451 element. 453 5.4. Unauthorized Distribution 455 Threat: 457 When an entity receives a CAP message it has to determine whether 458 the entity distributing the CAP messages is genuine to avoid 459 accepting messages that are injected by malicious users with the 460 potential desire to at least get the users immediate attention. 462 Countermeasures: 464 When receiving a CAP document a couple of verification steps must 465 be performed. First, it needs to be ensured that the message was 466 delivered via a trusted entitiy (such as a trusted SIP proxy) and 467 that the communication channel between the User Agent and it's SIP 468 proxy is properly secured to exclude various attacks at the SIP 469 level. Then, the message contains the that may contain 470 an entity that falls within the white list of the entity receiving 471 the message. Finally, the message is protected by a digital 472 signature and the entity signing the CAP message may again be 473 listed in a white list of the receiving entity and may therefore 474 be trusted. If none of these verification checks lead to a 475 positive indication of a known sender then the CAP document should 476 be treated as suspicious and configuration at the receiving entity 477 may dictate how to process and display CAP documents in such a 478 case. 480 6. IANA Considerations 482 6.1. Registration of the 'common-alerting-protocol' Event Package 484 This specification registers an event package, based on the 485 registration procedures defined in RFC 3265 [RFC3265]. The following 486 is the information required for such a registration: 487 Package Name: common-alerting-protocol 488 Package or Template-Package: This is a package. 489 Published Document: RFC XXX [Replace by the RFC number of this 490 specification]. 491 Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com 493 6.2. Registration of the 'application/common-alerting-protocol+xml' 494 MIME type 496 To: ietf-types@iana.org 497 Subject: Registration of MIME media type application/ common- 498 alerting-protocol+xml 499 MIME media type name: application 500 MIME subtype name: common-alerting-protocol+xml 501 Required parameters: (none) 502 Optional parameters: charset; Indicates the character encoding of 503 enclosed XML. Default is UTF-8 [RFC3629]. 504 Encoding considerations: Uses XML, which can employ 8-bit 505 characters, depending on the character encoding used. See RFC 506 3023 [RFC3023], Section 3.2. 507 Security considerations: This content type is designed to carry 508 payloads of the Common Alerting Protocol (CAP). 509 Interoperability considerations: This content type provides a way to 510 convey CAP payloads. 511 Published specification: RFC XXX [Replace by the RFC number of this 512 specification]. 513 Applications which use this media type: Applications that convey 514 alerts and early warnings according to the CAP standard. 515 Additional information: OASIS has published the Common Alerting 516 Protocol at [cap]. 517 Person & email address to contact for further information: Hannes 518 Tschofenig, Hannes.Tschofenig@nsn.com 519 Intended usage: Limited use 520 Author/Change controller: IETF SIPPING working group 521 Other information: This media type is a specialization of 522 application/xml RFC 3023 [RFC3023], and many of the considerations 523 described there also apply to application/ 524 common-alerting-protocol+xml. 526 6.3. Early Warning Service URNs 528 In according with RFC 5031 this document defines a new top-level 529 service called 'warning'. This section defines the first service 530 registration within the IANA registry using the top-level service 531 label 'warning'. 533 The 'warning' service type describes emergency services requiring an 534 immediate action or remedy by the recipient of the alert message as 535 instructed by the author of the message. Additional sub-services can 536 be added after expert review and must be of general public interest 537 and have a similar emergency nature. The expert is designated by the 538 ECRIT working group, its successor, or, in their absence, the IESG. 539 The expert review should only approve emergency services that are 540 offered widely and in different countries, with approximately the 541 same caller expectation in terms of services rendered. 543 The following list contains the initial IANA registration for the 544 'warning' service. 546 warning.geo Geophysical (inc. landslide) 547 warning.met Meteorological (inc. flood) 548 warning.safety General emergency and public safety 549 warning.security Law enforcement, military, homeland and local/ 550 private security 551 warning.rescue Rescue and recovery 552 warning.fire Fire suppression and rescue 553 warning.health Medical and public health 554 warning.env Pollution and other environmental 555 warning.transport Public and private transportation 556 warning.infra Utility, telecommunication, other non-transport 557 infrastructure 558 warning.cbrne Chemical, Biological, Radiological, Nuclear or High- 559 Yield Explosive threat or attack 560 warning.other Other events 562 7. Acknowledgments 564 The authors would like to thank Cullen Jennings for supporting this 565 work. We would also like to thank the participants of the Early 566 Warning Adhoc meeting at IETF#69. 568 8. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", March 1997. 573 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 574 1.1", October 2005. 576 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 577 Event Notification", RFC 3265, June 2002. 579 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 580 for Event State Publication", RFC 3903, October 2004. 582 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 583 Types", RFC 3023, January 2001. 585 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 586 10646", STD 63, RFC 3629, November 2003. 588 [I-D.ietf-geopriv-pdif-lo-profile] 589 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 590 PIDF-LO Usage Clarification, Considerations and 591 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 592 (work in progress), November 2008. 594 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 595 Format for Presence Information Data Format Location 596 Object (PIDF-LO)", RFC 5139, February 2008. 598 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 599 Emergency and Other Well-Known Services", RFC 5031, 600 January 2008. 602 Authors' Addresses 604 Brian Rosen 605 NeuStar, Inc. 606 470 Conrad Dr 607 Mars, PA 16046 608 US 610 Phone: 611 Email: br@brianrosen.net 613 Henning Schulzrinne 614 Columbia University 615 Department of Computer Science 616 450 Computer Science Building 617 New York, NY 10027 618 US 620 Phone: +1 212 939 7004 621 Email: hgs+ecrit@cs.columbia.edu 622 URI: http://www.cs.columbia.edu 623 Hannes Tschofenig 624 Nokia Siemens Networks 625 Linnoitustie 6 626 Espoo 02600 627 Finland 629 Phone: +358 (50) 4871445 630 Email: Hannes.Tschofenig@gmx.net 631 URI: http://www.tschofenig.priv.at