idnits 2.17.1 draft-rosen-ecrit-addldata-subnot-01.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 -- The document date (November 04, 2013) is 3824 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 (-38) exists of draft-ietf-ecrit-additional-data-15 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track November 04, 2013 5 Expires: May 08, 2014 7 Updating Additional Data related to an Emergency Call using Subscribe/ 8 Notify 9 draft-rosen-ecrit-addldata-subnot-01.txt 11 Abstract 13 Additional Call Data is sent in a SIP Call-Info header or in a 14 provided-by element of a PIDF-LO. Sometimes, the information needs 15 to be updated while an emergency call is in progress. It is best for 16 the Public Safety Answering Point (PSAP) to control the timing and 17 frequency of updates. This document describes a SIP Subscribe/Notify 18 Package to supply updates of Additional Call Data. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 08, 2014. 37 Copyright Notice 39 Copyright (c) 2013 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 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. SUBSCRIBE/NOTIFY Package for Additional Call Data . . . . . . 3 57 3.1. Event Package Name . . . . . . . . . . . . . . . . . . . 3 58 3.2. Event Package Parameters . . . . . . . . . . . . . . . . 3 59 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 3 60 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 3 61 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 3 62 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 4 63 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 4 64 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 4 65 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 4 66 3.10. Rate of Notification . . . . . . . . . . . . . . . . . . 4 67 3.11. Considerations for use with PUBLISH . . . . . . . . . . . 4 68 3.11.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . 4 69 3.11.2. PUBLISH Response Bodies . . . . . . . . . . . . . . 4 70 3.11.3. Multiple Sources for Event State . . . . . . . . . . 5 71 3.11.4. Event State Segmentation . . . . . . . . . . . . . . 5 72 3.11.5. Rate of Publication . . . . . . . . . . . . . . . . 5 73 4. SUBSCRIBE Additional Data Block . . . . . . . . . . . . . . . 5 74 4.1. Update SUBSCRIBE URI . . . . . . . . . . . . . . . . . . 5 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 7.1. Event Package Registration . . . . . . . . . . . . . . . 6 79 7.2. MIME Content-type Registration for 80 'application/emergencyCall.SvcInfo+xml' . . . . . . . . . 6 81 7.3. Block Registration . . . . . . . . . . . . . . . . . . . 7 82 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 This document provides a mechanism to update Additional Call Data 88 sent with an emergency call as described in 89 [I-D.ietf-ecrit-additional-data] using the SIP SUBSCRIBE/NOTIFY 90 method. It also defines a new block that provides the URL to which a 91 SUBSCRIBE can be sent by the PSAP to the provider of Additional Call 92 Data. 94 Additional Data can be provided by a service provider, but can also 95 be provided by a device. When provided by a device, implementing a 96 sub/not mechanism implies the device has a server capable of 97 accepting subscriptions and providing notifications. Many devices 98 could not do that. Instead, the device may PUBLISH the data to an 99 external server, and then use that server to provide subscription and 100 notification service. 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. SUBSCRIBE/NOTIFY Package for Additional Call Data 110 This document defines an Event Package as define in RFC 6655 111 [RFC6655] 113 3.1. Event Package Name 115 The name of this event package is "additional-call-data". 117 3.2. Event Package Parameters 119 This event package does not define any package parameters 121 3.3. SUBSCRIBE Bodies 123 This event package defines no message bodies to be used in the 124 SUBSCRIBE message. 126 3.4. Subscription Duration 128 A subscription would not last longer than an emergency call, but the 129 length of a call varies widely. A few minutes is a reasonable first 130 subscription time. PSAPs should not expect a data source to accept 131 subscriptions longer than 10 minutes. 133 3.5. NOTIFY Bodies 135 The content of a NOTIFY body will be a set of blocks as defined in 136 [I-D.ietf-ecrit-additional-data]. No delta or difference mechanism 137 is provided for, but a block that did not change from the prior 138 transmission MAY be omitted. To get the subscription address, the 139 PSAP would have to have gotten the entire block set, by value or by 140 reference, and subsequent NOTIFY messages (including the initial one) 141 need only contain blocks which have changed. Blocks that have not 142 changed MAY be sent in any NOTIFY, at the option of the data 143 provider. 145 3.6. Notifier Processing of SUBSCRIBE Requests 147 Upon receipt of a SUBSCRIBE request, the notifier applies 148 authorization according to local policy. Typically, PSAPS will have 149 credentials that may be useful to data providers in making such 150 authorization decisions. 152 3.7. Notifier Generation of NOTIFY Requests 154 NOTIFY messages are generated whenever the data in one or more blocks 155 change. Small changes in values that are not significant to handling 156 emergency calls SHOULD NOT generate new NOTIFY requests. 158 3.8. Subscriber Processing of NOTIFY Requests 160 Upon receipt of a NOTIFY message, the subscriber applies any 161 information in the message to update its view of the underlying data. 163 3.9. Handling of Forked Requests 165 Forking of Additional Call Data requests is not expected to occur. 166 In the aberrant circumstance that a SUBSCRIBE request is forked, the 167 subscriber SHOULD terminate all but one subscription. 169 3.10. Rate of Notification 171 While some data (e.g. sensor data) may change rapidly, PSAPs and 172 responders cannot usually make use of a high rate of NOTIFY requests. 173 Notifiers MUST implement event rate control RFC 6446 [RFC6446]. In 174 the absence of an event rate filter, Notifiers MUST NOT send 175 notifications more frequently than once every twenty seconds. 177 3.11. Considerations for use with PUBLISH 179 Additional data block(s) may be used with a PUBLISH operation to a 180 server that can subsequently handle event notification per this 181 document. 183 3.11.1. PUBLISH Bodies 185 The PUBLISH body MUST contain one or more additional data blocks as 186 defined in [I-D.ietf-ecrit-additional-data]. Blocks whose value did 187 not change need not appear in a given PUBLISH transaction. 189 3.11.2. PUBLISH Response Bodies 191 No bodies are expected in any resonse. 193 3.11.3. Multiple Sources for Event State 195 Multiple sources for additional data for a given URI handled by the 196 server is permitted, but no method for aggregating information when 197 more than one source supplies data for the same block is specified. 198 If different sources PUBLISH different blocks, the state is the union 199 of the blocks from all sources. 201 3.11.4. Event State Segmentation 203 No special segmentation processing is specified. 205 3.11.5. Rate of Publication 207 There are no rate limitations for additional data publication. 209 4. SUBSCRIBE Additional Data Block 211 This document defines a new Additional Data block type to contain the 212 URI to send a SUBSCRIBE to. 214 4.1. Update SUBSCRIBE URI 216 Data Element: Update SUBSCRIBE URI 218 Use: Optional 220 XML Element: 222 Description: If the data provider anticipates some block data may 223 change during the processing of an emergency call, it MAY provide 224 this URI to send a SUBSCRIBE to. This MUST be a SIP URI. . 226 Reason for Need: Provide a PSAP controlled update mechanism for 227 blocks that may change during an emergency call. 229 How Used by Call Taker: To obtain updates for Additional Call Data. 231 5. Security Considerations 233 Security considerations for the SUBSCRIBE/NOTIFY update mechanism are 234 identical to those in [I-D.ietf-ecrit-additional-data]. The same 235 credentials described in that document would be used to identify the 236 PSAP and the data provider. The SUBSCRIBE URI should be protected 237 against casual observation, and thus SIPS or HTTPS, as appropriate 238 SHOULD be used on the original transmission of blocks which contains 239 the SUBSCRIBE URI block. 241 Rapid updates could overwhelm PSAPs. The event rate controls defined 242 in Section 3.10 are essential to allow PSAPs to control the update 243 rate. 245 6. Privacy Considerations 247 The privacy considerations detailed in 248 [I-D.ietf-ecrit-additional-data] apply to updates of the blocks as 249 well as the original transmission. 251 7. IANA Considerations 253 7.1. Event Package Registration 255 This document defines a new Event Package as described in [RFC6655] 256 and registers it in the Event packages and Event template-packages 257 registry. The Package Name is "additional-call-data", The Type is 258 "package". The contact is "Brian Rosen, br@brianrosen.net" and the 259 Reference is this document. 261 7.2. MIME Content-type Registration for 'application/ 262 emergencyCall.SvcInfo+xml' 264 This specification requests the registration of a new MIME type 265 according to the procedures of RFC 4288 [RFC4288] and guidelines in 266 RFC 3023 [RFC3023]. 268 MIME media type name: application 270 MIME subtype name: emergencyCall.UpdateSubscribeURI+xml 272 Mandatory parameters: none 274 Optional parameters: charset 276 Indicates the character encoding of enclosed XML. 278 Encoding considerations: 280 Uses XML, which can employ 8-bit characters, depending on the 281 character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. 283 Security considerations: 285 This content type is designed to carry an event package 286 subscription URI, which is a sub-category of additional data about 287 an emergency call. 289 Please refer to Section 5 for more information about the 290 sensitivity of the SUBSCRIBE URI. 292 Interoperability considerations: None 294 Published specification: [TBD: This document] 296 Applications which use this media type: Emergency Services 298 Additional information: 300 Magic Number: None 302 File Extension: .xml 304 Macintosh file type code: 'TEXT' 306 Person and email address for further information: Brian Rosen, 307 br@brianrosen.net 309 Intended usage: LIMITED USE 311 Author: This specification is a work item of the IETF ECRIT 312 working group, with mailing list address . 314 Change controller: The IESG 316 7.3. Block Registration 318 This document registers a new Additional Data block as defined in 319 [I-D.ietf-ecrit-additional-data] and registers it in the Additional 320 Call Data Blocks Registry. The Token is "UpdateSubscribeURI", the 321 Reference is this document. 323 8. Normative References 325 [I-D.ietf-ecrit-additional-data] 326 Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J. 327 Winterbottom, "Additional Data related to an Emergency 328 Call", draft-ietf-ecrit-additional-data-15 (work in 329 progress), November 2013. 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 335 Types", RFC 3023, January 2001. 337 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 338 Registration Procedures", RFC 4288, December 2005. 340 [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 341 Protocol (SIP) Event Notification Extension for 342 Notification Rate Control", RFC 6446, January 2012. 344 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 345 Transport Layer Security (TLS)", RFC 6655, July 2012. 347 Author's Address 349 Brian Rosen 350 NeuStar 351 470 Conrad Dr. 352 Mars, PA 16046 353 US 355 Phone: +1 724 382 1051 356 Email: br@brianrosen.net