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