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]