ECRIT B. Rosen Internet-Draft NeuStar Intended status: Standards Track July 08, 2013 Expires: January 09, 2014 Updating Additional Data related to an Emergency Call using Subscribe/ Notify draft-rosen-ecrit-addldata-subnot-00.txt Abstract Additional Call Data is sent in a SIP Call-Info header or in a provided-by element of a PIDF-LO. Sometimes, the information needs to be updated while an emergency call is in progress. It is best for the Public Safety Answering Point (PSAP) to control the timing and frequency of updates. This document describes a SIP Subscribe/Notify Package to supply updates of Additional Call Data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 09, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Rosen Expires January 09, 2014 [Page 1] Internet-Draft Updating Additional Call Data July 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. SUBSCRIBE/NOTIFY Package for Additional Call Data . . . . . . 2 3.1. Event Package Name . . . . . . . . . . . . . . . . . . . 3 3.2. Event Package Parameters . . . . . . . . . . . . . . . . 3 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 3 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 3 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 3 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 3 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 3 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 4 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 4 3.10. Rate of Notification . . . . . . . . . . . . . . . . . . 4 4. SUBSCRIBE Additional Data Block . . . . . . . . . . . . . . . 4 4.1. Update SUBSCRIBE URI . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.1. Event Package Registration . . . . . . . . . . . . . . . 5 7.2. MIME Content-type Registration for 'application/emergencyCall.SvcInfo+xml' . . . . . . . . . 5 7.3. Block Registration . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document provides a mechanism to update Additional Call Data sent with an emergency call as described in [I-D.ietf-ecrit-additional-data] using the SIP SUBSCRIBE/NOTIFY method. It also defines a new block that provides the URL to which a SUBSCRIBE can be sent by the PSAP to the provider of Additional Call Data. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. SUBSCRIBE/NOTIFY Package for Additional Call Data Rosen Expires January 09, 2014 [Page 2] Internet-Draft Updating Additional Call Data July 2013 This document defines an Event Package as define in RFC 6655 [RFC6655] 3.1. Event Package Name The name of this event package is "additional-call-data". 3.2. Event Package Parameters This event package does not define any package parameters 3.3. SUBSCRIBE Bodies This event package defines no message bodies to be used in the SUBSCRIBE message. 3.4. Subscription Duration A subscription would not last longer than an emergency call, but the length of a call varies widely. A few minutes is a reasonable first subscription time. PSAPs should not expect a data source to accept subscriptions longer than 10 minutes. 3.5. NOTIFY Bodies The content of a NOTIFY body will be a set of blocks as defined in [I-D.ietf-ecrit-additional-data]. No delta or difference mechanism is provided for, but a block that did not change from the prior transmission MAY be omitted. To get the subscription address, the PSAP would have to have gotten the entire block set, by value or by reference, and subsequent NOTIFY messages (including the initial one) need only contain blocks which have changed. Blocks that have not changed MAY be sent in any NOTIFY, at the option of the data provider. 3.6. Notifier Processing of SUBSCRIBE Requests Upon receipt of a SUBSCRIBE request, the notifier applies authorization according to local policy. Typically, PSAPS will have credentials that may be useful to data providers in making such authorization decisions. 3.7. Notifier Generation of NOTIFY Requests NOTIFY messages are generated whenever the data in one or more blocks change. Small changes in values that are not significant to handling emergency calls SHOULD NOT generate new NOTIFY requests. Rosen Expires January 09, 2014 [Page 3] Internet-Draft Updating Additional Call Data July 2013 3.8. Subscriber Processing of NOTIFY Requests Upon receipt of a NOTIFY message, the subscriber applies any information in the message to update its view of the underlying data. 3.9. Handling of Forked Requests Forking of Additional Call Data requests is not expected to occur. In the aberrant circumstance that a SUBSCRIBE request is forked, the subscriber SHOULD terminate all but one subscription. 3.10. Rate of Notification While some data (e.g. sensor data) may change rapidly, PSAPs and responders cannot usually make use of a high rate of NOTIFY requests. Notifiers MUST implement event rate control RFC 6446 [RFC6446]. In the absence of an event rate filter, Notifiers MUST NOT send notifications more frequently than once every twenty seconds. 4. SUBSCRIBE Additional Data Block This document defines a new Additional Data block type to contain the URI to send a SUBSCRIBE to. 4.1. Update SUBSCRIBE URI Data Element: Update SUBSCRIBE URI Use: Optional XML Element: Description: If the data provider anticipates some block data may change during the processing of an emergency call, it MAY provide this URI to send a SUBSCRIBE to. This MUST be a SIP URI. . Reason for Need: Provide a PSAP controlled update mechanism for blocks that may change during an emergency call. How Used by Call Taker: To obtain updates for Additional Call Data. 5. Security Considerations Rosen Expires January 09, 2014 [Page 4] Internet-Draft Updating Additional Call Data July 2013 Security considerations for the SUBSCRIBE/NOTIFY update mechanism are identical to those in [I-D.ietf-ecrit-additional-data]. The same credentials described in that document would be used to identify the PSAP and the data provider. The SUBSCRIBE URI should be protected against casual observation, and thus SIPS or HTTPS, as appropriate SHOULD be used on the original transmission of blocks which contains the SUBSCRIBE URI block. Rapid updates could overwhelm PSAPs. The event rate controls defined in Section 3.10 are essential to allow PSAPs to control the update rate. 6. Privacy Considerations The privacy considerations detailed in [I-D.ietf-ecrit-additional-data] apply to updates of the blocks as well as the original transmission. 7. IANA Considerations 7.1. Event Package Registration This document defines a new Event Package as described in [RFC6655] and registers it in the Event packages and Event template-packages registry. The Package Name is "additional-call-data", The Type is "package". The contact is "Brian Rosen, br@brianrosen.net" and the Reference is this document. 7.2. MIME Content-type Registration for 'application/ emergencyCall.SvcInfo+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023]. MIME media type name: application MIME subtype name: emergencyCall.UpdateSubscribeURI+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Rosen Expires January 09, 2014 [Page 5] Internet-Draft Updating Additional Call Data July 2013 Uses XML, which can employ 8-bit characters, depending on the character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. Security considerations: This content type is designed to carry an event package subscription URI, which is a sub-category of additional data about an emergency call. Please refer to Section 5 for more information about the sensitivity of the SUBSCRIBE URI. Interoperability considerations: None Published specification: [TBD: This document] Applications which use this media type: Emergency Services Additional information: Magic Number: None File Extension: .xml Macintosh file type code: 'TEXT' Person and email address for further information: Brian Rosen, br@brianrosen.net Intended usage: LIMITED USE Author: This specification is a work item of the IETF ECRIT working group, with mailing list address . Change controller: The IESG 7.3. Block Registration This document registers a new Additional Data block as defined in [I-D.ietf-ecrit-additional-data] and registers it in the Additional Call Data Blocks Registry. The Token is "UpdateSubscribeURI", the Reference is this document. 8. Normative References [I-D.ietf-ecrit-additional-data] Rosen Expires January 09, 2014 [Page 6] Internet-Draft Updating Additional Call Data July 2013 Rosen, B., Tschofenig, H., Marshall, R., and R. Randy, "Additional Data related to an Emergency Call", draft- ietf-ecrit-additional-data-09 (work in progress), May 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control", RFC 6446, January 2012. [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012. Author's Address Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 US Phone: +1 724 382 1051 Email: br@brianrosen.net Rosen Expires January 09, 2014 [Page 7]