draft-ietf-ecrit-additional-data-36.txt   draft-ietf-ecrit-additional-data-37.txt 
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Updates: 6443, 6881 (if approved) B. Rosen Updates: 6443, 6881 (if approved) B. Rosen
Intended status: Standards Track NeuStar Intended status: Standards Track NeuStar
Expires: April 6, 2016 H. Tschofenig Expires: April 14, 2016 H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
October 4, 2015 October 12, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-36.txt draft-ietf-ecrit-additional-data-37.txt
Abstract Abstract
When an emergency call is sent to a Public Safety Answering Point When an emergency call is sent to a Public Safety Answering Point
(PSAP), the originating device, the access network provider to which (PSAP), the originating device, the access network provider to which
the device is connected, and all service providers in the path of the the device is connected, and all service providers in the path of the
call have information about the call, the caller or the location call have information about the call, the caller or the location
which is helpful for the PSAP to have in handling the emergency. which is helpful for the PSAP to have in handling the emergency.
This document describes data structures and mechanisms to convey such This document describes data structures and mechanisms to convey such
data to the PSAP. The intent is that every emergency call carry as data to the PSAP. The intent is that every emergency call carry as
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2016. This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 35, line 34 skipping to change at page 35, line 34
entities are expected to provide sets of data, the data itself needs entities are expected to provide sets of data, the data itself needs
information describing the source. Consequently, each entity adding information describing the source. Consequently, each entity adding
additional data MUST supply a "Data Provider" block. All other additional data MUST supply a "Data Provider" block. All other
blocks are optional, but each entity SHOULD supply all blocks where blocks are optional, but each entity SHOULD supply all blocks where
it has at least some of the information in the block. it has at least some of the information in the block.
Note that, as with any mechanism, failures are possible. For Note that, as with any mechanism, failures are possible. For
example, a block (provided by value or by reference) might not be the example, a block (provided by value or by reference) might not be the
type indicated by the "purpose" parameter, or might be badly formed, type indicated by the "purpose" parameter, or might be badly formed,
etc. The general principle that applies to emergency calls is that etc. The general principle that applies to emergency calls is that
it is more important for the call to go through than for for it is more important for the call to go through than for everything
everything to be correct. Thus, most PSAPs will process a call if at to be correct. Thus, most PSAPs will process a call if at all
all possible, even if data is missing or other failures occur. possible, even if data is missing or other failures occur.
6.1. Transmitting Blocks using Call-Info 6.1. Transmitting Blocks using Call-Info
A URI to a block MAY be inserted in any SIP request or response A URI to a block MAY be inserted in any SIP request or response
method (most often INVITE or MESSAGE) with a Call-Info header field method (most often INVITE or MESSAGE) with a Call-Info header field
containing a purpose value starting with 'EmergencyCallData', a dot containing a purpose value starting with 'EmergencyCallData', a dot
("."), and the type of data available at the URI. The type of data ("."), and the type of data available at the URI. The type of data
is denoted by including the root of the MIME media subtype (the is denoted by including the root of the MIME media subtype (the
'EmergencyCallData' prefix is not repeated), omitting any suffix such 'EmergencyCallData' prefix is not repeated), omitting any suffix such
as '+xml'). For example, when referencing a block with MIME media as '+xml'). For example, when referencing a block with MIME media
skipping to change at page 84, line 48 skipping to change at page 84, line 48
group. The authors are grateful for the initial work and extended group. The authors are grateful for the initial work and extended
comments provided by many NENA participants, including Delaine comments provided by many NENA participants, including Delaine
Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra, Leyerle, Kathy McMahon, Christian Militeau, Ira Pyles, Matt Serra,
and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank and Robert (Bob) Sherry. Amursana Khiyod, Robert Sherry, Frank
Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback Rahoi, Scott Ross, and Tom Klepetka provided valuable feedback
regarding the vCard/xCard use in this specification. regarding the vCard/xCard use in this specification.
We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris Thomson, Keith Drage, Laura Liess, Chris Santer, Barbara Stark, Chris
Santer, Archie Cobbs, Magnus Nystrom, and Francis Dupont for their Santer, Archie Cobbs, Magnus Nystrom, Stephen Farrell, and Francis
review comments. Alissa Cooper, Guy Caron, Ben Campbell, and Barry Dupont for their review comments. Alissa Cooper, Guy Caron, Ben
Leiba deserves special mention for their detailed and extensive Campbell, and Barry Leiba deserves special mention for their detailed
review comments, which were very helpful and appreciated. and extensive review comments, which were very helpful and
appreciated.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 6 change blocks. 
11 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/