< draft-ietf-ecrit-additional-data-33.txt   draft-ietf-ecrit-additional-data-34.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 20, 2016 NeuStar Expires: February 27, 2016 NeuStar
H. Tschofenig H. Tschofenig
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
J. Winterbottom J. Winterbottom
July 19, 2015 August 26, 2015
Additional Data Related to an Emergency Call Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-33.txt draft-ietf-ecrit-additional-data-34.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 20, 2016. This Internet-Draft will expire on February 27, 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 2, line 49 skipping to change at page 2, line 49
4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17 4.2.1. Service Environment . . . . . . . . . . . . . . . . . 17
4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Service Type . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Service Mobility Environment . . . . . . . . . . . . 20 4.2.3. Service Mobility Environment . . . . . . . . . . . . 20
4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21 4.2.4. EmergencyCallData.ServiceInfo Example . . . . . . . . 21
4.3. Device Information . . . . . . . . . . . . . . . . . . . 22 4.3. Device Information . . . . . . . . . . . . . . . . . . . 22
4.3.1. Device Classification . . . . . . . . . . . . . . . . 22 4.3.1. Device Classification . . . . . . . . . . . . . . . . 22
4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23 4.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 23
4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24 4.3.3. Device Model Number . . . . . . . . . . . . . . . . . 24
4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24 4.3.4. Unique Device Identifier . . . . . . . . . . . . . . 24
4.3.5. Device/Service-Specific Additional Data Structure . . 25 4.3.5. Device/Service-Specific Additional Data Structure . . 25
4.3.6. Device/Service Specific Additional Data Structure 4.3.6. Device/Service-Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 26 Type . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7. Issues with getting new types of data into use . . . 26 4.3.7. Issues with getting new types of data into use . . . 26
4.3.8. Choosing between defining a new type of block or new 4.3.8. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 27 type of device/service specific additional data . . . 27
4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28 4.3.9. EmergencyCallData.DeviceInfo Example . . . . . . . . 28
4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28 4.4. Owner/Subscriber Information . . . . . . . . . . . . . . 28
4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28 4.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 28
4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29 4.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 29
4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 30 4.4.3. EmergencyCallData.SubscriberInfo Example . . . . . . 30
4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32 4.5.2. EmergencyCallData.Comment Example . . . . . . . . . . 32
5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33 5. Data Transport Mechanisms . . . . . . . . . . . . . . . . . . 33
5.1. Transmitting Blocks using the Call-Info Header . . . . . 34 5.1. Transmitting Blocks using Call-Info . . . . . . . . . . . 34
5.2. Transmitting Blocks by Reference using the <provided-by> 5.2. Transmitting Blocks by Reference using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 36 Element . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Transmitting Blocks by Value using the <provided-by> 5.3. Transmitting Blocks by Value using the <provided-by>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 37 Element . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38 5.4. The Content-Disposition Parameter . . . . . . . . . . . . 38
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52 7. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52 7.1. EmergencyCallData.ProviderInfo XML Schema . . . . . . . . 52
7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54 7.2. EmergencyCallData.ServiceInfo XML Schema . . . . . . . . 54
7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55 7.3. EmergencyCallData.DeviceInfo XML Schema . . . . . . . . . 55
skipping to change at page 9, line 30 skipping to change at page 9, line 30
Data Element: Data Provider String Data Element: Data Provider String
Use: Conditional. Optional for blocks supplied by the originating Use: Conditional. Optional for blocks supplied by the originating
device, mandatory otherwise. device, mandatory otherwise.
XML Element: <DataProviderString> XML Element: <DataProviderString>
Description: This is a plain text string suitable for displaying the Description: This is a plain text string suitable for displaying the
name of the service provider that supplied the data structure. If name of the service provider that supplied the data structure. If
the device creates the structure, it SHOULD use the value of the the device creates the structure, it SHOULD use the value of the
contact header in the SIP INVITE. contact header field in the SIP INVITE.
Reason for Need: Inform the call taker of the identity of the entity Reason for Need: Inform the call taker of the identity of the entity
providing the data. providing the data.
How Used by Call Taker: Allows the call taker to interpret the data How Used by Call Taker: Allows the call taker to interpret the data
in this structure. The source of the information often influences in this structure. The source of the information often influences
how the information is used, believed or verified. how the information is used, believed or verified.
4.1.2. Data Provider ID 4.1.2. Data Provider ID
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Reason for Need: Provides device/service specific data that may be Reason for Need: Provides device/service specific data that may be
used by the call taker and/or responders. used by the call taker and/or responders.
How Used by Call Taker: Provide information to guide call takers to How Used by Call Taker: Provide information to guide call takers to
select appropriate responders, give appropriate pre-arrival select appropriate responders, give appropriate pre-arrival
instructions to callers, and advise responders of what to be instructions to callers, and advise responders of what to be
prepared for. May be used by responders to guide assistance prepared for. May be used by responders to guide assistance
provided. provided.
4.3.6. Device/Service Specific Additional Data Structure Type 4.3.6. Device/Service-Specific Additional Data Structure Type
Data Element: Type of device/service-specific additional data Data Element: Type of device/service-specific additional data
structure structure
Use: Conditional. MUST be provided when device/service specific- Use: Conditional. MUST be provided when device/service specific-
additional URI is provided additional URI is provided
XML Element: <DeviceSpecificType> XML Element: <DeviceSpecificType>
Description: A value from the registry defined in Section 10.1.8 to Description: A value from the registry defined in Section 10.1.8 to
skipping to change at page 33, line 13 skipping to change at page 33, line 13
Figure 13: EmergencyCallData.Comment Example. Figure 13: EmergencyCallData.Comment Example.
5. Data Transport Mechanisms 5. Data Transport Mechanisms
This section defines how to convey additional data to an emergency This section defines how to convey additional data to an emergency
service provider. Two different means are specified: the first uses service provider. Two different means are specified: the first uses
the call signaling; the second uses the <provided-by> element of a the call signaling; the second uses the <provided-by> element of a
PIDF-LO [RFC4119]. PIDF-LO [RFC4119].
1. First, the ability to embed a Uniform Resource Identifier (URI) 1. First, the ability to embed a Uniform Resource Identifier (URI)
in an existing SIP header field, the Call-Info header, is in an existing SIP header field, the Call-Info header field, 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 field is specified in Section 20.9 of [RFC3261].
document adds a new compound token starting with the value This 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 field contains
HTTPS URL pointing to an external resource or a CID (content either an HTTPS URL pointing to an external resource or a CID
indirection) URI that allows the data structure to be placed in (content indirection) URI that allows the data structure to be
the body of the SIP message. The "purpose" parameter also placed in the body of the SIP message. The "purpose" parameter
indicates the kind of data (by its MIME subtype) that is also indicates the kind of data (by its MIME subtype) that is
available at the URI. As the data is conveyed using a URI in the available at the URI. As the data is conveyed using a URI in the
SIP signaling, the data itself may reside on an external SIP signaling, the data itself may reside on an external
resource, or may be contained within the body of the SIP message. resource, or may be contained within the body of the SIP message.
When the URI refers to data at an external resource, the data is When the URI refers to data at an external resource, the data is
said to be passed by reference. When the URI refers to data said to be passed by reference. When the URI refers to data
contained within the body of the SIP message, the data is said to contained within the body of the SIP message, the data is said to
be passed by value. A PSAP or emergency responder is able to be passed by value. A PSAP or emergency responder is able to
examine the type of data provided and selectively inspect the examine the type of data provided and selectively inspect the
data it is interested in, while forwarding all of it (the values data it is interested in, while forwarding all of it (the values
or references) to downstream entities. To be conveyed in a SIP or references) to downstream entities. To be conveyed in a SIP
skipping to change at page 34, line 47 skipping to change at page 34, line 47
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.
5.1. Transmitting Blocks using the Call-Info Header 5.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 subtype (the is denoted by including the root of the MIME 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 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 field 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
Request-URI header of a SIP message), test emergency calls (using an Request-URI header field of a SIP message), test emergency calls
appropriate service URN), and some private-use calls where the (using an appropriate service URN), and some private-use calls where
endpoints have a preexisting relationship and privacy concerns do not the endpoints have a preexisting relationship and privacy concerns do
apply because of the relationship; use in other contexts is undefined not apply because of the relationship; use in other contexts is
and is likely to unnecessarily expose confidential data. undefined and is likely to unnecessarily expose confidential data.
If the data is provided by reference, an HTTPS URI MUST be included If the data is provided by reference, an HTTPS URI MUST be included
and consequently Transport Layer Security (TLS) protection is applied and consequently Transport Layer Security (TLS) protection is applied
for protecting the retrieval of the information. for protecting the retrieval of the information.
The data may also be supplied by value in any SIP request or response The data may also be supplied by value in any SIP request or response
method that is permitted to contain a body (i.e., not a BYE request). method that is permitted to contain a body (i.e., not a BYE request).
In this case, Content Indirection (CID) [RFC2392] is used, with the In this case, Content Indirection (CID) [RFC2392] is used, with the
CID URL referencing the MIME body part containing the data. Note CID URL referencing the MIME body part containing the data. Note
that [RFC3261] forbids proxies from altering message bodies, so that [RFC3261] forbids proxies from altering message bodies, so
entities in the call path that add blocks by value need to do so entities in the call path that add blocks by value need to do so
using an appropriate SIP entity (e.g., a back-to-back user agent). using an appropriate SIP entity (e.g., a back-to-back user agent).
Transmitting data by value is especially useful in certain cases, Transmitting data by value is especially useful in certain cases,
such as when the data exists in or is generated by the originating such as when the data exists in or is generated by the originating
device, but is not intended for very large data blocks. Additional device, but is not intended for very large data blocks. Additional
security and privacy considerations apply to data transmitted by security and privacy considerations apply to data transmitted by
value, as discussed in Section 8 and Section 9. value, as discussed in Section 8 and Section 9.
More than one Call-Info header with a purpose value starting with More than one Call-Info header field with a purpose value starting
'EmergencyCallData' can be expected, but at least one MUST be with 'EmergencyCallData' can be expected, but at least one MUST be
provided. The device MUST provide one if it knows no service provided. The device MUST provide one if it knows no service
provider is in the path of the call. The device MAY insert one if it provider is in the path of the call. The device MAY insert one if it
uses a service provider. Any service provider in the path of the uses a service provider. Any service provider in the path of the
call MUST insert its own. For example, a device, a telematics call MUST insert its own. For example, a device, a telematics
service provider in the call path, as well as the mobile carrier service provider in the call path, as well as the mobile carrier
handling the call will each provide one. There may be circumstances handling the call will each provide one. There may be circumstances
where there is a service provider who is unaware that the call is an where there is a service provider who is unaware that the call is an
emergency call and cannot reasonably be expected to determine that it emergency call and cannot reasonably be expected to determine that it
is an emergency call. In that case, that service provider is not is an emergency call. In that case, that service provider is not
expected to provide EmergencyCallData. expected to provide EmergencyCallData.
skipping to change at page 39, line 16 skipping to change at page 39, line 16
RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling'
parameter for the Content-Disposition header field. These RFCs parameter for the Content-Disposition header field. These RFCs
describe how a UAS reacts if it receives a message body whose content describe how a UAS reacts if it receives a message body whose content
type or disposition type it does not understand. If the 'handling' type or disposition type it does not understand. If the 'handling'
parameter has the value "optional", the UAS ignores the message body. parameter has the value "optional", the UAS ignores the message body.
If the 'handling' parameter has the value "required", the UAS returns If the 'handling' parameter has the value "required", the UAS returns
a 415 (Unsupported Media Type) response. The 'by-reference' a 415 (Unsupported Media Type) response. The 'by-reference'
disposition type allows a SIP message to contain a reference to the disposition type allows a SIP message to contain a reference to the
body part, and the SIP UA processes the body part according to the body part, and the SIP UA processes the body part according to the
reference. This is the case for the Call-info header containing a reference. This is the case for a Call-info header field containing
Content Indirection (CID) URL. a Content Indirection (CID) URL.
As an example, a SIP message indicates the Content-Disposition As an example, a SIP message indicates the Content-Disposition
parameter in the body of the SIP message as shown in Figure 14. parameter in the body of the SIP message as shown in Figure 14.
Content-Type: application/sdp Content-Type: application/sdp
...Omit Content-Disposition here; defaults are ok ...Omit Content-Disposition here; defaults are ok
...SDP goes in here ...SDP goes in here
--boundary1 --boundary1
skipping to change at page 66, line 17 skipping to change at page 66, line 17
10. IANA Considerations 10. IANA Considerations
10.1. Registry creation 10.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'. The following sub-registries are created for this
registry. registry.
10.1.1. Provider ID Series Registry 10.1.1. Provider ID Series Registry
This document creates a new sub-registry called "Additional Call Data This document creates a new sub-registry called "Provider ID Series".
Provider ID Series". As defined in [RFC5226], this registry operates As defined in [RFC5226], this registry operates under "Expert Review"
under "Expert Review" rules. The expert should determine that the rules. The expert should determine that the entity requesting a new
entity requesting a new value is a legitimate issuer of service value is a legitimate issuer of service provider IDs suitable for use
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
encouraged to register here and to ensure that all IDs they issue or encouraged to register here and to ensure that all IDs they issue or
use are unique. This guarantees that IDs issued or used by the use are unique. This guarantees that IDs issued or used by the
entity are globally unique and distinguishable from other IDs issued entity are globally unique and distinguishable from other IDs issued
or used by the same or a different entity. (Some organizations, such or used by the same or a different entity. (Some organizations, such
as NENA, issue IDs that are unique among all IDs they issue, so an as NENA, issue IDs that are unique among all IDs they issue, so an
entity using a combination of its NENA ID and the fact that it is entity using a combination of its NENA ID and the fact that it is
from NENA is globally unique. Other entities might not have an ID from NENA is globally unique. Other entities might not have an ID
issued by an organization such as NENA, so they are permitted to use issued by an organization such as NENA, so they are permitted to use
skipping to change at page 66, line 46 skipping to change at page 66, line 46
Name: An identifier to be used in the 'ProviderIDSeries' element. Name: An identifier to be used in the 'ProviderIDSeries' element.
Source: The full name of the organization issuing the identifiers. Source: The full name of the organization issuing the identifiers.
URL: A URL to the organization for further information. URL: A URL to the organization for further information.
The initial set of values is listed in Figure 1. The initial set of values is listed in Figure 1.
10.1.2. Service Environment Registry 10.1.2. Service Environment Registry
This document creates a new sub-registry called 'Additional Call This document creates a new sub-registry called "Service
Service Environment'. As defined in [RFC5226], this registry Environment". As defined in [RFC5226], this registry operates under
operates under "Expert Review" rules. The expert should determine "Expert Review" rules. The expert should determine that the entity
that the entity requesting a new value is relevant for this service requesting a new value is relevant for this service element, and that
element, and that the new value is distinct from existing values, and the new value is distinct from existing values, and its use is
its use is unambiguous. unambiguous.
The content of this registry includes: The content of this registry includes:
Token: The value to be used in the <ServiceEnvironment> element. Token: The value to be used in the <ServiceEnvironment> element.
Description: A short description of the value. Description: A short description of the value.
The initial set of values is listed in Figure 4. The initial set of values is listed in Figure 4.
10.1.3. Service Type Registry 10.1.3. Service Type Registry
This document creates a new sub-registry called 'Additional Call This document creates a new sub-registry called "Service Type". As
Service Type'. As defined in [RFC5226], this registry operates under defined in [RFC5226], this registry operates under "Expert Review"
"Expert Review" rules. The expert should determine that the entity rules. The expert should determine that the entity requesting a new
requesting a new value is relevant for this service element and that value is relevant for this service element and that the requested
the requested value is clearly distinct from other values so that value is clearly distinct from other values so that there is no
there is no ambiguity as to when the value is to be used or which ambiguity as to when the value is to be used or which value is to be
value is to be used. used.
The content of this registry includes: The content of this registry includes:
Name: The value to be used in the <ServiceType> element. Name: The value to be used in the <ServiceType> element.
Description: A short description of the value. Description: A short description of the value.
The initial set of values is listed in Figure 5. The initial set of values is listed in Figure 5.
10.1.4. Service Mobility Registry 10.1.4. Service Mobility Registry
This document creates a new sub-registry called 'Additional Call This document creates a new sub-registry called "Service Mobility".
Service Mobility'. As defined in [RFC5226], this registry operates As defined in [RFC5226], this registry operates under "Expert Review"
under "Expert Review" rules. The expert should determine that the rules. The expert should determine that the entity requesting a new
entity requesting a new value is relevant for this service element value is relevant for this service element and that the requested
and that the requested value is clearly distinct from other values so value is clearly distinct from other values so that there is no
that there is no ambiguity as to when the value is to be used or ambiguity as to when the value is to be used or which value is to be
which value is to be used. used.
The content of this registry includes: The content of this registry includes:
Token: The value used in the <ServiceMobility> element. Token: The value used in the <ServiceMobility> element.
Description: A short description of the value. Description: A short description of the value.
The initial set of values is listed in Figure 6. The initial set of values is listed in Figure 6.
10.1.5. Service Provider Type Registry 10.1.5. Service Provider Type Registry
This document creates a new sub-registry called 'Service Provider This document creates a new sub-registry called "Service Provider
Type'. As defined in [RFC5226], this registry operates under "Expert Type". As defined in [RFC5226], this registry operates under "Expert
Review". The expert should determine that the proposed new value is Review". The expert should determine that the proposed new value is
distinct from existing values and appropriate for use in the distinct from existing values and appropriate for use in the
<TypeOfServicerProvider> element <TypeOfServicerProvider> element
The content of this registry includes: The content of this registry includes:
Token: The value used in the <TypeOfProvider> element. Token: The value used in the <TypeOfProvider> element.
Description: A short description of the type of service provider. Description: A short description of the type of service provider.
skipping to change at page 68, line 39 skipping to change at page 68, line 39
The content of this registry includes: The content of this registry includes:
Token: Value used in the <DeviceClassification> element. Token: Value used in the <DeviceClassification> element.
Description: Short description identifying the device type. Description: Short description identifying the device type.
The initial set of values are defined in Figure 8. The initial set of values are defined in Figure 8.
10.1.7. Device ID Type Type Registry 10.1.7. Device ID Type Type Registry
This document creates a new sub-registry called 'Additional Call Data This document creates a new sub-registry called "Device ID Type". As
Device ID Type'. As defined in [RFC5226], this registry operates defined in [RFC5226], this registry operates under "Expert Review"
under "Expert Review" rules. The expert should ascertain that the rules. The expert should ascertain that the proposed type is well
proposed type is well understood, and provides information which understood, and provides information which PSAPs and responders are
PSAPs and responders are able to use to uniquely identify a device. able to use to uniquely identify a device. (For example, a biometric
(For example, a biometric fingerprint used to authenticate a device fingerprint used to authenticate a device would not normally be
would not normally be useful by a PSAP or responder to identify a useful by a PSAP or responder to identify a device.)
device.)
The content of this registry includes: The content of this registry includes:
Token: The value to be placed in the <TypeOfDeviceID> element. Token: The value to be placed in the <TypeOfDeviceID> element.
Description: Short description identifying the type of the device Description: Short description identifying the type of the device
ID. ID.
The initial set of values are defined in Figure 9. The initial set of values are defined in Figure 9.
10.1.8. Device/Service Data Type Registry 10.1.8. Device/Service Data Type Registry
This document creates a new sub-registry called 'Device/Service Data This document creates a new sub-registry called "Device/Service Data
Type Registry'. As defined in [RFC5226], this registry operates Type". As defined in [RFC5226], this registry operates under
under "Specification Required" rules, which include an explicit "Specification Required" rules, which include an explicit expert
expert review. The designated expert should ascertain that the review. The designated expert should ascertain that the proposed
proposed type is well understood, and provides information useful to type is well understood, and provides information useful to PSAPs and
PSAPs and responders. The specification must contain a complete responders. The specification must contain a complete description of
description of the data, and a precise format specification suitable the data, and a precise format specification suitable to allow
to allow interoperable implementations. interoperable implementations.
The content of this registry includes: The content of this registry includes:
Token: The value to be placed in the <DeviceSpecificType> element. Token: The value to be placed in the <DeviceSpecificType> element.
Description: Short description identifying the data. Description: Short description identifying the data.
Specification: Citation for the specification of the data. Specification: Citation for the specification of the data.
The initial set of values are listed in Figure 10. The initial set of values are listed in Figure 10.
10.1.9. Emergency Call Data Types Registry 10.1.9. Emergency Call Data Types Registry
This document creates a new sub-registry called 'Emergency Call Data This document creates a new sub-registry called 'Emergency Call Data
Types' in the 'purpose' registry established by RFC 3261 [RFC3261]. Types'. As defined in [RFC5226], this registry operates under
As defined in [RFC5226], this registry operates under "Specification "Specification Required" rules, which include an explicit expert
Required" rules, which include an explicit expert review. The expert review. The expert is responsible for verifying that the document
is responsible for verifying that the document contains a complete contains a complete and clear specification and the proposed
and clear specification and the proposed functionality does not functionality does not obviously duplicate existing functionality.
obviously duplicate existing functionality. The expert is also The expert is also responsible for verifying that the block is
responsible for verifying that the block is correctly categorized per correctly categorized per the description of the categories in
the description of the categories in Section 1. 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 field as specified in
document. The subtype MAY exist under any MIME media type (although this document. The subtype MAY exist under any MIME media type
most commonly these are under 'Application/' this is NOT REQUIRED), (although most commonly these are under 'Application/' this is NOT
however, to be added to the registry the "root" needs to be unique REQUIRED), however, to be added to the registry the "root" needs to
regardless of the MIME media type. be unique 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: A hint as to if the block is considered descriptive of Data About: A hint as to if the block is considered descriptive of
the call, the caller, or the location (or is applicable to more the call, the caller, or the location (or is applicable to more
than one), which may help PSAPs and other entities determine if than one), which may help PSAPs and other entities determine if
they wish to process the block. Note that this is only a hint; they wish to process the block. Note that this is only a hint;
skipping to change at page 70, line 25 skipping to change at page 70, line 23
field, when determining if they wish to process the block (which field, when determining if they wish to process the block (which
is why the field only exists in the registry, and is not contained is why the field only exists in the registry, and is not contained
within the block). The value MUST be either "The Call", "The within the block). The value MUST be either "The Call", "The
Caller", "The Location", or "Multiple". New values are created by Caller", "The Location", or "Multiple". New values are created by
extending this registry in a subsequent RFC. extending this registry in a subsequent RFC.
Reference: The document that describes the data object Reference: The document that describes the data object
Note that the tokens in this registry are part of the Note that the tokens in this registry are part of the
'EmergencyCallData' compound value; when used as a value of the 'EmergencyCallData' compound value; when used as a value of the
'purpose' parameter of the Call-Info header, the values listed in 'purpose' parameter of a Call-Info header field, the values listed in
this registry are prefixed by 'EmergencyCallData.' per the this registry are prefixed by 'EmergencyCallData.' per the
'EmergencyCallData' registation Section 10.2. 'EmergencyCallData' registation Section 10.2.
The initial set of values are listed in Figure 25. The initial set of values are listed in Figure 25.
+----------------+--------------+------------+ +----------------+--------------+------------+
| Token | Data About | Reference | | Token | Data About | Reference |
+----------------+--------------+------------+ +----------------+--------------+------------+
| ProviderInfo | The Call | [This RFC] | | ProviderInfo | The Call | [This RFC] |
| ServiceInfo | The Call | [This RFC] | | ServiceInfo | The Call | [This RFC] |
| DeviceInfo | The Call | [This RFC] | | DeviceInfo | The Call | [This RFC] |
| SubscriberInfo | The Call | [This RFC] | | SubscriberInfo | The Call | [This RFC] |
| Comment | The Call | [This RFC] | | Comment | The Call | [This RFC] |
+----------------+--------------+------------+ +----------------+--------------+------------+
Figure 25: Additional Data Blocks Registry Figure 25: Additional Data Blocks Registry
10.2. 'EmergencyCallData' Purpose Parameter Value 10.2. 'EmergencyCallData' Purpose Parameter Value
This document defines the 'EmergencyCallData' value for the "purpose" This document defines the 'EmergencyCallData' value for the 'purpose'
parameter of the Call-Info header field. The Call-Info header and parameter of the Call-Info header field [RFC3261]. IANA has added
the corresponding registry for the 'purpose' parameter was this document to the list of references for the 'purpose' value of
established with RFC 3261 [RFC3261]. Note that 'EmergencyCallData' Call-Info in the Header Field Parameters and Parameter Values sub-
is a compound value; when used as a value of the 'purpose' parameter registry of the Session Initiation Protocol (SIP) Parameters
of the Call-Info header, 'EmergencyCallData' is immediately followed registry. Note that 'EmergencyCallData' is a compound value; when
by a dot ('.') and a value from the 'Emergency Call Data Types' used as a value of the 'purpose' parameter of a Call-Info header
registry Section 10.1.9. field, 'EmergencyCallData' is immediately followed by a dot ('.') and
a value from the 'Emergency Call Data Types' registry Section 10.1.9.
Header Parameter New
Field Name Value Reference
---------- --------- ----------------- ---------
Call-Info purpose EmergencyCallData [This RFC]
10.3. URN Sub-Namespace Registration for <provided-by> Registry Entry 10.3. URN Sub-Namespace Registration for <provided-by> Registry Entry
This section registers the namespace specified in Section 10.5.1 in This section registers the namespace specified in Section 10.5.1 in
the provided-by registry established by RFC 4119, for usage within the provided-by registry established by RFC 4119, for usage within
the <provided-by> element of a PIDF-LO. the <provided-by> element of a PIDF-LO.
The schema for the <provided-by> element used by this document is The schema for the <provided-by> element used by this document is
specified in Section 7.6. specified in Section 7.6.
 End of changes. 27 change blocks. 
97 lines changed or deleted 92 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/