One document matched: draft-rosen-ecrit-addldata-subnot-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std" ipr="trust200902" docName="draft-rosen-ecrit-addldata-subnot-00.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Updating Additional Call Data">Updating Additional Data related to an Emergency Call using Subscribe/Notify</title>
<author fullname="Brian Rosen" initials="B.R" surname="Rosen">
<organization>NeuStar</organization>
<address>
<postal>
<street>470 Conrad Dr.</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<phone>+1 724 382 1051</phone>
<email>br@brianrosen.net</email>
</address>
</author>
<date year="2013"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Additional Call Data</keyword>
<keyword>Emergency Services</keyword>
<keyword>Call Information</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************************* -->
<section anchor="introduction" title="Introduction">
<t>This document provides a mechanism to update Additional Call Data sent with an emergency call as described in
<xref target="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.
</t>
</section>
<!-- ******************************************************************************* -->
<section title="Terminology">
<t> 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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<!-- ******************************************************************************* -->
<section title="SUBSCRIBE/NOTIFY Package for Additional Call Data">
<t>This document defines an Event Package as define in <xref target="RFC6655">RFC 6655</xref></t>
<section title="Event Package Name">
<t>The name of this event package is "additional-call-data".</t>
</section>
<section title="Event Package Parameters">
<t>This event package does not define any package parameters</t>
</section>
<section title="SUBSCRIBE Bodies">
<t>This event package defines no message bodies to be used in the
SUBSCRIBE message.</t>
</section>
<section title="Subscription Duration">
<t>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.</t>
</section>
<section title="NOTIFY Bodies">
<t>The content of a NOTIFY body will be a set of blocks as defined in <xref target="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.</t>
</section>
<section title="Notifier Processing of SUBSCRIBE Requests">
<t>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.</t>
</section>
<section title="Notifier Generation of NOTIFY Requests">
<t>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.</t>
</section>
<section title="Subscriber Processing of NOTIFY Requests">
<t>Upon receipt of a NOTIFY message, the subscriber applies any
information in the message to update its view of the underlying
data. </t>
</section>
<section title="Handling of Forked Requests">
<t>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.</t>
</section>
<section anchor="rate" title="Rate of Notification">
<t>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 <xref target="RFC6446">RFC 6446</xref>. In the absence of an event rate filter, Notifiers MUST NOT send
notifications more frequently than once every twenty seconds.</t>
</section>
</section>
<!-- ******************************************************************************* -->
<section title="SUBSCRIBE Additional Data Block">
<t>This document defines a new Additional Data block type to contain the URI to send a SUBSCRIBE to.</t>
<section title="Update SUBSCRIBE URI">
<t>
<list style="hanging">
<t hangText="Data Element:">Update SUBSCRIBE URI<vspace blankLines="1"/>
</t>
<t hangText="Use:">Optional<vspace blankLines="1"/>
</t>
<t hangText="XML Element:"><UpdateSubscribeURII><vspace blankLines="1"/>
</t>
<t hangText="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. .<vspace blankLines="1"/>
</t>
<t hangText="Reason for Need:">Provide a PSAP controlled update mechanism for blocks that may change during an emergency call.<vspace blankLines="1"/>
</t>
<t hangText="How Used by Call Taker:">To obtain updates for Additional Call Data.</t>
</list>
</t>
</section>
</section>
<!-- ******************************************************************************* -->
<section anchor="security" title="Security Considerations">
<t>Security considerations for the SUBSCRIBE/NOTIFY update mechanism are identical to those in <xref target="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.</t>
<t>Rapid updates could overwhelm PSAPs. The event rate controls defined in <xref target="rate"/> are essential to allow PSAPs to control the update rate.</t>
</section>
<!-- ******************************************************************************* -->
<section anchor="privacy" title="Privacy Considerations">
<t>The privacy considerations detailed in <xref target="I-D.ietf-ecrit-additional-data"/> apply to updates of the blocks as well as the original transmission.</t>
</section>
<!-- ******************************************************************************* -->
<section title="IANA Considerations">
<section title="Event Package Registration">
<t>This document defines a new Event Package as described in <xref target="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.</t>
</section>
<section title="MIME Content-type Registration for 'application/emergencyCall.SvcInfo+xml'">
<t>This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 <xref target="RFC4288"/> and guidelines in RFC
3023 <xref target="RFC3023"/>.</t>
<t>
<list style="empty">
<t>MIME media type name: application</t>
<t>MIME subtype name: emergencyCall.UpdateSubscribeURI+xml</t>
<t>Mandatory parameters: none</t>
<t>Optional parameters: charset<vspace blankLines="1"/>
Indicates the character encoding of enclosed XML.
</t>
<t>Encoding considerations:<vspace blankLines="1"/>
Uses XML, which can employ 8-bit characters, depending on the
character encoding used.
See Section 3.2 of RFC 3023 <xref target="RFC3023"/>.
</t>
<t>Security considerations:<vspace blankLines="1"/>
This content type is designed to carry an event package subscription URI, which is a sub-category of additional
data about an emergency call.
<vspace blankLines="1"/>
Please refer
to <xref target="security"/> for more
information about the sensitivity of the SUBSCRIBE URI.</t>
<t>Interoperability considerations: None</t>
<t>Published specification: [TBD: This document]</t>
<t>Applications which use this media type:
Emergency Services
</t>
<t>Additional information:<vspace blankLines="1"/>
Magic Number: None<vspace blankLines="1"/>
File Extension: .xml<vspace blankLines="1"/>
Macintosh file type code: 'TEXT'<vspace blankLines="1"/>
</t>
<t>Person and email address for further information:
Brian Rosen, br@brianrosen.net
</t>
<t>Intended usage: LIMITED USE</t>
<t>Author:
This specification is a work item of the IETF ECRIT working
group, with mailing list address <ecrit@ietf.org>.
</t>
<t>Change controller:
The IESG <ietf@ietf.org>
</t>
</list>
</t>
</section>
<section title="Block Registration">
<t>This document registers a new Additional Data block as defined in <xref target="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.</t>
</section>
</section>
<!-- ******************************************************************************* -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3023"?>
<?rfc include="reference.RFC.4288"?>
<?rfc include="reference.RFC.6446"?>
<?rfc include="reference.RFC.6655"?>
<?rfc include="reference.I-D.ietf-ecrit-additional-data"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 00:40:22 |