draft-ietf-ecrit-additional-data-03.txt   draft-ietf-ecrit-additional-data-04.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: September 14, 2012 Nokia Siemens Networks Expires: January 17, 2013 Nokia Siemens Networks
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
March 13, 2012 July 16, 2012
Additional Data related to an Emergency Call Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data-03.txt draft-ietf-ecrit-additional-data-04.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 device that sends it, as well as any service provider in (PSAP), the device that sends it, as well as any service provider in
the path of the call, or access network may have information about the path of the call, or access network may have information about
the call which the PSAP may be able to use. This document describes the call which the PSAP may be able to use. This document describes
an XML data structure that contains this kind of information in a an XML data structure that contains this kind of information in a
standardized form. A Uniform Resource Identifier (URI) that points standardized form. A Uniform Resource Identifier (URI) that points
to the structure can be included in the SIP signaling with the call, to the structure can be included in the SIP signaling with the call,
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 14, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 8 3. Call-Info Specification . . . . . . . . . . . . . . . . . . . 8
4. Data Provider Information . . . . . . . . . . . . . . . . . . 9 4. Data Provider Information . . . . . . . . . . . . . . . . . . 10
4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 9 4.1. Data Provider String . . . . . . . . . . . . . . . . . . . 10
4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 9 4.2. Data Provider ID . . . . . . . . . . . . . . . . . . . . . 10
4.3. Type of Data Provider ID . . . . . . . . . . . . . . . . . 10 4.3. Type of Data Provider ID . . . . . . . . . . . . . . . . . 11
4.4. Data Provider Contact URI . . . . . . . . . . . . . . . . 10 4.4. Data Provider Contact URI . . . . . . . . . . . . . . . . 12
4.5. Data Provider Languages(s) Supported . . . . . . . . . . . 11 4.5. Data Provider Languages(s) Supported . . . . . . . . . . . 12
4.6. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 12 4.6. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 13
4.7. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 12 4.7. Subcontractor Principal . . . . . . . . . . . . . . . . . 13
5. Service Information . . . . . . . . . . . . . . . . . . . . . 14 4.8. Subcontractor Priority . . . . . . . . . . . . . . . . . . 14
5.1. Service Environment . . . . . . . . . . . . . . . . . . . 14 4.9. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 14
5.2. Service Delivered by Provider to End User . . . . . . . . 14 5. Service Information . . . . . . . . . . . . . . . . . . . . . 16
5.3. Service Mobility Environment . . . . . . . . . . . . . . . 16 5.1. Service Environment . . . . . . . . . . . . . . . . . . . 16
5.4. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 17 5.2. Service Delivered by Provider to End User . . . . . . . . 16
6. Device Information . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Service Mobility Environment . . . . . . . . . . . . . . . 18
6.1. Device Classification . . . . . . . . . . . . . . . . . . 18 5.4. addCallSvcInfo XML Schema . . . . . . . . . . . . . . . . 19
6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 20 6. Device Information . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 20 6.1. Device Classification . . . . . . . . . . . . . . . . . . 20
6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 21 6.2. Device Manufacturer . . . . . . . . . . . . . . . . . . . 22
6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 21 6.3. Device Model Number . . . . . . . . . . . . . . . . . . . 22
6.6. Device/Service Specific Additional Data Structure . . . . 22 6.4. Unique Device Identifier . . . . . . . . . . . . . . . . . 23
6.7. Device/Service Specific Additional Data Structure Type . . 23 6.5. Type of Device Identifier . . . . . . . . . . . . . . . . 23
6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 23 6.6. Device/Service Specific Additional Data Structure . . . . 24
7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 25 6.7. Device/Service Specific Additional Data Structure Type . . 25
7.1. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 25 6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 25
7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 25 7. Owner/Subscriber Information . . . . . . . . . . . . . . . . . 27
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. vCARD for Subscriber's Data . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.2. addCallSub XML Schema . . . . . . . . . . . . . . . . . . 27
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. Main Telephone Number . . . . . . . . . . . . . . . . . . . . 30
11.1. Registry creation . . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11.1.1. Additional Call Data Service Delivered Registry . . . 30 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32
11.1.2. Additional Call Data Device Classification 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
Registry . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Registry creation . . . . . . . . . . . . . . . . . . . . 33
11.1.3. Additional Call Data Device ID Type Registry . . . . 32 12.1.1. Additional Call Data Blocks Registry . . . . . . . . 33
11.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 32 12.1.2. Additional Call Data Service Delivered Registry . . . 33
11.3. URN Sub-Namespace Registration for provided-by 12.1.3. Additional Call Data Device Classification
Registry Entry . . . . . . . . . . . . . . . . . . . . . . 32 Registry . . . . . . . . . . . . . . . . . . . . . . 34
11.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 33 12.1.4. Additional Call Data Device ID Type Registry . . . . 35
11.4.1. MIME Content-type Registration for 12.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 36
'application/addDataProviderInfo+xml' . . . . . . . . 33 12.3. URN Sub-Namespace Registration for provided-by
11.4.2. MIME Content-type Registration for Registry Entry . . . . . . . . . . . . . . . . . . . . . . 36
'application/addCallSvcInfo+xml' . . . . . . . . . . 34 12.4. MIME Registrations . . . . . . . . . . . . . . . . . . . . 36
11.4.3. MIME Content-type Registration for 12.4.1. MIME Content-type Registration for
'application/addDataDevInfo+xml' . . . . . . . . . . 35 'application/addDataProviderInfo+xml' . . . . . . . . 36
11.4.4. MIME Content-type Registration for 12.4.2. MIME Content-type Registration for
'application/addCallSub+xml' . . . . . . . . . . . . 36 'application/addCallSvcInfo+xml' . . . . . . . . . . 38
11.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 38 12.4.3. MIME Content-type Registration for
11.5.1. Registration for 'application/addDataDevInfo+xml' . . . . . . . . . . 39
urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 38 12.4.4. MIME Content-type Registration for
11.5.2. Registration for 'application/addCallSub+xml' . . . . . . . . . . . . 40
urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 38 12.5. URN Sub-Namespace Registration . . . . . . . . . . . . . . 41
11.5.3. Registration for 12.5.1. Registration for
urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 39 urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 41
11.5.4. Registration for urn:ietf:params:xml:ns:addCallSub . 40 12.5.2. Registration for
11.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 41 urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 12.5.3. Registration for
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 12.5.4. Registration for urn:ietf:params:xml:ns:addCallSub . 44
13.2. Informational References . . . . . . . . . . . . . . . . . 44 12.6. Schema Registrations . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 12.7. VCard Parameter Value Registration . . . . . . . . . . . . 46
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. Informational References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
As communications devices increasingly utilize the Internet to As communications devices increasingly utilize the Internet to
interconnect and communicate, users will expect to use such devices interconnect and communicate, users will expect to use such devices
to request help. The Internet Protocol suite provides many to request help. The Internet Protocol suite provides many
advantages but also requires re-thinking of the traditional emergency advantages but also requires re-thinking of the traditional emergency
calling architecture. The IETF emergency services architecture, as calling architecture. The IETF emergency services architecture, as
described in [RFC6443] and [I-D.ietf-ecrit-phonebcp], offers a much described in [RFC6443] and [I-D.ietf-ecrit-phonebcp], offers a much
richer communication exchange and thereby better situational richer communication exchange and thereby better situational
skipping to change at page 8, line 45 skipping to change at page 8, line 45
one. There may be circumstances where there is a service provider one. There may be circumstances where there is a service provider
who is unaware that the call is an emergency call and cannot who is unaware that the call is an emergency call and cannot
reasonably be expected to determine that it is an emergency call. In reasonably be expected to determine that it is an emergency call. In
that case, that service provider is not expected to provide that case, that service provider is not expected to provide
emergencyCallData. emergencyCallData.
Note: The access network MAY supply additional data as well. For Note: The access network MAY supply additional data as well. For
this purpose, this document defines a namespace and adds the this purpose, this document defines a namespace and adds the
namespace to the "provided-by" registry defined by PIDF-LO [RFC4119]. namespace to the "provided-by" registry defined by PIDF-LO [RFC4119].
In regions where callers can elect to suppress certain personally
identifying information, the network or PSAP functionality can
inspect privacy flags within the SIP headers to determine what
information may be passed, stored, or displayed to comply with local
policy or law.
Additional data about a call is defined as a series of MIME objects, Additional data about a call is defined as a series of MIME objects,
each with an XML data structure contained inside. MIME-multipart is each with an XML data structure contained inside. MIME-multipart is
used to enclose the XML documents and the sections below define them. used to enclose the XML documents and the sections below define them.
When additional data is passed by value, the CID URL points to one of
the blocks, and a link is provided in each of the other blocks to
link to the next block. When additional data is provided by
reference, the data is retrieved with an HTTP Get operation, which
returns a multi-part MIME header and a set of MIME blocks threaded
with the links. A registry of allowed types is created by this
document. Every block MUST be one of the types in the registry.
4. Data Provider Information 4. Data Provider Information
This block is intended to be provided by any service provider in the This block is intended to be provided by any service provider in the
path of the call or the access network provider. It includes path of the call or the access network provider. It includes
identification and contact information. This block SHOULD be identification and contact information. This block SHOULD be
provided for every service provider in the path of the call, and the provided for every service provider in the path of the call, and the
access network provider. Devices also use this block to provide access network provider. Devices also use this block to provide
identifying information. The MIME type is "addDataProviderInfo+xml". identifying information. The MIME type is "addDataProviderInfo+xml".
skipping to change at page 10, line 30 skipping to change at page 11, line 30
Use: Conditional. If Data Provider ID is provided, Type of Data Use: Conditional. If Data Provider ID is provided, Type of Data
Provider ID is required. Provider ID is required.
XML Element: <TypeOfProviderID> XML Element: <TypeOfProviderID>
Description: Identifies the type of data provider id being supplied Description: Identifies the type of data provider id being supplied
in the ProviderId data element. A registry will reflect the in the ProviderId data element. A registry will reflect the
following valid entries: following valid entries:
* NENA (CDMA) * Access Provider
* Origination Network Provider
* ServiceProviderSubcontractor
* Other * Other
Reason for Need: Identifies how to interpret the Data Provider ID. Reason for Need: Identifies how to interpret the Data Provider ID.
How Used by Call Taker: Determines which provider ID registry to How Used by Call Taker: Determines which provider ID registry to
consult for more information consult for more information
4.4. Data Provider Contact URI 4.4. 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: For a service provider the contact SHOULD be a contact Description: For a service provider the contact SHOULD be a contact
URI. This must be a SIP URI. If a telephone number is the URI. This must be a SIP URI. If a telephone number is the
contact address it should be provided in the form of contact address it should be provided in the form of
sip:telephonenumber@serviceprovider:user=phone. If the call is sip:telephonenumber@serviceprovider:user=phone. If the call is
skipping to change at page 12, line 25 skipping to change at page 13, line 25
Data Element: vCARD of Data Provider Data Element: vCARD of Data Provider
Use: Optional Use: Optional
XML Element: <DataProviderContact> XML Element: <DataProviderContact>
Description: There are many fields in the xCARD and the creator of Description: There are many fields in the xCARD and the creator of
the data structure is encouraged to provide as much information as the data structure is encouraged to provide as much information as
they have available. N, ORG, ADR, TEL, EMAIL are suggested at a they have available. N, ORG, ADR, TEL, EMAIL are suggested at a
minimum. N should contain name of support group or device owner minimum. N should contain name of support group or device owner
as appropriate. For encoding of the vCard this specification uses as appropriate. If more than one TEL property is provided, a
parameter from the vCard Property Value registry MUST be specified
on each TEL. For encoding of the vCard this specification uses
the XML-based encoding specified in [RFC6351]. the XML-based encoding specified in [RFC6351].
and is hereinafter referred to as "xCard" and is hereinafter referred to as "xCard"
Reason for Need: Information needed to determine additional contact Reason for Need: Information needed to determine additional contact
information. information.
How Used by Call Taker: Assists call taker by providing additional How Used by Call Taker: Assists call taker by providing additional
contact information that may not be included in the SIP invite or contact information that may not be included in the SIP invite or
the PIDF-LO. the PIDF-LO.
4.7. addDataProviderInfo XML Schema 4.7. Subcontractor Principal
Data Element: Subcontractor Principal
XML Element: <SubcontratorPrincipal>
Description: If the data provider is a subcontractor to an access
provider or origination network, this element contains the
DataProviderString of the access provider or origination network
to indicate which provider the subcontractor is working for. This
data is required if the Data Provider type is subcontractor.
Reason for Need: Identify the entity the subcontractor works for.
How Used by Call Taker: Allows the call taker to understand what the
relationship between data providers and the service providers in
the path of the call are.
4.8. Subcontractor Priority
Data Element: Subcontractor Priority
Use: Required
XML Element: <SubcontractorPriority>
Description: If the subcontractor should be contacted first, this
element should have a "sub" value. If the access or origination
service provider should be contacted first, this element should
have a "main" value. This data is required if the Data Provider
type is "subcontractor".
Reason for Need: Inform the call taker whether the network operator
or the subcontractor should be contacted first if support is
needed.
How Used by Call Taker: To decide which entity to contact first if
assistance is needed.
4.9. addDataProviderInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:addDataProviderInfo" targetNamespace="urn:ietf:params:xml:ns:addDataProviderInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ad="urn:ietf:params:xml:ns:addDataProviderInfo" xmlns:ad="urn:ietf:params:xml:ns:addDataProviderInfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0" xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
skipping to change at page 13, line 37 skipping to change at page 15, line 37
<xs:element name="ProviderID" <xs:element name="ProviderID"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="TypeOfProvider" <xs:element name="TypeOfProvider"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ContactURI" type="xs:anyURI" <xs:element name="ContactURI" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="Language" type="ad:iso3166a2" <xs:element name="Language" type="ad:iso3166a2"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xs:element name="DataProviderContact" <xs:element name="DataProviderContact"
type="vc:vcards" minOccurs="0" maxOccurs="1"> type="vc:vcards" minOccurs="0" maxOccurs="1">
<xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1">
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Figure 1: addDataProviderInfo XML Schema Figure 1: addDataProviderInfo XML Schema
5. Service Information 5. Service Information
This block describes the service that the service provider provides This block describes the service that the service provider provides
skipping to change at page 17, line 27 skipping to change at page 19, line 27
<xs:element name="addCallSvcInfo"> <xs:element name="addCallSvcInfo">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="SvcEnvironment" <xs:element name="SvcEnvironment"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="SvcDelByProvider" <xs:element name="SvcDelByProvider"
type="xs:string" minOccurs="0" maxOccurs="unbounded"/> type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="SvcMobility" <xs:element name="SvcMobility"
type="xs:string" minOccurs="0" maxOccurs="unbounded"/> type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1">
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Figure 2: addCallSvcInfo XML Schema Figure 2: addCallSvcInfo XML Schema
6. Device Information 6. Device Information
This block provides information about the device used to place the This block provides information about the device used to place the
skipping to change at page 24, line 15 skipping to change at page 26, line 15
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:addDataDevInfo" targetNamespace="urn:ietf:params:xml:ns:addDataDevInfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:svc="urn:ietf:params:xml:ns:addDataDevInfo" xmlns:svc="urn:ietf:params:xml:ns:addDataDevInfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="addCallSvcInfo"> <xs:element name="addDataDevInfo">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="DeviceClassification" <xs:element name="DeviceClassification"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceMfgr" <xs:element name="DeviceMfgr"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceModelNr" <xs:element name="DeviceModelNr"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="UniqueDeviceID" <xs:element name="UniqueDeviceID"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="TypeOfDeviceID" <xs:element name="TypeOfDeviceID"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xsd:element name="devicespecificType" <xsd:element name="devicespecificType"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xsd:element name="devicespecificSchema" <xsd:element name="devicespecificSchema"
type="xsd:anyURI" minOccurs="0" maxOccurs="1"/> type="xsd:anyURI" minOccurs="0" maxOccurs="1"/>
<xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1">
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Figure 3: addDataDevInfo XML Schema Figure 3: addDataDevInfo XML Schema
7. Owner/Subscriber Information 7. Owner/Subscriber Information
This block describes the owner of the device (if provided by the This block describes the owner of the device (if provided by the
skipping to change at page 25, line 25 skipping to change at page 27, line 25
Data Element: xCARD for Subscriber's Data Data Element: xCARD for Subscriber's Data
Use: Conditional: Some services (e.g. prepaid phones, initialized Use: Conditional: Some services (e.g. prepaid phones, initialized
phones, etc.) may not have this information. phones, etc.) may not have this information.
XML Element: <SubscriberData> XML Element: <SubscriberData>
Description: Information known by the service provider or device Description: Information known by the service provider or device
about the subscriber; i.e., Name, Address, Individual Telephone about the subscriber; i.e., Name, Address, Individual Telephone
Number, Main Telephone Number and any other data. N, ORG (if Number, Main Telephone Number and any other data. N, ORG (if
appropriate), ADR, TEL, EMAIL are suggested at a minimum. appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more
than one TEL property is provided, a parameter from the vCard
Property Value registry MUST be specified on each TEL.
Reason for Need: When the caller is unable to provide information, Reason for Need: When the caller is unable to provide information,
this data may be used to obtain it this data may be used to obtain it
How Used by Call Taker: Obtaining critical information about the How Used by Call Taker: Obtaining critical information about the
caller and possibly the location when it is not able to be caller and possibly the location when it is not able to be
obtained otherwise. obtained otherwise.
7.2. addCallSub XML Schema 7.2. addCallSub XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 26, line 21 skipping to change at page 28, line 21
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="addCallSub"> <xs:element name="addCallSub">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="SubscriberData" <xs:element name="SubscriberData"
type="vc:vcards" minOccurs="0" maxOccurs="1"> type="vc:vcards" minOccurs="0" maxOccurs="1">
</xs:sequence> <xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1">
</xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Figure 4: addCallSub XML Schema Figure 4: addCallSub XML Schema
8. Example 8. Example
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info, <http://www.example.com/alice/> ;purpose=info,
<cid:1234567890@atlanta.example.com> ;purpose=emergencyCallData <cid:1234567890@atlanta.example.com> ;purpose=emergencyCallData
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
Geolocation-Routing: no Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml,
application/addDataProviderinfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 27, line 40 skipping to change at page 29, line 41
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
...PIDF-LO goes here ...PIDF-LO goes here
--boundary1-- --boundary1--
Content-Type: application/pidf+xml Content-Type: application/addDataProviderinfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
...Additional Data goes here ...Additional Data goes here
--boundary1-- --boundary1--
Example: Attaching Additional Data via CID to a SIP INVITE Example: Attaching Additional Data via CID to a SIP INVITE
9. Security Considerations 9. Main Telephone Number
In a vCard, used extensively in this document, there is no way to
specify a "Main" telephone number. These numbers are useful to
emergency responders who are called to a large enterprise. This
document adds a new Property Value to the "tel" property of the TYPE
parameter called "main". It can be used in any vCard in additional
data.
10. Security Considerations
The information in this data structure will usually be considered The information in this data structure will usually be considered
private. HTTPS is specified to require the provider of the private. HTTPS is specified to require the provider of the
information to validate the credentials of the requester. While the information to validate the credentials of the requester. While the
creation of a PKI that has global scope may be difficult, the creation of a PKI that has global scope may be difficult, the
alternatives to creating devices and services that can provide alternatives to creating devices and services that can provide
critical information securely are more daunting. critical information securely are more daunting.
The Call-info header with purpose='emergencyCallData' MUST only be The Call-info header with purpose='emergencyCallData' MUST only be
sent on an emergency call, which can be ascertained by the presence sent on an emergency call, which can be ascertained by the presence
of an emergency service urn in a Route header of a SIP message. of an emergency service urn in a Route header of a SIP message.
<how recipient validates credentials of sender> <how recipient validates credentials of sender>
<how sender validates credentials of recipient> <how sender validates credentials of recipient>
<how sender validates credentials of anyone requesting device <how sender validates credentials of anyone requesting device
dependent data> dependent data>
10. Privacy Considerations 11. Privacy Considerations
[Editor's Note: The privacy considerations outlined in [Editor's Note: The privacy considerations outlined in
[I-D.iab-privacy-considerations] need to be addressed here in a [I-D.iab-privacy-considerations] need to be addressed here in a
future version of this document. future version of this document.
There is much private data in this information. Local regulations There is much private data in this information. Local regulations
may govern what data must be provided in emergency calls, but in may govern what data must be provided in emergency calls, but in
general, the emergency call system is often aided by the kinds of general, the emergency call system is often aided by the kinds of
information described in this document. There is a tradeoff between information described in this document. There is a tradeoff between
the privacy considerations and the utility of the data. Certainly, the privacy considerations and the utility of the data. Certainly,
if the data cannot be protected, due to failure of the TLS mechanisms if the data cannot be protected, due to failure of the TLS mechanisms
described here, data not required by regulation SHOULD not be sent. described here, data not required by regulation SHOULD not be sent.
11. IANA Considerations 12. IANA Considerations
11.1. Registry creation 12.1. Registry creation
11.1.1. Additional Call Data Service Delivered Registry 12.1.1. Additional Call Data Blocks Registry
This document creates a new registry called 'Additional Call Data
Blocks'. As defined in [RFC5226], this registry operates under
"Expert Review" and "Specification Required" rules.
The content of this registry includes:
Name: Element Name of enclosing block.
Reference: The document that describes the block
The values defined are:
+---------------------+-----------+
| Name | Reference |
+---------------------+-----------+
| addDataProviderInfo | RFCXXXX |
| addCallSvcInfo | RFCXXXX |
| addCallSvcInfo | RFCXXXX |
| addCallSub | RFCXXXX |
+---------------------+-----------+
RFC Editor Note:
replace XXXX in the table above with this documents RFC number
12.1.2. Additional Call Data Service Delivered Registry
This document creates a new registry called 'Additional Call Data This document creates a new registry called 'Additional Call Data
Service Delivered'. As defined in [RFC5226], this registry operates Service Delivered'. As defined in [RFC5226], this registry operates
under "Expert Review" rules. under "Expert Review" rules.
The content of this registry includes: The content of this registry includes:
Name: enumeration token of the service. Name: enumeration token of the service.
Description: Short description identifying the service. Description: Short description identifying the service.
skipping to change at page 31, line 5 skipping to change at page 34, line 36
| | that are supported by a monitoring | | | that are supported by a monitoring |
| | service provider or automatically | | | service provider or automatically |
| | open a two-way communication path | | | open a two-way communication path |
| POTS | Wireline: Plain Old Telephone Service | | POTS | Wireline: Plain Old Telephone Service |
| VOIP | VoIP Telephone Service: A type of | | VOIP | VoIP Telephone Service: A type of |
| | service that offers communication | | | service that offers communication |
| | over internet protocol, such as Fixed| | | over internet protocol, such as Fixed|
| | Nomadic, Mobile, ... | | | Nomadic, Mobile, ... |
+--------+-------+--------------------------------+ +--------+-------+--------------------------------+
11.1.2. Additional Call Data Device Classification Registry 12.1.3. Additional Call Data Device Classification Registry
This document creates a new registry called 'Additional Call Data This document creates a new registry called 'Additional Call Data
Device Classification'. As defined in [RFC5226], this registry Device Classification'. As defined in [RFC5226], this registry
operates under "Expert Review" rules. operates under "Expert Review" rules.
The content of this registry includes: The content of this registry includes:
Name: enumeration token of the device classification. Name: enumeration token of the device classification.
Description: Short description identifying the device type. Description: Short description identifying the device type.
skipping to change at page 32, line 5 skipping to change at page 35, line 36
| PDA | Personal digital assistant | | PDA | Personal digital assistant |
| PND | Personal navigation device) | | PND | Personal navigation device) |
| SmrtPhn| Smart phone | | SmrtPhn| Smart phone |
| Itab | Internet tablet | | Itab | Internet tablet |
| Game | Gaming console | | Game | Gaming console |
| Video | Video phone | | Video | Video phone |
| Text | Other text device | | Text | Other text device |
| NA | Not Available | | NA | Not Available |
+--------+----------------------------------------+ +--------+----------------------------------------+
11.1.3. Additional Call Data Device ID Type Registry 12.1.4. Additional Call Data Device ID Type Registry
This document creates a new registry called 'Additional Call Data This document creates a new registry called 'Additional Call Data
Device ID Type'. As defined in [RFC5226], this registry operates Device ID Type'. As defined in [RFC5226], this registry operates
under "Expert Review" rules. under "Expert Review" rules.
The content of this registry includes: The content of this registry includes:
Name: enumeration token of the device id type. Name: enumeration token of the device id type.
Description: Short description identifying the type of device id. Description: Short description identifying the type of device id.
skipping to change at page 32, line 34 skipping to change at page 36, line 20
| MAC | Media Access Control Address (IEEE) | | MAC | Media Access Control Address (IEEE) |
| WiMAX | device certificate unique id | | WiMAX | device certificate unique id |
| IMEI | International Mobile Equipment ID (GSM)| | IMEI | International Mobile Equipment ID (GSM)|
| UDI | Unique Device Identifier (medical) | | UDI | Unique Device Identifier (medical) |
| RFID | Radio Frequency Identification | | RFID | Radio Frequency Identification |
| Sense | Sensors (types to be identified ) | | Sense | Sensors (types to be identified ) |
| SN | Manufacturer Serial Number | | SN | Manufacturer Serial Number |
| Other | Other | | Other | Other |
+--------+----------------------------------------+ +--------+----------------------------------------+
11.2. 'emergencyCallData' Purpose Parameter Value 12.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. The Call-Info header and
the corresponding registry for the 'purpose' parameter was the corresponding registry for the 'purpose' parameter was
established with RFC 3261 [RFC3261]. established with RFC 3261 [RFC3261].
Header Parameter New Header Parameter New
Field Name Value Reference Field Name Value Reference
---------- --------- ----------------- --------- ---------- --------- ----------------- ---------
Call-Info purpose emergencyCallData [This RFC] Call-Info purpose emergencyCallData [This RFC]
11.3. URN Sub-Namespace Registration for provided-by Registry Entry 12.3. URN Sub-Namespace Registration for provided-by Registry Entry
This section registers the namespace specified in ??? in the This section registers the namespace specified in ??? in the
provided-by registry established by RFC 4119. provided-by registry established by RFC 4119.
11.4. MIME Registrations 12.4. MIME Registrations
11.4.1. MIME Content-type Registration for 'application/ 12.4.1. MIME Content-type Registration for 'application/
addDataProviderInfo+xml' addDataProviderInfo+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: addDataProviderInfo+xml MIME subtype name: addDataProviderInfo+xml
skipping to change at page 33, line 38 skipping to change at page 37, line 22
Security considerations: Security considerations:
This content type is designed to carry the data provider This content type is designed to carry the data provider
information, which is a sub-category of additional data about an information, which is a sub-category of additional data about an
emergency call. emergency call.
Since this data contains personal information appropriate Since this data contains personal information appropriate
precautions have to be taken to limit unauthorized access, precautions have to be taken to limit unauthorized access,
inappropriate disclosure to third parties, and eavesdropping of inappropriate disclosure to third parties, and eavesdropping of
this information. Please refer to Section 9 and Section 10 for this information. Please refer to Section 10 and Section 11 for
more information. more information.
Interoperability considerations: None Interoperability considerations: None
Published specification: [TBD: This specification] Published specification: [TBD: This specification]
Applications which use this media type: Emergency Services Applications which use this media type: Emergency Services
Additional information: Additional information:
skipping to change at page 34, line 16 skipping to change at page 38, line 5
Personal and email address for further information: Hannes Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@gmx.net Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>. working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <ietf@ietf.org> Change controller: The IESG <ietf@ietf.org>
11.4.2. MIME Content-type Registration for 'application/ 12.4.2. MIME Content-type Registration for 'application/
addCallSvcInfo+xml' addCallSvcInfo+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: addCallSvcInfo+xml MIME subtype name: addCallSvcInfo+xml
skipping to change at page 34, line 47 skipping to change at page 38, line 36
Security considerations: Security considerations:
This content type is designed to carry the service information, This content type is designed to carry the service information,
which is a sub-category of additional data about an emergency which is a sub-category of additional data about an emergency
call. call.
Since this data contains personal information appropriate Since this data contains personal information appropriate
precautions have to be taken to limit unauthorized access, precautions have to be taken to limit unauthorized access,
inappropriate disclosure to third parties, and eavesdropping of inappropriate disclosure to third parties, and eavesdropping of
this information. Please refer to Section 9 and Section 10 for this information. Please refer to Section 10 and Section 11 for
more information. more information.
Interoperability considerations: None Interoperability considerations: None
Published specification: [TBD: This specification] Published specification: [TBD: This specification]
Applications which use this media type: Emergency Services Applications which use this media type: Emergency Services
Additional information: Additional information:
skipping to change at page 35, line 29 skipping to change at page 39, line 14
Personal and email address for further information: Hannes Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@gmx.net Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>. working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <ietf@ietf.org> Change controller: The IESG <ietf@ietf.org>
11.4.3. MIME Content-type Registration for 'application/ 12.4.3. MIME Content-type Registration for 'application/
addDataDevInfo+xml' addDataDevInfo+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: addDataDevInfo+xml MIME subtype name: addDataDevInfo+xml
skipping to change at page 36, line 14 skipping to change at page 39, line 45
Security considerations: Security considerations:
This content type is designed to carry the device information This content type is designed to carry the device information
information, which is a sub-category of additional data about an information, which is a sub-category of additional data about an
emergency call. emergency call.
Since this data contains personal information appropriate Since this data contains personal information appropriate
precautions have to be taken to limit unauthorized access, precautions have to be taken to limit unauthorized access,
inappropriate disclosure to third parties, and eavesdropping of inappropriate disclosure to third parties, and eavesdropping of
this information. Please refer to Section 9 and Section 10 for this information. Please refer to Section 10 and Section 11 for
more information. more information.
Interoperability considerations: None Interoperability considerations: None
Published specification: [TBD: This specification] Published specification: [TBD: This specification]
Applications which use this media type: Emergency Services Applications which use this media type: Emergency Services
Additional information: Additional information:
Magic Number: None Magic Number: None
File Extension: .xml File Extension: .xml
Macintosh file type code: 'TEXT' Macintosh file type code: 'TEXT'
skipping to change at page 36, line 41 skipping to change at page 40, line 24
Personal and email address for further information: Hannes Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@gmx.net Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>. working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <ietf@ietf.org> Change controller: The IESG <ietf@ietf.org>
11.4.4. MIME Content-type Registration for 'application/addCallSub+xml' 12.4.4. MIME Content-type Registration for 'application/addCallSub+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: addCallSub+xml MIME subtype name: addCallSub+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See Section 3.2 of RFC 3023 [RFC3023]. character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 37, line 24 skipping to change at page 41, line 8
Security considerations: Security considerations:
This content type is designed to carry owner/subscriber This content type is designed to carry owner/subscriber
information, which is a sub-category of additional data about an information, which is a sub-category of additional data about an
emergency call. emergency call.
Since this data contains personal information appropriate Since this data contains personal information appropriate
precautions have to be taken to limit unauthorized access, precautions have to be taken to limit unauthorized access,
inappropriate disclosure to third parties, and eavesdropping of inappropriate disclosure to third parties, and eavesdropping of
this information. Please refer to Section 9 and Section 10 for this information. Please refer to Section 10 and Section 11 for
more information. more information.
Interoperability considerations: None Interoperability considerations: None
Published specification: [TBD: This specification] Published specification: [TBD: This specification]
Applications which use this media type: Emergency Services Applications which use this media type: Emergency Services
Additional information: Additional information:
skipping to change at page 38, line 5 skipping to change at page 41, line 35
Personal and email address for further information: Hannes Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@gmx.net Tschofenig, Hannes.Tschofenig@gmx.net
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification is a work item of the IETF ECRIT Author: This specification is a work item of the IETF ECRIT
working group, with mailing list address <ecrit@ietf.org>. working group, with mailing list address <ecrit@ietf.org>.
Change controller: The IESG <ietf@ietf.org> Change controller: The IESG <ietf@ietf.org>
11.5. URN Sub-Namespace Registration 12.5. URN Sub-Namespace Registration
11.5.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo 12.5.1. Registration for urn:ietf:params:xml:ns:addDataProviderInfo
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:addDataProviderInfo URI: urn:ietf:params:xml:ns:addDataProviderInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
skipping to change at page 38, line 38 skipping to change at page 42, line 24
Data Provider Information</title> Data Provider Information</title>
</head> </head>
<body> <body>
<h1>Namespace for Additional Data related to an Emergency Call</h1> <h1>Namespace for Additional Data related to an Emergency Call</h1>
<h2>Data Provider Information</h2> <h2>Data Provider Information</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
11.5.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo 12.5.2. Registration for urn:ietf:params:xml:ns:addCallSvcInfo
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:addCallSvcInfo URI: urn:ietf:params:xml:ns:addCallSvcInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
skipping to change at page 39, line 26 skipping to change at page 43, line 24
Service Information</title> Service Information</title>
</head> </head>
<body> <body>
<h1>Namespace for Additional Data related to an Emergency Call</h1> <h1>Namespace for Additional Data related to an Emergency Call</h1>
<h2>Service Information</h2> <h2>Service Information</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
11.5.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo 12.5.3. Registration for urn:ietf:params:xml:ns:addDataDevInfo
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:addDataDevInfo URI: urn:ietf:params:xml:ns:addDataDevInfo
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
skipping to change at page 40, line 24 skipping to change at page 44, line 24
Device Information</title> Device Information</title>
</head> </head>
<body> <body>
<h1>Namespace for Additional Data related to an Emergency Call</h1> <h1>Namespace for Additional Data related to an Emergency Call</h1>
<h2>Device Information</h2> <h2>Device Information</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
11.5.4. Registration for urn:ietf:params:xml:ns:addCallSub 12.5.4. Registration for urn:ietf:params:xml:ns:addCallSub
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:addCallSub URI: urn:ietf:params:xml:ns:addCallSub
Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as Registrant Contact: IETF, ECRIT working group, <ecrit@ietf.org>, as
delegated by the IESG <iesg@ietf.org>. delegated by the IESG <iesg@ietf.org>.
XML: XML:
skipping to change at page 41, line 24 skipping to change at page 45, line 24
Owner/Subscriber Information</title> Owner/Subscriber Information</title>
</head> </head>
<body> <body>
<h1>Namespace for Additional Data related to an Emergency Call</h1> <h1>Namespace for Additional Data related to an Emergency Call</h1>
<h2> Owner/Subscriber Information</h2> <h2> Owner/Subscriber Information</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
11.6. Schema Registrations 12.6. Schema Registrations
This specification registers four schemas, as per the guidelines in This specification registers four schemas, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: URI:
urn:ietf:params:xml:schema:additional-data:addDataProviderInfo urn:ietf:params:xml:schema:additional-data:addDataProviderInfo
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
skipping to change at page 43, line 5 skipping to change at page 46, line 14
XML: The XML schema can be found in Figure 3. XML: The XML schema can be found in Figure 3.
URI: urn:ietf:params:xml:schema:additional-data:addCallSub URI: urn:ietf:params:xml:schema:additional-data:addCallSub
Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as
delegated by the IESG (iesg@ietf.org). delegated by the IESG (iesg@ietf.org).
XML: The XML schema can be found in Figure 4. XML: The XML schema can be found in Figure 4.
12. Acknowledgments 12.7. VCard Parameter Value Registration
The authors would like to thank the following persons for their work This document registers a new value in the vCARD Parameter Values
in the NENA Data Technical Committee: Delaine Arnold (Data Technical registry as defined by [RFC6350] with the following template:
Committee Chair), Marc Berryman, Erica Aubut (Data Technical
Committee Vice-Chair), Susan Sherwood, Ric Atkins, Patty Bluhm,
Eileen Boroski, David Connel, Maryls Davis, Paul-David de la Rosby,
Gordon Chinander, David Froneberger, Marilyn Haroutunian, Roger
Hixson, Rick Jones, Roger Marshall, Tom Muehleisen, Ira Pyles, Carl
Reed, Susan Seet, and Skip Walls. The authors would also like to
thank Tom Breen, Technical Committee Chair/Liaison; Busam, Technical
Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee
Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison;
Roger Hixson, Technical Director; and Rick Jones, Operations Issues
Director for their support and assistance.
[Editor's Note: Add the participants of the NENA Additional Data Value: main
Working group lead by Matt Serra.]
13. References Purpose: The main telephone number, typically of an enterprise, as
opposed to a direct dial number of an individual employee
13.1. Normative References Conformance: This value can be used with the "TYPE" parameter
applied on the "TEL" property.
Example(s):
TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-9000
13. Acknowledgments
This work was originally started in NENA and has benefitted from a
large number of participants in NENA standardization efforts,
originally in the Long Term Definition Working Group, the Data
Technical Committee and most recently the Additional Data working
group. The authors are grateful for the initial work and extended
comments provided by the many NENA participants.
14. References
14.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
skipping to change at page 44, line 36 skipping to change at page 48, line 36
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", [RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, August 2011. RFC 6351, August 2011.
13.2. Informational References 14.2. Informational References
[I-D.iab-privacy-considerations] [I-D.iab-privacy-considerations]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
J. Morris, "Privacy Considerations for Internet Morris, J., Hansen, M., and R. Smith, "Privacy
Protocols", draft-iab-privacy-considerations-02 (work in Considerations for Internet Protocols",
progress), March 2012. draft-iab-privacy-considerations-03 (work in progress),
July 2012.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress), draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011. September 2011.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011. Multimedia", RFC 6443, December 2011.
 End of changes. 53 change blocks. 
120 lines changed or deleted 238 lines changed or added

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