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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. SUBSCRIBE/NOTIFY Package for Additional Call Data
• 3.1. Event Package Name
• 3.2. Event Package Parameters
• 3.3. SUBSCRIBE Bodies
• 3.4. Subscription Duration
• 3.5. NOTIFY Bodies
• 3.6. Notifier Processing of SUBSCRIBE Requests
• 3.7. Notifier Generation of NOTIFY Requests
• 3.8. Subscriber Processing of NOTIFY Requests
• 3.9. Handling of Forked Requests
• 3.10. Rate of Notification
• 4. SUBSCRIBE Additional Data Block
• 4.1. Update SUBSCRIBE URI
• 5. Security Considerations
• 6. Privacy Considerations
• 7. IANA Considerations
• 7.1. Event Package Registration
• 7.2. MIME Content-type Registration for 'application/emergencyCall.SvcInfo+xml'
• 7.3. Block Registration
• 8. Normative References
• Author's Address

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

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.

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:

<UpdateSubscribeURII>

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

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:
  
  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 <ecrit@ietf.org>.
• Change controller: The IESG <ietf@ietf.org>

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

Author's Address