< draft-ietf-ecrit-additional-data-35.txt   draft-ietf-ecrit-additional-data-36.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: March 19, 2016 H. Tschofenig Expires: April 6, 2016 H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
September 16, 2015 October 4, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-35.txt draft-ietf-ecrit-additional-data-36.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 March 19, 2016. This Internet-Draft will expire on April 6, 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 3, line 20 skipping to change at page 3, line 20
4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 28 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 28
4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 31 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 31 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 31
5. Issues with getting new types of data into use . . . . . . . 32 5. Issues with getting new types of data into use . . . . . . . 32
5.1. Choosing between defining a new type of block or new type 5.1. Choosing between defining a new type of block or new type
of device/service-specific additional data . . . . . . . 32 of device/service-specific additional data . . . . . . . 32
6. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33 6. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33
6.1. Transmitting Blocks using Call-Info . . . . . . . . . . . 35 6.1. Transmitting Blocks using Call-Info . . . . . . . . . . . 35
6.2. Transmitting Blocks by Reference using the <provided-by> 6.2. Transmitting Blocks by Reference using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 Element . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39 6.4. The Content-Disposition Parameter . . . . . . . . . . . . 39
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53 8. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 53 8.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 53
8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 55 8.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 55
8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 56 8.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 56
8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 58 8.4. EmergencyCallData.SubscriberInfo XML Schema . . . . . . . 58
8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 59 8.5. EmergencyCallData.Comment XML Schema . . . . . . . . . . 59
8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 60 8.6. provided-by XML Schema . . . . . . . . . . . . . . . . . 60
9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 62
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
11.1. Registry creation . . . . . . . . . . . . . . . . . . . 67 11.1. Registry creation . . . . . . . . . . . . . . . . . . . 67
11.1.1. Provider ID Series Registry . . . . . . . . . . . . 67 11.1.1. Provider ID Series Registry . . . . . . . . . . . . 67
11.1.2. Service Environment Registry . . . . . . . . . . . . 67 11.1.2. Service Environment Registry . . . . . . . . . . . . 68
11.1.3. Service Type Registry . . . . . . . . . . . . . . . 68 11.1.3. Service Type Registry . . . . . . . . . . . . . . . 68
11.1.4. Service Mobility Registry . . . . . . . . . . . . . 68 11.1.4. Service Mobility Registry . . . . . . . . . . . . . 68
11.1.5. Service Provider Type Registry . . . . . . . . . . . 69 11.1.5. Service Provider Type Registry . . . . . . . . . . . 69
11.1.6. Device Classification Registry . . . . . . . . . . . 69 11.1.6. Device Classification Registry . . . . . . . . . . . 69
11.1.7. Device ID Type Type Registry . . . . . . . . . . . . 69 11.1.7. Device ID Type Type Registry . . . . . . . . . . . . 70
11.1.8. Device/Service Data Type Registry . . . . . . . . . 70 11.1.8. Device/Service Data Type Registry . . . . . . . . . 70
11.1.9. Emergency Call Data Types Registry . . . . . . . . . 70 11.1.9. Emergency Call Data Types Registry . . . . . . . . . 70
11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 71 11.2. 'EmergencyCallData' Purpose Parameter Value . . . . . . 72
11.3. URN Sub-Namespace Registration for <provided-by> 11.3. URN Sub-Namespace Registration for <provided-by>
Registry Entry . . . . . . . . . . . . . . . . . . . . . 72 Registry Entry . . . . . . . . . . . . . . . . . . . . . 72
11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72 11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 72
11.4.1. MIME Content-type Registration for 11.4.1. MIME Content-type Registration for
'application/EmergencyCallData.ProviderInfo+xml' . . 72 'application/EmergencyCallData.ProviderInfo+xml' . . 72
11.4.2. MIME Content-type Registration for 11.4.2. MIME Content-type Registration for
'application/EmergencyCallData.ServiceInfo+xml' . . 73 'application/EmergencyCallData.ServiceInfo+xml' . . 73
11.4.3. MIME Content-type Registration for 11.4.3. MIME Content-type Registration for
'application/EmergencyCallData.DeviceInfo+xml' . . . 74 'application/EmergencyCallData.DeviceInfo+xml' . . . 75
11.4.4. MIME Content-type Registration for 11.4.4. MIME Content-type Registration for
'application/EmergencyCallData.SubscriberInfo+xml' . 75 'application/EmergencyCallData.SubscriberInfo+xml' . 76
11.4.5. MIME Content-type Registration for 11.4.5. MIME Content-type Registration for
'application/EmergencyCallData.Comment+xml' . . . . 76 'application/EmergencyCallData.Comment+xml' . . . . 77
11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 77 11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 78
11.5.1. Registration for 11.5.1. Registration for
urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 77 urn:ietf:params:xml:ns:EmergencyCallData . . . . . . 78
11.5.2. Registration for 11.5.2. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf urn:ietf:params:xml:ns:EmergencyCallData:ProviderInf
o . . . . . . . . . . . . . . . . . . . . . . . . . 78 o . . . . . . . . . . . . . . . . . . . . . . . . . 79
11.5.3. Registration for 11.5.3. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 79 urn:ietf:params:xml:ns:EmergencyCallData:ServiceInfo 79
11.5.4. Registration for 11.5.4. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 80 urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo 80
11.5.5. Registration for 11.5.5. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI urn:ietf:params:xml:ns:EmergencyCallData:SubscriberI
nfo . . . . . . . . . . . . . . . . . . . . . . . . 81 nfo . . . . . . . . . . . . . . . . . . . . . . . . 81
11.5.6. Registration for 11.5.6. Registration for
urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 82 urn:ietf:params:xml:ns:EmergencyCallData:Comment . . 82
11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 83 11.6. Schema Registrations . . . . . . . . . . . . . . . . . . 83
skipping to change at page 4, line 48 skipping to change at page 4, line 48
When an IP-based emergency call is initiated, a rich set of data from When an IP-based emergency call is initiated, a rich set of data from
multiple data sources is conveyed to the Public Safety Answering multiple data sources is conveyed to the Public Safety Answering
Point (PSAP). This data includes information about the calling party Point (PSAP). This data includes information about the calling party
identity, the multimedia capabilities of the device, the request for identity, the multimedia capabilities of the device, the request for
emergency services, location information, and meta-data about the emergency services, location information, and meta-data about the
sources of the data. In addition, the device, the access network sources of the data. In addition, the device, the access network
provider, and any service provider in the call path has even more provider, and any service provider in the call path has even more
information that is useful for a PSAP when handling an emergency. information that is useful for a PSAP when handling an emergency.
This document extends the basic set of data communicated with an IP- This document extends the basic set of data communicated with a
based emergency call, as described in [RFC6443] and [RFC6881], in Session Initiation Protocol (SIP) based emergency call, as described
order to carry additional data which is useful to an entity or call in [RFC6443] and [RFC6881], in order to carry additional data which
taker handling the call. This data is "additional" to the basic is useful to an entity or call taker handling the call. This data is
information found in the emergency call signaling used. The intent "additional" to the basic information found in the emergency call
is that every emergency call carry as much as possible of the signaling used. The intent is that every emergency call carry as
information described here using the mechanisms described here. much as possible of the information described here using the
mechanisms described here.
This document defines three categories of this additional data that This document defines three categories of this additional data that
can be transmitted with an emergency call: can be transmitted with an emergency call:
Data Associated with a Location: Primary location data is conveyed Data Associated with a Location: Primary location data is conveyed
in the Presence Information Data Format Location Object (PIDF-LO) in the Presence Information Data Format Location Object (PIDF-LO)
data structure as defined in RFC 4119 [RFC4119] and extended by data structure as defined in RFC 4119 [RFC4119] and extended by
RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location RFC 5139 [RFC5139] and RFC 6848 [RFC6848] (for civic location
information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for information), RFC 5491 [RFC5491] and RFC 5962 [RFC5962] (for
geodetic location information), and [RFC7035] (for relative geodetic location information), and [RFC7035] (for relative
skipping to change at page 7, line 36 skipping to change at page 7, line 36
immediately applicable. For this reason, an XML-based encoding of immediately applicable. For this reason, an XML-based encoding of
the information elements defined in the vCard specification has been the information elements defined in the vCard specification has been
defined and the name of that specification is xCard [RFC6351]. Since defined and the name of that specification is xCard [RFC6351]. Since
the term vCard is more familiar to most readers, we use the terms the term vCard is more familiar to most readers, we use the terms
xCard and vCard interchangeably. xCard and vCard interchangeably.
3. Document Scope 3. Document Scope
The scope of this document is explicitly limited to emergency calls. The scope of this document is explicitly limited to emergency calls.
The data structures defined here are not appropriate to be conveyed The data structures defined here are not appropriate to be conveyed
with non-emergency calls because they carry sensitive and private in non-emergency calls because they carry sensitive and private data.
data. However, in certain private-use situations (such as However, in certain private-use situations between a specialized
communications between a telematics or other service provider and service provider (such as a vehicle telematics service provider) and
dedicated equipment such as in a vehicle) where the endpoints have a dedicated equipment (such as in a vehicle) where the endpoints have a
preexisting relationship and privacy issues are addressed within the preexisting relationship and privacy issues are addressed within the
relationship, the mechanisms and data structures defined here can be relationship, the mechanisms and data structures defined here can be
used. used with communications within the limited context of the
preexisting relationship.
4. Data Structures 4. Data Structures
This section defines the following five data structures, each as a This section defines the following five data structures, each as a
data block. For each block we define the MIME media type, and the data block. For each block we define the MIME media type, and the
XML encoding. The five data structures are: XML encoding. The five data structures are:
'Data Provider': This block supplies name and contact information 'Data Provider': This block supplies name and contact information
for the entity that created the data. Section 4.1 provides the for the entity that created the data. Section 4.1 provides the
details. details.
skipping to change at page 12, line 40 skipping to change at page 12, line 40
4.1.5. Data Provider Contact URI 4.1.5. Data Provider Contact URI
Data Element: Data Provider Contact URI Data Element: Data Provider Contact URI
Use: Required Use: Required
XML Element: <ContactURI> XML Element: <ContactURI>
Description: When provided by a service provider or an access Description: When provided by a service provider or an access
network provider, this information MUST be a URI to a 24/7 support network provider, this information is expected to be a URI to a
organization tasked to provide PSAP support for this emergency 24/7 support organization tasked to provide PSAP support for this
call. When provided by a device, this MUST be the contact emergency call. When provided by a device, this MUST be the
information of the user or owner of the device. (Ideally, this is contact information of the user or owner of the device. (Ideally,
the contact information of the device user, but when the owner and this is the contact information of the device user, but when the
user are separate (e.g., the device owner is an organization), owner and user are separate (e.g., the device owner is an
this MAY be the contact information of the owner.) The Data organization), this MAY be the contact information of the owner.)
Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format The Data Provider Contact URI SHOULD be a TEL URI [RFC3966] in
fully specified with country code. If a TEL URI is not available, E.164 format fully specified with country code. If a TEL URI is
a generic SIP URI is acceptable. Note that this contact not available, a generic SIP URI is acceptable. Note that this
information is not used by PSAPs for callbacks (a call from a PSAP contact information is not used by PSAPs for callbacks (a call
directly related to a recently terminated emergency call, placed from a PSAP directly related to a recently terminated emergency
by the PSAP using a SIP Priority header field set to "psap- call, placed by the PSAP using a SIP Priority header field set to
callback", as described in [RFC7090]). "psap-callback", as described in [RFC7090]).
Reason for Need: Additional data providers might need to be Reason for Need: Additional data providers might need to be
contacted in error cases or other unusual circumstances. contacted in error cases or other unusual circumstances.
How Used by Call Taker: To contact the supplier of the additional How Used by Call Taker: To contact the supplier of the additional
data for assistance in handling the call. data for assistance in handling the call.
4.1.6. Data Provider Languages(s) Supported 4.1.6. Data Provider Languages(s) Supported
Data Element: Data Provider Language(s) supported Data Element: Data Provider Language(s) supported
skipping to change at page 17, line 49 skipping to change at page 17, line 49
</vcard> </vcard>
</ad:DataProviderContact> </ad:DataProviderContact>
</ad:EmergencyCallData.ProviderInfo> </ad:EmergencyCallData.ProviderInfo>
Figure 3: EmergencyCallData.ProviderInfo Example. Figure 3: EmergencyCallData.ProviderInfo Example.
4.2. Service Information 4.2. Service Information
This block describes the service that the service provider provides This block describes the service that the service provider provides
to the caller. It SHOULD be included by all service providers in the to the caller. It SHOULD be included by all service providers in the
path of the call. The mime media type is "application/ path of the call. The MIME media type is "application/
EmergencyCallData.ServiceInfo+xml". EmergencyCallData.ServiceInfo+xml".
4.2.1. Service Environment 4.2.1. Service Environment
Data Element: Service Environment Data Element: Service Environment
Use: Conditional: Required unless the 'ServiceType' value is Use: Conditional: Required unless the 'ServiceType' value is
'wireless'. 'wireless'.
XML Element: <ServiceEnvironment> XML Element: <ServiceEnvironment>
skipping to change at page 22, line 20 skipping to change at page 22, line 20
<svc:ServiceType>MLTS-hosted</svc:ServiceType> <svc:ServiceType>MLTS-hosted</svc:ServiceType>
<svc:ServiceMobility>Fixed</svc:ServiceMobility> <svc:ServiceMobility>Fixed</svc:ServiceMobility>
</svc:EmergencyCallData.ServiceInfo> </svc:EmergencyCallData.ServiceInfo>
Figure 7: EmergencyCallData.ServiceInfo Example. Figure 7: EmergencyCallData.ServiceInfo Example.
4.3. Device Information 4.3. Device Information
This block provides information about the device used to place the This block provides information about the device used to place the
call. It SHOULD be provided by any service provider that knows what call. It SHOULD be provided by any service provider that knows what
device is being used, and by the device itself. The mime media type device is being used, and by the device itself. The MIME media type
is "application/EmergencyCallData.DeviceInfo+xml". is "application/EmergencyCallData.DeviceInfo+xml".
4.3.1. Device Classification 4.3.1. Device Classification
Data Element: Device Classification Data Element: Device Classification
Use: Optional Use: Optional
XML Element: <DeviceClassification> XML Element: <DeviceClassification>
skipping to change at page 31, line 24 skipping to change at page 31, line 24
</sub:SubscriberData> </sub:SubscriberData>
</sub:EmergencyCallData.SubscriberInfo> </sub:EmergencyCallData.SubscriberInfo>
Figure 12: EmergencyCallData.SubscriberInfo Example. Figure 12: EmergencyCallData.SubscriberInfo Example.
4.5. Comment 4.5. Comment
This block provides a mechanism for the data provider to supply This block provides a mechanism for the data provider to supply
extra, human readable information to the PSAP. It is not intended extra, human readable information to the PSAP. It is not intended
for a general purpose extension mechanism nor does it aim to provide for a general purpose extension mechanism nor does it aim to provide
machine-readable content. The mime media type is "application/ machine-readable content. The MIME media type is "application/
EmergencyCallData.Comment+xml" EmergencyCallData.Comment+xml"
4.5.1. Comment 4.5.1. Comment
Data Element: EmergencyCallData.Comment Data Element: EmergencyCallData.Comment
Use: Optional Use: Optional
XML Element: <Comment> XML Element: <Comment>
skipping to change at page 34, line 9 skipping to change at page 34, line 9
also indicates the kind of data (by its MIME media subtype) that also indicates the kind of data (by its MIME media subtype) that
is available at the URI. is available at the URI.
As the data is conveyed using a URI in the SIP signaling, the As the data is conveyed using a URI in the SIP signaling, the
data itself can reside on an external resource, or can be data itself can reside on an external resource, or can be
contained within the body of the SIP message. When the URI contained within the body of the SIP message. When the URI
refers to data at an external resource, the data is said to be refers to data at an external resource, the data is said to be
passed by reference. When the URI refers to data contained passed by reference. When the URI refers to data contained
within the body of the SIP message, the data is said to be passed within the body of the SIP message, the data is said to be passed
by value. A PSAP or emergency responder is able to examine the by value. A PSAP or emergency responder is able to examine the
type of data provided and selectively inspect the data it is type of data provided and selectively access the data it is
interested in, while forwarding all of it (the values or interested in, while forwarding all of it (the values or
references) to downstream entities. references) to downstream entities.
To be conveyed in a SIP body, additional data about a call is To be conveyed in a SIP body, additional data about a call is
defined as a series of MIME objects (also referred to as a defined as a series of MIME objects (also referred to as a
"block" of data). Each block defined in this document is an XML "block" of data). Each block defined in this document is an XML
data structure identified by its MIME media type. (Blocks data structure identified by its MIME media type. (Blocks
defined by others can be encoded in XML or not, as identified by defined by others can be encoded in XML or not, as identified by
their MIME registration.) As usual, whenever more than one MIME their MIME registration.) As usual, whenever more than one MIME
part is included in the body of a message, MIME multipart (i.e., part is included in the body of a message, MIME multipart (i.e.,
skipping to change at page 35, line 30 skipping to change at page 35, line 30
included or referenced in the SIP signaling (using the Call-Info included or referenced in the SIP signaling (using the Call-Info
header field) or in the <provided-by> element of a PIDF-LO. For header field) or in the <provided-by> element of a PIDF-LO. For
interoperability, only blocks in the registry are permitted to be interoperability, only blocks in the registry are permitted to be
sent using the mechanisms specified in this document. Since multiple sent using the mechanisms specified in this document. Since multiple
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
example, a block (provided by value or by reference) might not be the
type indicated by the "purpose" parameter, or might be badly formed,
etc. The general principle that applies to emergency calls is that
it is more important for the call to go through than for for
everything to be correct. Thus, most PSAPs will process a call if at
all 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
type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose'
skipping to change at page 67, line 13 skipping to change at page 67, line 13
control policies are available for distinguishing the different control policies are available for distinguishing the different
entities dereferencing the reference. Without access control entities dereferencing the reference. Without access control
policies any party in possession of the reference is able to resolve policies any party in possession of the reference is able to resolve
the reference and to obtain the data, including intermediaries. the reference and to obtain the data, including intermediaries.
11. IANA Considerations 11. IANA Considerations
11.1. Registry creation 11.1. Registry creation
This document creates a new registry called 'Emergency Call This document creates a new registry called 'Emergency Call
Additional Data'. The following sub-registries are created for this Additional Data' with a number of sub-registries.
registry.
For several of the sub-registries, "Expert Review" is the criteria
for adding new entries. As discussed in Section 5, it can be
counterproductive to register new types of data, and as discussed in
Section 10, data sent as part of an emergency call can be very
privacy-sensitive. In some cases, it is anticipated that various
standards bodies dealing with emergency services might need to
register new values, and in those cases text below advises the
designed expert to verify that the entity requesting the registration
is relevant (e.g., a recognized emergency services related SDO). In
other cases, especially those where the trade-off between the
potential benefit versus danger of new registrations is more
conservative (such as Section 11.1.9), "Specification Required" is
the criteria, which is a higher hurdle and also implicitly includes
an expert review.
The following sub-registries are created for this registry.
11.1.1. Provider ID Series Registry 11.1.1. Provider ID Series Registry
This document creates a new sub-registry called "Provider ID Series". This document creates a new sub-registry called "Provider ID Series".
As defined in [RFC5226], this registry operates under "Expert Review" As defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should determine that the entity requesting a new rules. The expert should determine that the entity requesting a new
value is a legitimate issuer of service provider IDs suitable for use value is a legitimate issuer of service provider IDs suitable for use
in Additional Call Data. in Additional Call Data.
Private entities issuing or using internally-generated IDs are Private entities issuing or using internally-generated IDs are
skipping to change at page 112, line 10 skipping to change at page 112, line 10
Note to RFC Editor: After IANA has published the schemas, the above Note to RFC Editor: After IANA has published the schemas, the above
link to the schemas should be replaced with [IANA-XML-Schemas]. link to the schemas should be replaced with [IANA-XML-Schemas].
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
US US
Email: rg+ietf@qti.qualcomm.com Email: rg+ietf@randy.pensive.org
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 26 change blocks. 
49 lines changed or deleted 75 lines changed or added

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