Updating Additional Data related to an Emergency Call using Subscribe/ Notify
draft-rosen-ecrit-addldata-subnot-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Brian Rosen | ||
| Last updated | 2013-07-08 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosen-ecrit-addldata-subnot-00
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: <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
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 <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
[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]