Internet DRAFT - draft-rosen-ecrit-addldata-subnot
draft-rosen-ecrit-addldata-subnot
ECRIT B. Rosen
Internet-Draft NeuStar
Intended status: Standards Track November 04, 2013
Expires: May 08, 2014
Updating Additional Data related to an Emergency Call using Subscribe/
Notify
draft-rosen-ecrit-addldata-subnot-01.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 May 08, 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 May 08, 2014 [Page 1]
Internet-Draft Updating Additional Call Data November 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SUBSCRIBE/NOTIFY Package for Additional Call Data . . . . . . 3
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 . . . . . . . . 4
3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 4
3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 4
3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 4
3.10. Rate of Notification . . . . . . . . . . . . . . . . . . 4
3.11. Considerations for use with PUBLISH . . . . . . . . . . . 4
3.11.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . 4
3.11.2. PUBLISH Response Bodies . . . . . . . . . . . . . . 4
3.11.3. Multiple Sources for Event State . . . . . . . . . . 5
3.11.4. Event State Segmentation . . . . . . . . . . . . . . 5
3.11.5. Rate of Publication . . . . . . . . . . . . . . . . 5
4. SUBSCRIBE Additional Data Block . . . . . . . . . . . . . . . 5
4.1. Update SUBSCRIBE URI . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7.1. Event Package Registration . . . . . . . . . . . . . . . 6
7.2. MIME Content-type Registration for
'application/emergencyCall.SvcInfo+xml' . . . . . . . . . 6
7.3. Block Registration . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Additional Data can be provided by a service provider, but can also
be provided by a device. When provided by a device, implementing a
sub/not mechanism implies the device has a server capable of
Rosen Expires May 08, 2014 [Page 2]
Internet-Draft Updating Additional Call Data November 2013
accepting subscriptions and providing notifications. Many devices
could not do that. Instead, the device may PUBLISH the data to an
external server, and then use that server to provide subscription and
notification service.
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.
Rosen Expires May 08, 2014 [Page 3]
Internet-Draft Updating Additional Call Data November 2013
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.
3.11. Considerations for use with PUBLISH
Additional data block(s) may be used with a PUBLISH operation to a
server that can subsequently handle event notification per this
document.
3.11.1. PUBLISH Bodies
The PUBLISH body MUST contain one or more additional data blocks as
defined in [I-D.ietf-ecrit-additional-data]. Blocks whose value did
not change need not appear in a given PUBLISH transaction.
3.11.2. PUBLISH Response Bodies
No bodies are expected in any resonse.
Rosen Expires May 08, 2014 [Page 4]
Internet-Draft Updating Additional Call Data November 2013
3.11.3. Multiple Sources for Event State
Multiple sources for additional data for a given URI handled by the
server is permitted, but no method for aggregating information when
more than one source supplies data for the same block is specified.
If different sources PUBLISH different blocks, the state is the union
of the blocks from all sources.
3.11.4. Event State Segmentation
No special segmentation processing is specified.
3.11.5. Rate of Publication
There are no rate limitations for additional data publication.
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.
Rosen Expires May 08, 2014 [Page 5]
Internet-Draft Updating Additional Call Data November 2013
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:
Rosen Expires May 08, 2014 [Page 6]
Internet-Draft Updating Additional Call Data November 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 May 08, 2014 [Page 7]
Internet-Draft Updating Additional Call Data November 2013
Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J.
Winterbottom, "Additional Data related to an Emergency
Call", draft-ietf-ecrit-additional-data-15 (work in
progress), November 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 May 08, 2014 [Page 8]
