draft-ietf-ecrit-additional-data-31.txt   draft-ietf-ecrit-additional-data-32.txt 
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Qualcomm Technologies, Inc. Internet-Draft Qualcomm Technologies, Inc.
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: January 4, 2016 NeuStar Expires: January 5, 2016 NeuStar
H. Tschofenig H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
July 3, 2015 July 4, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-31.txt draft-ietf-ecrit-additional-data-32.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 the data to the PSAP. The intent is that every emergency call carry the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 January 4, 2016. This Internet-Draft will expire on January 5, 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 33, line 11 skipping to change at page 33, line 11
in an existing SIP header field, the Call-Info header, is in an existing SIP header field, the Call-Info header, is
defined. The URI points to the additional data structure. The defined. The URI points to the additional data structure. The
Call-Info header is specified in Section 20.9 of [RFC3261]. This Call-Info header is specified in Section 20.9 of [RFC3261]. This
document adds a new compound token starting with the value document adds a new compound token starting with the value
'EmergencyCallData' for the Call-Info "purpose" parameter. If 'EmergencyCallData' for the Call-Info "purpose" parameter. If
the "purpose" parameter is set to a value starting with the "purpose" parameter is set to a value starting with
'EmergencyCallData', then the Call-Info header contains either an 'EmergencyCallData', then the Call-Info header contains either an
HTTPS URL pointing to an external resource or a CID (content HTTPS URL pointing to an external resource or a CID (content
indirection) URI that allows the data structure to be placed in indirection) URI that allows the data structure to be placed in
the body of the SIP message. The "purpose" parameter also the body of the SIP message. The "purpose" parameter also
indicates the kind of data (by its MIME type) that is available indicates the kind of data (by its MIME subtype) that is
at the URI. As the data is conveyed using a URI in the SIP available at the URI. As the data is conveyed using a URI in the
signaling, the data itself may reside on an external resource, or SIP signaling, the data itself may reside on an external
may be contained within the body of the SIP message. When the resource, or may be contained within the body of the SIP message.
URI refers to data at an external resource, the data is said to When the URI refers to data at an external resource, the data is
be passed by reference. When the URI refers to data contained said to be passed by reference. When the URI refers to data
within the body of the SIP message, the data is said to be passed contained within the body of the SIP message, the data is said to
by value. A PSAP or emergency responder is able to examine the be passed by value. A PSAP or emergency responder is able to
type of data provided and selectively inspect the data it is examine the type of data provided and selectively inspect the
interested in, while forwarding all of it (the values or data it is interested in, while forwarding all of it (the values
references) to downstream entities. To be conveyed in a SIP or references) to downstream entities. To be conveyed in a SIP
body, additional data about a call is defined as a series of MIME body, additional data about a call is defined as a series of MIME
objects. Each block defined in this document is an XML data objects. Each block defined in this document is an XML data
structure identified by its MIME type. (Blocks defined by others structure identified by its MIME type. (Blocks defined by others
may be encoded in XML or not, as identified by their MIME may be encoded in XML or not, as identified by their MIME
registration.) As usual, whenever more than one MIME part is registration.) As usual, whenever more than one MIME part is
included in the body of a message, MIME multipart (i.e., included in the body of a message, MIME multipart (i.e.,
'multipart/mixed') encloses them all. This document defines a 'multipart/mixed') encloses them all. This document defines a
set of XML schemas and MIME types used for each block defined set of XML schemas and MIME types used for each block defined
here. When additional data is passed by value in the SIP here. When additional data is passed by value in the SIP
signaling, each CID URL points to one block in the body. signaling, each CID URL points to one block in the body.
skipping to change at page 34, line 38 skipping to change at page 34, line 38
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.
5.1. Transmitting Blocks using the Call-Info Header 5.1. Transmitting Blocks using the Call-Info Header
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' and the containing a purpose value starting with 'EmergencyCallData', a dot
type of data available at the URI. The type of data is denoted by ("."), and the type of data available at the URI. The type of data
including the root of the MIME type (not including the is denoted by including the root of the MIME subtype (the
'EmergencyCallData' prefix and any suffix such as '+xml') with a '.' 'EmergencyCallData' prefix is not repeated), omitting any suffix such
separator. For example, when referencing a block with MIME type as '+xml'). For example, when referencing a block with MIME type
'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose'
parameter is set to 'EmergencyCallData.ProviderInfo'. An example parameter is set to 'EmergencyCallData.ProviderInfo'. An example
"Call-Info" header field for this would be: "Call-Info" header field for this would be:
Call-Info: https://www.example.com/23sedde3; Call-Info: https://www.example.com/23sedde3;
purpose="EmergencyCallData.ProviderInfo" purpose="EmergencyCallData.ProviderInfo"
A Call-info header with a purpose value starting with A Call-info header with a purpose value starting with
'EmergencyCallData' only has meaning in the context of an emergency 'EmergencyCallData' only has meaning in the context of an emergency
call (as ascertained by the presence of an emergency service URN in a call (as ascertained by the presence of an emergency service URN in a
skipping to change at page 69, line 49 skipping to change at page 69, line 49
obviously duplicate existing functionality. The expert is also obviously duplicate existing functionality. The expert is also
responsible for verifying that the block is correctly categorized per responsible for verifying that the block is correctly categorized per
the description of the categories in Section 1. the description of the categories in Section 1.
The registry contains an entry for every data block that can be sent The registry contains an entry for every data block that can be sent
with an emergency call using the mechanisms as specified in this with an emergency call using the mechanisms as specified in this
document. Each data block is identified by the "root" of its MIME document. Each data block is identified by the "root" of its MIME
subtype (which is the part after 'EmergencyCallData.'). If the MIME subtype (which is the part after 'EmergencyCallData.'). If the MIME
subtype does not start with 'EmergencyCallData.', then it cannot be subtype does not start with 'EmergencyCallData.', then it cannot be
registered here nor used in a Call-Info header as specified in this registered here nor used in a Call-Info header as specified in this
document. The subtype MAY exist under any MIME type (although most document. The subtype MAY exist under any MIME media type (although
commonly these are under 'Application/' this is NOT REQUIRED), most commonly these are under 'Application/' this is NOT REQUIRED),
however, to be added to the registry the "root" needs to be unique however, to be added to the registry the "root" needs to be unique
regardless of the MIME type. regardless of the MIME media type.
The content of this registry includes: The content of this registry includes:
Token: The root of the data's MIME subtype (not including the Token: The root of the data's MIME subtype (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') 'EmergencyCallData' prefix and any suffix such as '+xml')
Data About: Indicates if the data describes the call, the caller, or Data About: Indicates if the data describes the call, the caller, or
the location (or is applicable to all), which helps PSAPs and the location (or is applicable to all), which helps PSAPs and
other entities determine if they wish to process the block. The other entities determine if they wish to process the block. The
value MUST be either "The Call", "The Caller", "The Location", or value MUST be either "The Call", "The Caller", "The Location", or
 End of changes. 8 change blocks. 
23 lines changed or deleted 23 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/