draft-ietf-ecrit-additional-data-14.txt   draft-ietf-ecrit-additional-data-15.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: April 19, 2014 Nokia Solutions and Networks Expires: May 07, 2014 Nokia Solutions and Networks
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
R. Gellens R. Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
J. Winterbottom J. Winterbottom
October 16, 2013 November 03, 2013
Additional Data related to an Emergency Call Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data-14.txt draft-ietf-ecrit-additional-data-15.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 application service (PSAP), the device that sends it, as well as any application service
provider in the path of the call, or access network provider through provider in the path of the call, or access network provider through
which the call originated may have information about the call, the which the call originated may have information about the call, the
caller or the location which the PSAP may be able to use. This caller or the location which the PSAP may be able to use. This
document describes data structures and a mechanism to convey such document describes data structures and a mechanism to convey such
data to the PSAP. The mechanism uses a Uniform Resource Identifier data to the PSAP. The mechanism uses a Uniform Resource Identifier
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 April 19, 2014. This Internet-Draft will expire on May 07, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7
3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7
3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8
3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8
3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9
3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 9 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10
3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 11
3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 10 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11
3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 11 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12
3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 11 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12
3.1.10. emergencyCall.ProviderInfo Example . . . . . . . . . 12 3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13
3.2. Service Information . . . . . . . . . . . . . . . . . . . 14 3.2. Service Information . . . . . . . . . . . . . . . . . . . 15
3.2.1. Service Environment . . . . . . . . . . . . . . . . . 14 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15
3.2.2. Service Delivered by Provider to End User . . . . . . 15 3.2.2. Service Delivered by Provider to End User . . . . . . 15
3.2.3. Service Mobility Environment . . . . . . . . . . . . 16 3.2.3. Service Mobility Environment . . . . . . . . . . . . 18
3.2.4. emergencyCall.SvcInfo Example . . . . . . . . . . . . 17 3.2.4. emergencyCallData.SvcInfo Example . . . . . . . . . . 18
3.3. Device Information . . . . . . . . . . . . . . . . . . . 17 3.3. Device Information . . . . . . . . . . . . . . . . . . . 19
3.3.1. Device Classification . . . . . . . . . . . . . . . . 17 3.3.1. Device Classification . . . . . . . . . . . . . . . . 19
3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 20
3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 19 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 21
3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 19 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 21
3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 20 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 21
3.3.6. Device/Service Specific Additional Data Structure . . 20 3.3.6. Device/Service Specific Additional Data Structure . . 22
3.3.7. Device/Service Specific Additional Data Structure 3.3.7. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 21 Type . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.8. Choosing between defining a new type of block or new 3.3.8. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 22 type of device/service specific additional data . . . 23
3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22 3.3.9. emergencyCallData.DevInfo Example . . . . . . . . . . 24
3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 23 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24
3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 23 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 25
3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 24 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25
3.4.3. emergencyCall.SubInfo Example . . . . . . . . . . . . 24 3.4.3. emergencyCallData.SubInfo Example . . . . . . . . . . 26
3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27 3.5.2. emergencyCallData.Comment Example . . . . . . . . . . 29
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Transmitting Blocks using the Call-Info Header . . . . . 29 4.1. Transmitting Blocks using the Call-Info Header . . . . . 31
4.2. Transmitting Blocks by Reference using the Provided-By 4.2. Transmitting Blocks by Reference using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Transmitting Blocks by Value using the Provided-By 4.3. Transmitting Blocks by Value using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 Element . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4. The Content-Disposition Parameter . . . . . . . . . . . . 31 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 33
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 36 6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 45
6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 37 6.2. emergencyCallData.SvcInfo XML Schema . . . . . . . . . . 47
6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 38 6.3. emergencyCallData.DevInfo XML Schema . . . . . . . . . . 48
6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 39 6.4. emergencyCallData.SubInfo XML Schema . . . . . . . . . . 49
6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 39 6.5. emergencyCallData.Comment XML Schema . . . . . . . . . . 49
6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 40 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 50
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 46 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 56
9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 46 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 56
9.1.2. Service Provider Type Registry . . . . . . . . . . . 46 9.1.2. Service Environment Registry . . . . . . . . . . . . 57
9.1.3. Service Delivered Registry . . . . . . . . . . . . . 47 9.1.3. Service Provider Type Registry . . . . . . . . . . . 57
9.1.4. Device Classification Registry . . . . . . . . . . . 47 9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57
9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 47 9.1.5. Device Classification Registry . . . . . . . . . . . 58
9.1.6. Device/Service Data Type Registry . . . . . . . . . . 48 9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58
9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48 9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58
9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 49 9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 59
9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 60
9.3. URN Sub-Namespace Registration for provided-by Registry 9.3. URN Sub-Namespace Registration for provided-by Registry
Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 49 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 60
9.4.1. MIME Content-type Registration for 9.4.1. MIME Content-type Registration for
'application/emergencyCall.ProviderInfo+xml' . . . . 49 'application/emergencyCallData.ProviderInfo+xml' . . 60
9.4.2. MIME Content-type Registration for 9.4.2. MIME Content-type Registration for
'application/emergencyCall.SvcInfo+xml' . . . . . . . 50 'application/emergencyCallData.SvcInfo+xml' . . . . . 61
9.4.3. MIME Content-type Registration for 9.4.3. MIME Content-type Registration for
'application/emergencyCall.DevInfo+xml' . . . . . . . 51 'application/emergencyCallData.DevInfo+xml' . . . . . 62
9.4.4. MIME Content-type Registration for 9.4.4. MIME Content-type Registration for
'application/emergencyCall.SubInfo+xml' . . . . . . . 52 'application/emergencyCallData.SubInfo+xml' . . . . . 63
9.4.5. MIME Content-type Registration for 9.4.5. MIME Content-type Registration for
'application/emergencyCall.Comment+xml' . . . . . . . 53 'application/emergencyCallData.Comment+xml' . . . . . 64
9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 54 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65
9.5.1. Registration for 9.5.1. Registration for
urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 54 urn:ietf:params:xml:ns:emergencycalldata . . . . . . 65
9.5.2. Registration for 9.5.2. Registration for
urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 55 urn:ietf:params:xml:ns:emergencycalldata:providerinfo 66
9.5.3. Registration for 9.5.3. Registration for
urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 56 urn:ietf:params:xml:ns:emergencycalldata:svcinfo . . 67
9.5.4. Registration for 9.5.4. Registration for
urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 57 urn:ietf:params:xml:ns:emergencycalldata:devinfo . . 67
9.5.5. Registration for 9.5.5. Registration for
urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 57 urn:ietf:params:xml:ns:emergencycalldata:subinfo . . 68
9.5.6. Registration for 9.5.6. Registration for
urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 58 urn:ietf:params:xml:ns:emergencycalldata:comment . . 69
9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 59 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 70
9.7. VCard Parameter Value Registration . . . . . . . . . . . 60 9.7. VCard Parameter Value Registration . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
11.1. Normative References . . . . . . . . . . . . . . . . . . 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 71
11.2. Informational References . . . . . . . . . . . . . . . . 61 11.2. Informational References . . . . . . . . . . . . . . . . 72
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 62 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
When an IP-based emergency call is initiated a rich set of data from When an IP-based emergency call is initiated a rich set of data from
multiple data sources is conveyed to the Public Safety Answering multiple data sources is conveyed to the Public Safety Answering
Point (PSAP). This data includes information about the calling party Point (PSAP). This data includes information about the calling party
identity, the multimedia capabilities of the device, the emergency identity, the multimedia capabilities of the device, the emergency
service number, location information, and meta-data about the sources service number, location information, and meta-data about the sources
of the data. The device, the access network provider, and any of the data. The device, the access network provider, and any
service provider in the call path may have even more information service provider in the call path may have even more information
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Section 3.3. Section 3.3.
'Owner/Subscriber': This block supplies information about the owner 'Owner/Subscriber': This block supplies information about the owner
of the device or about the subscriber. Details can be found in of the device or about the subscriber. Details can be found in
Section 3.4. Section 3.4.
'Comment': This block provides a way to supply free form human 'Comment': This block provides a way to supply free form human
readable text to the PSAP or emergency responders. This simple readable text to the PSAP or emergency responders. This simple
structure is defined in Section 3.5. structure is defined in Section 3.5.
Each block contains a mandatory <id> element. The purpose of this
<id> element is to associate the data added by a data provider to the
data provider block. Consequently, when a data provider adds
additional data to an emergency call (such as device information) it
MUST add information about itself (via the data provider block) and
the two blocks contain the same value in the <id> element, whereby
the chosen value for the <id> element MUST be different to any other
<id> elements already added by other data providers.
Note that the xCard format is re-used in some of the data structures Note that the xCard format is re-used in some of the data structures
to provide contact information. In an xCard there is no way to to provide contact information. In an xCard there is no way to
specify a "main" telephone number. These numbers are useful to specify a "main" telephone number. These numbers are useful to
emergency responders who are called to a large enterprise. This emergency responders who are called to a large enterprise. This
document adds a new property value to the "tel" property of the TYPE document adds a new property value to the "tel" property of the TYPE
parameter called "main". It can be used in any xCard in additional parameter called "main". It can be used in any xCard in additional
data. data.
3.1. Data Provider Information 3.1. Data Provider Information
skipping to change at page 9, line 28 skipping to change at page 10, line 10
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 with an initial set of in the ProviderId data element. A registry with an initial set of
values is shown in Figure 1. values is shown in Figure 1.
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Token | Description | | Token | Description |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
|Access Network Provider | Access network service provider | |Access Network Provider | Access network service provider |
|Service Provider | Calling or Origination telecom SP | |Service Provider | Calling or Origination telecom SP |
|Service Provider Subcontractor| A contractor to another kind of SP | |Subcontractor | A contractor to another SP |
|Telematics Provider | A sensor based SP, especially | |Telematics Provider | A sensor based SP, especially |
| | vehicle based | | | vehicle based |
|Language Translation Provider | A spoken language translation SP | |Language Translation Provider | A spoken language translation SP |
|Emergency Service Provider | An emergency service provider | |Emergency Service Provider | An emergency service provider |
| | conveying information to another | | | conveying information to another |
| | emergency service provider. | | | emergency service provider. |
|Emergency Modality Translation| An emergency call specific | |Emergency Modality Translation| An emergency call specific |
| | modality translation service | | | modality translation service |
| | e.g., for sign language | | | e.g., for sign language |
|Relay Provider | A interpretation SP, for example, | |Relay Provider | A interpretation SP, for example, |
skipping to change at page 10, line 17 skipping to change at page 10, line 48
XML Element: <ContactURI> XML Element: <ContactURI>
Description: When provided by a service provider or an access Description: When provided by a service provider or an access
provider, this information MUST be a URI to a 24/7 support provider, this information MUST be a URI to a 24/7 support
organization tasked to provide PSAP support for this emergency organization tasked to provide PSAP support for this emergency
call. If the call is from a device, this would reflect the call. If the call is from a device, this would reflect the
contact information of the owner of the device. If a telephone contact information of the owner of the device. If a telephone
number is the contact address then it MUST be tel URI. If it is number is the contact address then it MUST be tel URI. If it is
provided as a SIP URI then it MUST be in the form of provided as a SIP URI then it MUST be in the form of
sip:telephonenumber@serviceprovider:user=phone. sip:telephonenumber@serviceprovider:user=phone. Note that this
contact information is not used by PSAPs for callbacks using a SIP
Priority header field with the value set to "psap- callback", as
described in [I-D.ietf-ecrit-psap-callback].
Reason for Need: Additional data providers may need to be contacted Reason for Need: Additional data providers may need to be contacted
for error or other unusual circumstances. for error or other unusual circumstances.
How Used by Call Taker: To contact the supplier of the additional How Used by Call Taker: To contact the supplier of the additional
data for assistance in handling the call. data for assistance in handling the call.
3.1.6. Data Provider Languages(s) Supported 3.1.6. Data Provider Languages(s) Supported
Data Element: Data Provider Language(s) supported Data Element: Data Provider Language(s) supported
skipping to change at page 10, line 40 skipping to change at page 11, line 26
XML Element: <Language> XML Element: <Language>
Description: The language used by the entity at the Data Provider Description: The language used by the entity at the Data Provider
Contact URI as an alpha 2-character code as defined in ISO Contact URI as an alpha 2-character code as defined in ISO
639-1:2002 Codes for the representation of names of languages -- 639-1:2002 Codes for the representation of names of languages --
Part 1: Alpha-2 code Multiple instances of this element may occur. Part 1: Alpha-2 code Multiple instances of this element may occur.
Order is significant; preferred language should appear first. The Order is significant; preferred language should appear first. The
content MUST reflect the languages supported at the contact URI. content MUST reflect the languages supported at the contact URI.
Note that the 'language' media feature tag, defined in RFC 3840
[RFC3840] and the more extensive language negotiation mechanism
proposed with [I-D.gellens-negotiating-human-language] are
independent of this data provider language indication.
Reason for Need: Information needed to determine if emergency Reason for Need: Information needed to determine if emergency
service authority can communicate with the service provider or if service authority can communicate with the service provider or if
an interpreter will be needed. an interpreter will be needed.
How Used by Call Taker: If call taker cannot speak language(s) How Used by Call Taker: If call taker cannot speak language(s)
supported by the service provider, a translation service will need supported by the service provider, a translation service will need
to be added to the conversation. Alternatively, other persons at to be added to the conversation. Alternatively, other persons at
the PSAP, besides the call taker, might be consulted for help the PSAP, besides the call taker, might be consulted for help
(depending on the urgency and the type of interaction). (depending on the urgency and the type of interaction).
skipping to change at page 11, line 36 skipping to change at page 12, line 26
3.1.8. Subcontractor Principal 3.1.8. Subcontractor Principal
Data Element: Subcontractor Principal Data Element: Subcontractor Principal
Use: Conditional. This data is required if the Data Provider type Use: Conditional. This data is required if the Data Provider type
is subcontractor. is subcontractor.
XML Element: <SubcontratorPrincipal> XML Element: <SubcontratorPrincipal>
Description: If the data provider is a subcontractor to another Description: Some providers outsource their obligations to handle
provider, such as an access infrastructure provider or telematics aspects of emergency services to specialized providers. If the
provider, this element contains the DataProviderString of the data provider is a subcontractor to another provider this element
service provider to indicate which provider the subcontractor is contains the DataProviderString of the service provider to
working for. indicate which provider the subcontractor is working for.
Reason for Need: Identify the entity the subcontractor works for. Reason for Need: Identify the entity the subcontractor works for.
How Used by Call Taker: Allows the call taker to understand what the How Used by Call Taker: Allows the call taker to understand what the
relationship between data providers and the service providers in relationship between data providers and the service providers in
the path of the call are. the path of the call are.
3.1.9. Subcontractor Priority 3.1.9. Subcontractor Priority
Data Element: Subcontractor Priority Data Element: Subcontractor Priority
Use: Conditional. This data is required if the Data Provider type
is "subcontractor". Use: Conditional. This element is required if the Data Provider
type is set to "Subcontractor".
XML Element: <SubcontractorPriority> XML Element: <SubcontractorPriority>
Description: If the subcontractor has to be contacted first then Description: If the subcontractor has to be contacted first then
this element MUST have the value "sub". If the access or service this element MUST have the value "sub". If the provider the
provider has to be contacted first then this element MUST have the subcontractor is working for has to be contacted first then this
value "main". element MUST have the value "main".
Reason for Need: Inform the call taker whom to contact first, if Reason for Need: Inform the call taker whom to contact first, if
support is needed. support is needed.
How Used by Call Taker: To decide which entity to contact first if How Used by Call Taker: To decide which entity to contact first if
assistance is needed. assistance is needed.
3.1.10. emergencyCall.ProviderInfo Example 3.1.10. ProviderInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ad:emergencyCall.ProviderInfo <ad:emergencyCallData.ProviderInfo
xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" xmlns:ad="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ad:id>12345</ad:id>
<ad:DataProviderString>Example VoIP Provider <ad:DataProviderString>Example VoIP Provider
</ad:DataProviderString> </ad:DataProviderString>
<ad:ProviderID>urn:nena:companyid:ID123</ad:ProviderID> <ad:ProviderID>urn:nena:companyid:ID123</ad:ProviderID>
<ad:ProviderIDSeries>NENA</ad:ProviderIDSeries> <ad:ProviderIDSeries>NENA</ad:ProviderIDSeries>
<ad:TypeOfProvider>Service Provider</ad:TypeOfProvider> <ad:TypeOfProvider>Service Provider</ad:TypeOfProvider>
<ad:ContactURI>sip:voip-provider@example.com</ad:ContactURI> <ad:ContactURI>sip:voip-provider@example.com</ad:ContactURI>
<ad:Language>EN</ad:Language> <ad:Language>EN</ad:Language>
<xc:DataProviderContact <ad:DataProviderContact
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"> xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard> <vcard>
<fn><text>Hannes Tschofenig</text></fn> <fn><text>Hannes Tschofenig</text></fn>
<n> <n>
<surname>Hannes</surname> <surname>Hannes</surname>
<given>Tschofenig</given> <given>Tschofenig</given>
<additional/> <additional/>
<prefix/> <prefix/>
<suffix>Dipl. Ing.</suffix> <suffix>Dipl. Ing.</suffix>
</n> </n>
<bday><date>--0203</date></bday> <bday><date>--0203</date></bday>
skipping to change at page 14, line 18 skipping to change at page 15, line 9
http://www.tschofenig.priv.at/key.asc http://www.tschofenig.priv.at/key.asc
</uri> </uri>
</key> </key>
<tz><text>Finland/Helsinki</text></tz> <tz><text>Finland/Helsinki</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://www.tschofenig.priv.at</uri> <uri>http://www.tschofenig.priv.at</uri>
</url> </url>
</vcard> </vcard>
</xc:DataProviderContact> </ad:DataProviderContact>
</ad:emergencyCall.ProviderInfo> </ad:emergencyCallData.ProviderInfo>
Figure 2: emergencyCall.ProviderInfo Example. Figure 2: emergencyCall.ProviderInfo Example.
3.2. Service Information 3.2. Service Information
This block describes the service that the service provider provides This block describes the service that the service provider provides
to the caller. It SHOULD be included by all SPs in the path of the to the caller. It SHOULD be included by all SPs in the path of the
call. The mime subtype is "application/emergencyCall.SvcInfo+xml". call. The mime subtype is "application/emergencyCall.SvcInfo+xml".
3.2.1. Service Environment 3.2.1. Service Environment
Data Element: Service Environment Data Element: Service Environment
Use: Required Use: Required
XML Element: <SvcEnvironment> XML Element: <SvcEnvironment>
Description: This element defines whether a call is from a business Description: This element defines whether a call is from a business
or residence caller. Currently, the only valid entries are or residence caller. Currently, the only valid entries are
'Business' or 'Residence'. 'Business' or 'Residence'. New values can be defined via the
registry created in Figure 22.
Reason for Need: To assist in determining equipment and manpower Reason for Need: To assist in determining equipment and manpower
requirements. requirements.
How Used by Call Taker: Information may be used to assist in How Used by Call Taker: Information may be used to assist in
determining equipment and manpower requirements for emergency determining equipment and manpower requirements for emergency
responders. As the information is not always available, and the responders. As the information is not always available, and the
registry is not all encompassing, this is at best advisory registry is not all encompassing, this is at best advisory
information, but since it mimics a similar capability in some information, but since it mimics a similar capability in some
current emergency calling systems, it is known to be valuable. current emergency calling systems, it is known to be valuable.
skipping to change at page 17, line 14 skipping to change at page 18, line 45
* Unknown: no information is known about the service mobility * Unknown: no information is known about the service mobility
environment for the device environment for the device
Reason for Need: Knowing the service provider's belief of mobility Reason for Need: Knowing the service provider's belief of mobility
may assist the PSAP with the handling of the call. may assist the PSAP with the handling of the call.
How Used by Call Taker: To determine whether to assume the location How Used by Call Taker: To determine whether to assume the location
of the caller might change. of the caller might change.
3.2.4. emergencyCall.SvcInfo Example 3.2.4. emergencyCallData.SvcInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:emergencyCall.SvcInfo <svc:emergencyCallData.SvcInfo
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:id>12345</svc:id>
<svc:SvcEnvironment>Business</svc:SvcEnvironment> <svc:SvcEnvironment>Business</svc:SvcEnvironment>
<svc:SvcDelByProvider>MLTS</svc:SvcDelByProvider> <svc:SvcDelByProvider>MLTS</svc:SvcDelByProvider>
<svc:SvcMobility>Fixed</svc:SvcMobility> <svc:SvcMobility>Fixed</svc:SvcMobility>
</svc:emergencyCall.SvcInfo> </svc:emergencyCallData.SvcInfo>
Figure 4: emergencyCall.SvcInfo Example. Figure 4: emergencyCallData.SvcInfo Example.
3.3. Device Information 3.3. Device Information
This block provides information about the device used to place the This block provides information about the device used to place the
call. It should be provided by any service provider that knows what call. It should be provided by any service provider that knows what
device is being used, and by the device itself. The mime subtype is device is being used, and by the device itself. The mime subtype is
"application/emergencyCall.DevInfo+xml". "application/emergencyCall.DevInfo+xml".
3.3.1. Device Classification 3.3.1. Device Classification
skipping to change at page 22, line 39 skipping to change at page 24, line 33
DevInfo block, rather than a new block so that implementations are DevInfo block, rather than a new block so that implementations are
not tempted to send the data by value. Conversely, data which is not tempted to send the data by value. Conversely, data which is
small may best be sent in a separate block so that it can be sent small may best be sent in a separate block so that it can be sent
by value by value
Availability of a server: Providing the data via the device block Availability of a server: Providing the data via the device block
requires a server be made available to retrieve the data. requires a server be made available to retrieve the data.
Providing the data via new block allows it to be sent by value Providing the data via new block allows it to be sent by value
(CID). (CID).
3.3.9. emergencyCall.DevInfo Example 3.3.9. emergencyCallData.DevInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:emergencyCall.DevInfo <dev:emergencyCallData.DevInfo
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.DevInfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:DeviceClassification>Fixed phone</svc:DeviceClassification> <dev:id>12345</dev:id>
<svc:DeviceMfgr>Nokia</svc:DeviceMfgr> <dev:DeviceClassification>Fixed phone</dev:DeviceClassification>
<svc:DeviceModelNr>Lumia 800</svc:DeviceModelNr> <dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
<svc:UniqueDeviceID>35788104</svc:UniqueDeviceID> <dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
<svc:TypeOfDeviceID>IMEI</svc:TypeOfDeviceID> <dev:UniqueDeviceID>35788104</dev:UniqueDeviceID>
</svc:emergencyCall.DevInfo> <dev:TypeOfDeviceID>IMEI</dev:TypeOfDeviceID>
</dev:emergencyCallData.DevInfo>
Figure 7: emergencyCallDevInfo Example. Figure 7: emergencyCallData.DevInfo Example.
3.4. Owner/Subscriber Information 3.4. 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
device) or the subscriber information, if provided by a service device) or the subscriber information, if provided by a service
provider. The contact location is not necessarily the location of provider. The contact location is not necessarily the location of
the caller or incident, but is rather the nominal contact address. the caller or incident, but is rather the nominal contact address.
The mime subtype is "application/emergencyCall.Subscriber+xml". The mime subtype is "application/emergencyCall.Subscriber+xml".
In some jurisdictions some or all parts of the subscriber-specific In some jurisdictions some or all parts of the subscriber-specific
information are subject to privacy constraints. These constraints information are subject to privacy constraints. These constraints
vary but dictate what information and be displayed and logged. A vary but dictate what information and be displayed and logged. A
general privacy indicator expressing a desire for privacy is general privacy indicator expressing a desire for privacy is
skipping to change at page 24, line 33 skipping to change at page 26, line 16
than one TEL property is provided, a parameter from the vCard than one TEL property is provided, a parameter from the vCard
Property Value registry MUST be specified on each TEL. 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.
3.4.3. emergencyCall.SubInfo Example 3.4.3. emergencyCallData.SubInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ad:emergencyCall.SubInfo <sub:emergencyCallData.SubInfo
xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo" xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:subinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
privacyRequested="false"> privacyRequested="false">
<xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"> <sub:id>12345</sub:id>
<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0"> <sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcards>
<vcard> <vcard>
<fn><text>Simon Perreault</text></fn> <fn><text>Simon Perreault</text></fn>
<n> <n>
<surname>Perreault</surname> <surname>Perreault</surname>
<given>Simon</given> <given>Simon</given>
<additional/> <additional/>
<prefix/> <prefix/>
<suffix>ing. jr</suffix> <suffix>ing. jr</suffix>
<suffix>M.Sc.</suffix> <suffix>M.Sc.</suffix>
</n> </n>
skipping to change at page 26, line 38 skipping to change at page 28, line 23
</uri> </uri>
</key> </key>
<tz><text>America/Montreal</text></tz> <tz><text>America/Montreal</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://nomis80.org</uri> <uri>http://nomis80.org</uri>
</url> </url>
</vcard> </vcard>
</vcards> </vcards>
</xc:SubscriberData> </sub:SubscriberData>
</ad:emergencyCall.SubInfo> </sub:emergencyCallData.SubInfo>
Figure 8: emergencyCall.SubInfo Example. Figure 8: emergencyCallData.SubInfo Example.
3.5. Comment 3.5. Comment
This block provides a mechanism for the data provider to supply This block provides a mechanism for the data provider to supply
extra, human readable information to the PSAP. It is not intended extra, human readable information to the PSAP. It is not intended
for a general purpose extension mechanism nor does it aim to provide for a general purpose extension mechanism nor does it aim to provide
machine-reable content. The mime subtype is "application/ machine-reable content. The mime subtype is "application/
emergencyCall.Comment+xml" emergencyCall.Comment+xml"
3.5.1. Comment 3.5.1. Comment
skipping to change at page 27, line 21 skipping to change at page 29, line 5
XML Element: <Comment> XML Element: <Comment>
Description: Human readable text providing additional information to Description: Human readable text providing additional information to
the PSAP staff. the PSAP staff.
Reason for Need: Explanatory information for values in the data Reason for Need: Explanatory information for values in the data
structure structure
How Used by Call Taker: To interpret the data provided How Used by Call Taker: To interpret the data provided
3.5.2. emergencyCall.Comment Example 3.5.2. emergencyCallData.Comment Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<sub:emergencyCall.Comment <com:emergencyCallData.Comment
xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.Comment" xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:comment"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<sub:Comment xml:lang="en">This is an example text.</sub:Comment> <com:id>12345</com:id>
</sub:emergencyCall.Comment> <com:Comment xml:lang="en">This is an example text.</com:Comment>
</com:emergencyCallData.Comment>
Figure 9: EmergencyCall.Comment Example. Figure 9: EmergencyCallData.Comment Example.
4. Transport 4. Transport
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, is
skipping to change at page 32, line 8 skipping to change at page 33, line 38
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 the Call-info header containing a
Content Indirection (CID) URL. 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 10. parameter in the body of the SIP message as shown in Figure 10.
Content-Type: application/sdp Content-Type: application/sdp
...Omit Content-Disposition here; defaults are ok ...Omit Content-Disposition here; defaults are ok
...SDP goes here ...SDP goes in here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
...PIDF-LO goes here ...PIDF-LO goes in here
--boundary1-- --boundary1--
Content-Type: application/emergencyCall.ProviderInfo+xml Content-Type: application/emergencyCall.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
...Additional data goes here ...Data provider information data goes in here
--boundary1-- --boundary1--
Figure 10: Example for use of the Content-Disposition Parameter in Figure 10: Example for use of the Content-Disposition Parameter in
SIP. SIP.
5. Examples 5. Examples
This section provides three examples of communicating additional This section illustrates a longer and more complex example, as shown
data. In Figure 11 additional data is communicated in a SIP INVITE in Figure 11. In this example additional data is added by the end
per value. In Figure 12 we illustrate how additional data is added device, included by the VoIP provider, and provided by the access
by a SIP proxy per reference. Finally, an example for including network provider.
additional data in the <Provided-By> element of a PIDF-LO is
illustrated.
INVITE sips:bob@biloxi.example.com SIP/2.0 O +----+ Emergency Call
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 /|\ | UA |--+ +Device Info
| +----+ | +Data Provider Info
/ \ | +Location URI
|
| (1)
\
\
,-----------. Location
,' `. +Owner/Subscriber Info
/ \ +Device Info
| Access | +Data Provider Info #3
| Network |<..................+
| Provider | .
\ / . (4)
`. ,' .
'----------' .
| .
| v
| +----------+
(2)| | |
| | PSAP |
\ | |
\ +----------+
Emergency Call \ ^
+Device Info \ |
+Data Provider Info ,-------. | (3)
+Location URI ,' `. -
/ VoIP \ ----
( Provider )---
\ example.org / Emergency Call
`. ,' +Device Info
'-------' +Owner/Subscriber Info
+Data Provider Info
//////////////
+Service Info
+Location URI
+Data Provider Info #2
Legend:
--- Emergency Call Setup Procedure
... Location Retrieval/Response
Figure 11: Additional Data Example Flow.
The example scenario starts with the end device itself adding device
information, owner/subscriber information, a location URI, and data
provider information to the outgoing emergency call setup message
(see step #1 in Figure 11). The SIP INVITE example is shown in
Figure 12.
INVITE urn:service:sos SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: <urn:service:sos>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info, <http://www.example.com/hannes/> ;purpose=info,
<cid:1234567890@atlanta.example.com> <cid:1234567890@example.com>
;purpose=emergencyCallData.ProviderInfo ;purpose=emergencyCallData.ProviderInfo
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: no Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallProviderinfo+xml application/emergencyCallProviderinfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:hannes@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
...SDP goes here ...SDP goes here
--boundary1 --boundary1--
Content-Type: application/pidf+xml Content-Type: application/emergencyCallData.DevInfo+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
...PIDF-LO goes here <dev:emergencyCallData.DevInfo
xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dev:id>12345</svc:id>
<dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
</dev:emergencyCallData.DevInfo>
--boundary1-- --boundary1--
Content-Type: application/emergencyCall.ProviderInfo+xml Content-Type: application/emergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:emergencyCallData.ProviderInfo
xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<pi:id>12345</pi:id>
<pi:DataProviderString>Hannes Tschofenig
</pi:DataProviderString>
<pi:TypeOfProvider>Other</pi:TypeOfProvider>
<pi:ContactURI>sip:hannes@example.com</pi:ContactURI>
<pi:Language>EN</pi:Language>
<xc:DataProviderContact
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Hannes Tschofenig</text></fn>
<n>
<surname>Hannes</surname>
<given>Tschofenig</given>
<additional/>
<prefix/>
<suffix>Dipl. Ing.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>de</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Hannes Tschofenig
Linnoitustie 6
Espoo, Finland
02600</text></label>
</parameters>
<pobox/>
<ext/>
<street>Linnoitustie 6</street>
<locality>Espoo</locality>
<region>Uusimaa</region>
<code>02600</code>
<country>Finland</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 4871445</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>hannes.tschofenig@nsn.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:60.210796,24.812924</uri>
...Additional data goes here </geo>
<key>
<parameters>
<type><text>home</text></type>
</parameters>
<uri>https://www.example.com/key.asc
</uri>
</key>
<tz><text>Finland/Helsinki</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://example.com/hannes.tschofenig</uri>
</url>
</vcard>
</xc:DataProviderContact>
</pi:emergencyCallData.ProviderInfo>
--boundary1-- --boundary1--
Figure 11: Example: Attaching Additional Data via CID to a SIP Figure 12: End Device sending SIP INVITE with Additional Data.
INVITE.
INVITE sips:bob@biloxi.example.com SIP/2.0 In this example, information available to the access network operator
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 is included in the call setup message only indirectly via the use of
the location reference. The PSAP has to retrieve it via a separate
look-up step. Since the access network provider and the VoIP service
provider are two independent entities in this scenario the access
network operator is not involved in the processing of application
layer exchanges and forwards the SIP INVITE transparently, as
illustrated in step #1. No change to the SIP INVITE is applied.
When the VoIP service provider receives the message and determines
based on the Service URN that the incoming request is an emergency
call. It performs the typical emergency services related tasks,
including location-based routing, and adds additional data, namely
service and subscriber information, to the outgoing message. For the
example we assume a VoIP service provider that deploys a back-to-back
user agent allowing additional data to be included in the body of the
SIP message (rather than per reference in the header), which allows
us to illustrate the use of multiple data provider info blocks. The
resulting message is shown in Figure 13.
INVITE sips:psap@example.org SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: <urn:service:sos>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info, <http://www.example.com/hannes/> ;purpose=info,
<https://www.example.com/abc123456/> <cid:1234567890@example.com>
;purpose=emergencyCallData.ProviderInfo ;purpose=emergencyCallData.ProviderInfo
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: no Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallProviderinfo+xml application/emergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:hannes@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
...SDP goes here ...SDP goes here
--boundary1 --boundary1--
Content-Type: application/pidf+xml Content-Type: application/emergencyCallData.DevInfo+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
...PIDF-LO goes here <dev:emergencyCallData.DevInfo
xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dev:id>12345</svc:id>
<dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
</dev:emergencyCallData.DevInfo>
--boundary1-- --boundary1--
Figure 12: Example: Attaching Additional Data per Reference in a SIP Content-Type: application/emergencyCallData.ProviderInfo+xml
INVITE. Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:emergencyCallData.ProviderInfo
xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<pi:id>12345</pi:id>
<pi:DataProviderString>Hannes Tschofenig
</pi:DataProviderString>
<pi:TypeOfProvider>Other</pi:TypeOfProvider>
<pi:ContactURI>sip:hannes@example.com</pi:ContactURI>
<pi:Language>EN</pi:Language>
<xc:DataProviderContact
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>Hannes Tschofenig</text></fn>
<n>
<surname>Hannes</surname>
<given>Tschofenig</given>
<additional/>
<prefix/>
<suffix>Dipl. Ing.</suffix>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>de</language-tag>
</lang>
<lang>
<parameters><pref><integer>2</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>Hannes Tschofenig
Linnoitustie 6
Espoo, Finland
02600</text></label>
</parameters>
<pobox/>
<ext/>
<street>Linnoitustie 6</street>
<locality>Espoo</locality>
<region>Uusimaa</region>
<code>02600</code>
<country>Finland</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>tel:+358 50 4871445</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>hannes.tschofenig@nsn.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:60.210796,24.812924</uri>
</geo>
<key>
<parameters>
<type><text>home</text></type>
</parameters>
<uri>https://www.example.com/key.asc
</uri>
</key>
<tz><text>Finland/Helsinki</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://example.com/hannes.tschofenig</uri>
</url>
</vcard>
</xc:DataProviderContact>
</pi:emergencyCallData.ProviderInfo>
--boundary1--
Content-Type: application/emergencyCall.SvcInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<svc:emergencyCall.SvcInfo
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:id>abc123</svc:id>
<svc:SvcEnvironment>Residence</svc:SvcEnvironment>
<svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider>
<svc:SvcMobility>Unknown</svc:SvcMobility>
</svc:emergencyCall.SvcInfo>
--boundary1--
Content-Type: application/emergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<pi:emergencyCallData.ProviderInfo
xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<pi:id>abc123</pi:id>
<pi:DataProviderString>Example VoIP Provider
</pi:DataProviderString>
<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
<pi:TypeOfProvider>Service Provider</pi:TypeOfProvider>
<pi:ContactURI>sip:voip-provider@example.com</pi:ContactURI>
<pi:Language>EN</pi:Language>
<xc:DataProviderContact
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>John Doe</text></fn>
<n>
<surname>John</surname>
<given>Doe</given>
<additional/>
<prefix/>
<suffix/>
</n>
<bday><date>--0203</date></bday>
<anniversary>
<date-time>20090808T1430-0500</date-time>
</anniversary>
<gender><sex>M</sex></gender>
<lang>
<parameters><pref><integer>1</integer></pref>
</parameters>
<language-tag>en</language-tag>
</lang>
<org>
<parameters><type><text>work</text></type>
</parameters>
<text>Example VoIP Provider</text>
</org>
<adr>
<parameters>
<type><text>work</text></type>
<label><text>John Doe
Downing Street 10
London, UK</text></label>
</parameters>
<pobox/>
<ext/>
<street>Downing Street 10</street>
<locality>London</locality>
<region/>
<code>SW1A 2AA</code>
<country>UK</country>
</adr>
<tel>
<parameters>
<type>
<text>work</text>
<text>voice</text>
</type>
</parameters>
<uri>sips:john.doe@example.com</uri>
</tel>
<email>
<parameters><type><text>work</text></type>
</parameters>
<text>john.doe@example.com</text>
</email>
<geo>
<parameters><type><text>work</text></type>
</parameters>
<uri>geo:51.503396, 0.127640</uri>
</geo>
<tz><text>Europe/London</text></tz>
<url>
<parameters><type><text>home</text></type>
</parameters>
<uri>http://www.example.com/john.doe</uri>
</url>
</vcard>
</xc:DataProviderContact>
</pi:emergencyCallData.ProviderInfo>
Figure 13: VoIP Provider sending SIP INVITE with Additional Data.
Finally, the PSAP requests location information from the access
network operator. The response is shown in Figure 14. Along with
the location information additional data is provided in the
<Provided-By> element of the PIDF-LO.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1"> <dm:device id="target123-1">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
skipping to change at page 35, line 15 skipping to change at page 44, line 33
<NAM>Video Rental Store</NAM> <NAM>Video Rental Store</NAM>
<PC>2500</PC> <PC>2500</PC>
<ROOM>Westerns and Classics</ROOM> <ROOM>Westerns and Classics</ROOM>
<PLC>store</PLC> <PLC>store</PLC>
<POBOX>Private Box 15</POBOX> <POBOX>Private Box 15</POBOX>
</civicAddress> </civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gbp:retransmission-allowed>true <gbp:retransmission-allowed>true
</gbp:retransmission-allowed> </gbp:retransmission-allowed>
<gbp:retention-expiry>2013-07-10T20:00:00Z <gbp:retention-expiry>2013-12-10T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
<provided-by
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"> <provided-by
xmlns="urn:ietf:params:xml:ns:emergencycalldata">
<emergencyCallDataReference purpose="emergencyCallData.SvcInfo" <emergencyCallDataReference purpose="emergencyCallData.SvcInfo"
ref="https://example.com/ref2"/> ref="https://example.com/ref2"/>
<emergencyCallDataValue> <emergencyCallDataValue>
<emergencyCall.ProviderInfo <emergencyCallData.ProviderInfo
xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"> xmlns="urn:ietf:params:xml:ns:emergencycalldata:providerinfo">
<DataProviderString>University of California, Irvine <DataProviderString>University of California, Irvine
</DataProviderString> </DataProviderString>
<ProviderID>urn:nena:companyid:uci</ProviderID> <ProviderID>urn:nena:companyid:uci</ProviderID>
<ProviderIDSeries>NENA</ProviderIDSeries> <ProviderIDSeries>NENA</ProviderIDSeries>
<TypeOfProvider>Other</TypeOfProvider> <TypeOfProvider>Other</TypeOfProvider>
<ContactURI>tel:+1 9498245222</ContactURI> <ContactURI>tel:+1 9498245222</ContactURI>
<Language>EN</Language> <Language>EN</Language>
</emergencyCall.ProviderInfo> </emergencyCallData.ProviderInfo>
<emergencyCall.Comment <emergencyCallData.Comment
xmlns="urn:ietf:params:xml:ns:emergencyCall.Comment"> xmlns="urn:ietf:params:xml:ns:emergencycalldata:comment">
<Comment xml:lang="en">This is an example text.</Comment> <Comment xml:lang="en">This is an example text.</Comment>
</emergencyCall.Comment> </emergencyCallData.Comment>
</emergencyCallDataValue> </emergencyCallDataValue>
</provided-by> </provided-by>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:00-0d-4b-30-72-df</dm:deviceID>
<dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp> <dm:timestamp>2013-07-09T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
Figure 13: Example: Including Additional Data via the Provided-By
Element in a PIDF-LO. Figure 14: Access Network Provider returning PIDF-LO with Additional
Data.
6. XML Schemas 6. XML Schemas
This section defines the XML schemas of the five data blocks. This section defines the XML schemas of the five data blocks.
Additionally, the Provided-By schema is specified. Additionally, the Provided-By schema is specified.
6.1. emergencyCall.ProviderInfo XML Schema 6.1. emergencyCallData.ProviderInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" targetNamespace=
"urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0" xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> 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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"> <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0">
skipping to change at page 36, line 32 skipping to change at page 46, line 4
attributeFormDefault="unqualified"> 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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"> <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0">
<xs:simpleType name="iso3166a2"> <xs:simpleType name="iso3166a2">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}"/> <xs:pattern value="[A-Z]{2}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element <xs:element
name="emergencyCall.ProviderInfo" name="emergencyCallData.ProviderInfo"
type="pi:ProviderInfoType"/> type="pi:ProviderInfoType"/>
<xs:simpleType name="SubcontractorPriorityType"> <xs:simpleType name="SubcontractorPriorityType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="sub"/> <xs:enumeration value="sub"/>
<xs:enumeration value="main"/> <xs:enumeration value="main"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="ProviderInfoType"> <xs:complexType name="ProviderInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="DataProviderString" <xs:element name="DataProviderString"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<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="ProviderIDSeries" <xs:element name="ProviderIDSeries"
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="pi:iso3166a2" <xs:element name="Language" type="pi:iso3166a2"
minOccurs="0" maxOccurs="unbounded" /> minOccurs="0" maxOccurs="unbounded" />
<xs:element name="DataProviderContact" <xs:element name="DataProviderContact"
type="xc:vcardType" minOccurs="0" type="xc:vcardType" minOccurs="0"
maxOccurs="1"/> maxOccurs="1"/>
<xs:element name="SubcontratorPrincipal" <xs:element name="SubcontratorPrincipal"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="SubcontractorPriority" <xs:element name="SubcontractorPriority"
type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/> type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
skipping to change at page 37, line 28 skipping to change at page 47, line 10
<xs:element name="SubcontractorPriority" <xs:element name="SubcontractorPriority"
type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/> type="pi:SubcontractorPriorityType" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 14: emergencyCall.ProviderInfo XML Schema. Figure 15: emergencyCallData.ProviderInfo XML Schema.
6.2. emergencyCall.SvcInfo XML Schema 6.2. emergencyCallData.SvcInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" targetNamespace=
"urn:ietf:params:xml:ns:emergencycalldata:svcinfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" xmlns:svc="urn:ietf:params:xml:ns:emergencycalldata:svcinfo"
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="emergencyCall.SvcInfo" type="svc:SvcInfoType"/> <xs:element name="emergencyCallData.SvcInfo" type="svc:SvcInfoType"/>
<xs:complexType name="SvcInfoType"> <xs:complexType name="SvcInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SvcEnvironment" <xs:element name="SvcEnvironment"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SvcDelByProvider" <xs:element name="SvcDelByProvider"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SvcMobility" <xs:element name="SvcMobility"
type="xs:string" minOccurs="1" maxOccurs="1"/> type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Link" <xs:element name="Link"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 16: emergencyCallData.SvcInfo XML Schema.
Figure 15: emergencyCall.SvcInfo XML Schema. 6.3. emergencyCallData.DevInfo XML Schema
6.3. emergencyCall.DevInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo" targetNamespace="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
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="emergencyCall.DevInfo" type="dev:DevInfoType"/> <xs:element name="emergencyCallData.DevInfo" type="dev:DevInfoType"/>
<xs:complexType name="DevInfoType"> <xs:complexType name="DevInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<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"/>
<xs:element name="DeviceSpecificData" <xs:element name="DeviceSpecificData"
type="xs:anyURI" minOccurs="0" maxOccurs="1"/> type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
<xs:element name="DeviceSpecificType" <xs:element name="DeviceSpecificType"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
skipping to change at page 39, line 10 skipping to change at page 49, line 7
<xs:element name="DeviceSpecificType" <xs:element name="DeviceSpecificType"
type="xs:string" minOccurs="0" maxOccurs="1"/> type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 16: emergencyCall.DevInfo XML Schema. Figure 17: emergencyCallData.DevInfo XML Schema.
6.4. emergencyCall.SubInfo XML Schema 6.4. emergencyCallData.SubInfo XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo" targetNamespace=
"urn:ietf:params:xml:ns:emergencycalldata:subinfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo" xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:subinfo"
xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0" xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"
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:import namespace="urn:ietf:params:xml:ns:vcard-4.0"/> <xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"/>
<xs:element name="emergencyCall.SubInfo" type="sub:SubInfoType"/> <xs:element name="emergencyCallData.SubInfo" type="sub:SubInfoType"/>
<xs:complexType name="SubInfoType"> <xs:complexType name="SubInfoType">
<xs:complexContent> <xs:complexContent>
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="SubscriberData" type="xc:vcardType" <xs:element name="SubscriberData" type="xc:vcardType"
minOccurs="0" maxOccurs="1" /> minOccurs="0" maxOccurs="1" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="privacyRequested" type="xs:boolean" use="required"/> <xs:attribute name="privacyRequested" type="xs:boolean" use="required"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 17: emergencyCall.SubInfo XML Schema. Figure 18: emergencyCallData.SubInfo XML Schema.
6.5. emergencyCall.Comment XML Schema 6.5. emergencyCallData.Comment XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:emergencyCall.Comment" targetNamespace=
"urn:ietf:params:xml:ns:emergencycalldata:comment"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment" xmlns:com="urn:ietf:params:xml:ns:emergencycalldata:comment"
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="emergencyCall.Comment" type="com:CommentType"/> <xs:element name="emergencyCallData.Comment" type="com:CommentType"/>
<xs:complexType name="CommentType"> <xs:complexType name="CommentType">
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Comment" <xs:element name="Comment"
type="com:CommentSubType" minOccurs="0" type="com:CommentSubType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="CommentSubType"> <xs:complexType name="CommentSubType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/> <xs:attribute ref="xml:lang"/>
</xs:extension> </xs:extension>
skipping to change at page 40, line 36 skipping to change at page 50, line 41
<xs:complexType name="CommentSubType"> <xs:complexType name="CommentSubType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/> <xs:attribute ref="xml:lang"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 18: EmergencyCall.Comment XML Schema. Figure 19: EmergencyCallData.Comment XML Schema.
6.6. Provided-By XML Schema 6.6. Provided-By XML Schema
This section defines the Provided-By schema. This section defines the Provided-By schema.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace= targetNamespace=
"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData" "urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData" xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" xmlns:svc="urn:ietf:params:xml:ns:emergencycalldata:svcinfo"
xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo" xmlns:sub="urn:ietf:params:xml:ns:emergencycalldata:subinfo"
xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment" xmlns:com="urn:ietf:params:xml:ns:emergencycalldata:comment"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.Comment"/> <xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"/>
<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SubInfo"/> <xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:svcinfo"/>
<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.DevInfo"/> <xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:devinfo"/>
<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"/> <xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:subinfo"/>
<xs:import namespace="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"/> <xs:import namespace="urn:ietf:params:xml:ns:emergencycalldata:comment"/>
<xs:element name="provided-by" type="ad:provided-by-Type"/> <xs:element name="provided-by" type="ad:provided-by-Type"/>
<xs:complexType name="provided-by-Type"> <xs:complexType name="provided-by-Type">
<xs:sequence> <xs:sequence>
<xs:element name="id"
type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="emergencyCallDataReference" <xs:element name="emergencyCallDataReference"
type="ad:ByRefType" type="ad:ByRefType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emergencyCallDataValue" <xs:element name="emergencyCallDataValue"
type="ad:emergencyCallDataValueType" type="ad:emergencyCallDataValueType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
skipping to change at page 42, line 4 skipping to change at page 52, line 10
<xs:any namespace="##other" minOccurs="0" <xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/> maxOccurs="unbounded" processContents="lax"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="purpose" type="xs:anyURI" <xs:attribute name="purpose" type="xs:anyURI"
use="required"/> use="required"/>
<xs:attribute name="ref" type="xs:anyURI" <xs:attribute name="ref" type="xs:anyURI"
use="required"/> use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- Additional Data By Value --> <!-- Additional Data By Value -->
<xs:complexType name="emergencyCallDataValueType"> <xs:complexType name="emergencyCallDataValueType">
<xs:sequence> <xs:sequence>
<xs:element name="emergencyCall.ProviderInfo" <xs:element name="emergencyCallData.ProviderInfo"
type="pi:ProviderInfoType" type="pi:ProviderInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emergencyCall.SvcInfo" <xs:element name="emergencyCallData.SvcInfo"
type="svc:SvcInfoType" type="svc:SvcInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emergencyCall.DevInfo" <xs:element name="emergencyCallData.DevInfo"
type="dev:DevInfoType" type="dev:DevInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emergencyCall.SubInfo" <xs:element name="emergencyCallData.SubInfo"
type="sub:SubInfoType" type="sub:SubInfoType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emergencyCall.Comment" <xs:element name="emergencyCallData.Comment"
type="com:CommentType" type="com:CommentType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 19: Provided-By XML Schema. Figure 20: Provided-By XML Schema.
7. Security Considerations 7. 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 public key infrastructure (PKI) that has global scope creation of a public key infrastructure (PKI) that has global scope
may be difficult, the alternatives to creating devices and services may be difficult, the alternatives to creating devices and services
that can provide critical information securely are more daunting. that can provide critical information securely are more daunting.
The provider may enforce any policy it wishes to use, but PSAPs and The provider may enforce any policy it wishes to use, but PSAPs and
responder agencies should deploy a PKI so that providers of responder agencies should deploy a PKI so that providers of
additional data can check the certificate of the client and decide additional data can check the certificate of the client and decide
the appropriate policy to enforce based on that certificate. the appropriate policy to enforce based on that certificate.
skipping to change at page 46, line 4 skipping to change at page 56, line 14
intermediaries may also introduce additional privacy risk. intermediaries may also introduce additional privacy risk.
Therefore, in situations where the conveyed information raises Therefore, in situations where the conveyed information raises
privacy concerns and intermediaries are involved transmitting a privacy concerns and intermediaries are involved transmitting a
reference is more appropriate (assuming proper access control reference is more appropriate (assuming proper access control
policies are available for distinguishing the different entities policies are available for distinguishing the different entities
dereferencing the reference). Without access control policies any dereferencing the reference). Without access control policies any
party in possession of the reference is able to resolve the reference party in possession of the reference is able to resolve the reference
and to obtain the data, including intermediaries. and to obtain the data, including intermediaries.
9. IANA Considerations 9. IANA Considerations
9.1. Registry creation 9.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 in Additional Data'. The following sub-registries are created for this
Emergency Call Additional Data: registry.
9.1.1. Provider ID Series Registry 9.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 'Additional Call Data
Provider ID Series'. As defined in [RFC5226], this registry operates Provider ID Series'. As defined in [RFC5226], this registry operates
under "Expert Review" rules. The expert should determine that the under "Expert Review" rules. The expert should determine that the
entity requesting a new value is a legitimate issuer of service entity requesting a new value is a legitimate issuer of service
provider IDs suitable for use in Additional Call Data. provider IDs suitable for use in Additional Call Data.
The content of this registry includes: The content of this registry includes:
Name: The identifier which will be used in the ProviderIDSeries Name: The identifier which will be used in the ProviderIDSeries
element 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 20. The initial set of values is listed in Figure 21.
+-----------+--------------------------+----------------------+ +-----------+--------------------------+----------------------+
| Name | Source | URL | | Name | Source | URL |
+-----------+--------------------------+----------------------+ +-----------+--------------------------+----------------------+
| NENA | National Emergency | http://www.nena.org | | NENA | National Emergency | http://www.nena.org |
| | Number Association | | | | Number Association | |
| EENA | European Emergency | http://www.eena.org | | EENA | European Emergency | http://www.eena.org |
| | Number Association | | | | Number Association | |
+-----------+--------------------------+----------------------+ +-----------+--------------------------+----------------------+
Figure 20: Provider ID Series Registry. Figure 21: Provider ID Series Registry.
9.1.2. Service Provider Type Registry 9.1.2. Service Environment Registry
This document creates a new sub-registry called 'Additional Call
Service Environment'. As defined in [RFC5226], this registry
operates under "Expert Review" rules. The expert should determine
that the entity requesting a new value is relevant for this service
element.
The content of this registry includes:
Token: The value to be used in <SvcEnvironment> element.
Description: A short description of the token.
The initial set of values is listed in Figure 22.
+-----------+--------------------------+
| Token | Description |
+-----------+--------------------------+
| Business | [[This RFC]] |
| Residence | [[This RFC]] |
+-----------+--------------------------+
Figure 22: Service Environment Registry.
9.1.3. 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:
Name: Value to be used in TypeOfServiceProvider. Name: The value to be used in TypeOfServiceProvider.
Description: A short description of the type of service provider Description: A short description of the type of service provider
The initial set of values is defined in Figure 1. The initial set of values is defined in Figure 1.
9.1.3. Service Delivered Registry 9.1.4. Service Delivered Registry
This document creates a new sub-registry called 'Service Delivered'. This document creates a new sub-registry called 'Service Delivered'.
As defined in [RFC5226], this registry operates under "Expert Review" As defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should consider whether the proposed service is rules. The expert should consider whether the proposed service is
unique from existing services and the definition of the service will unique from existing services and the definition of the service will
be clear to implementors and PSAPS/responders. be clear to implementors and PSAPS/responders.
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.
The initial set of values are defined in Figure 3. The initial set of values are defined in Figure 3.
9.1.4. Device Classification Registry 9.1.5. Device Classification Registry
This document creates a new sub-registry called 'Device This document creates a new sub-registry called 'Device
Classification'. As defined in [RFC5226], this registry operates Classification'. As defined in [RFC5226], this registry operates
under "Expert Review" rules. The expert should consider whether the under "Expert Review" rules. The expert should consider whether the
proposed class is unique from existing classes and the definition of proposed class is unique from existing classes and the definition of
the class will be clear to implementors and PSAPS/responders. the class will be clear to implementors and PSAPS/responders.
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.
The initial set of values are defined in Figure 5. The initial set of values are defined in Figure 5.
9.1.5. Device ID Type Type Registry 9.1.6. Device ID Type Type Registry
This document creates a new sub-registry called 'Additional Call Data This document creates a new sub-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. The expert should ascertain that the under "Expert Review" rules. The expert should ascertain that the
proposed type is well understood, and provides the information useful proposed type is well understood, and provides the information useful
to PSAPs and responders to uniquely identify a device. to PSAPs and responders to uniquely identify a device.
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 type of device id. Description: Short description identifying type of device id.
The initial set of values are defined in Figure 6. The initial set of values are defined in Figure 6.
9.1.6. Device/Service Data Type Registry 9.1.7. 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 Registry'. As defined in [RFC5226], this registry operates
under "Expert Review" and "Specification Required" rules. The expert under "Expert Review" and "Specification Required" rules. The expert
should ascertain that the proposed type is well understood, and should ascertain that the proposed type is well understood, and
provides information useful to PSAPs and responders. The provides information useful to PSAPs and responders. The
specification must contain a complete description of the data, and a specification must contain a complete description of the data, and a
precise format specification suitable to allow interoperable precise format specification suitable to allow interoperable
implementations. implementations.
The content of this registry includes: The content of this registry includes:
Name: Enumeration token of the data type. Name: Enumeration token of the data type.
Description: Short description identifying the the data. Description: Short description identifying the 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 21. The initial set of values are listed in Figure 23.
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| Token | Description | Specification | | Token | Description | Specification |
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 | | IEE1512 | Common Incident Management Message Set | IEEE 1512-2006 |
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
| VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS | | VEDS | Vehicle Emergency Data Set | APCO/NENA VEDS |
+---------+----------------------------------------+----------------+ +---------+----------------------------------------+----------------+
Figure 21: Device/Service Data Type Registry. Figure 23: Device/Service Data Type Registry.
9.1.7. Additional Data Blocks Registry 9.1.8. Additional Data Blocks Registry
This document creates a new sub-registry called 'Additional Data This document creates a new sub-registry called 'Additional Data
Blocks' in the purpose registry established by RFC 3261 [RFC3261]. Blocks' in the purpose registry established by RFC 3261 [RFC3261].
As defined in [RFC5226], this registry operates under "Expert Review" As defined in [RFC5226], this registry operates under "Expert Review"
and "Specification Required" rules. The expert is responsible for and "Specification Required" rules. The expert is responsible for
verifying that the document contains a complete and clear verifying that the document contains a complete and clear
specification and the proposed functionality does not obviously specification and the proposed functionality does not obviously
duplicate existing functionality. duplicate existing functionality.
The content of this registry includes: The content of this registry includes:
Name: Element Name of enclosing block. Name: Element Name of enclosing block.
Reference: The document that describes the block Reference: The document that describes the block
The initial set of values are listed in Figure 22. The initial set of values are listed in Figure 24.
+--------------+------------+ +--------------+------------+
| Token | Reference | | Token | Reference |
+--------------+------------+ +--------------+------------+
| ProviderInfo | [This RFC] | | ProviderInfo | [This RFC] |
| SvcInfo | [This RFC] | | SvcInfo | [This RFC] |
| DevInfo | [This RFC] | | DevInfo | [This RFC] |
| Subscriber | [This RFC] | | Subscriber | [This RFC] |
| Comment | [This RFC] | | Comment | [This RFC] |
+--------------+------------+ +--------------+------------+
Figure 22: Additional Data Blocks Registry. Figure 24: Additional Data Blocks Registry.
9.2. 'emergencyCallData' Purpose Parameter Value 9.2. 'emergencyCallData' Purpose Parameter Value
This document defines the 'emergencyCall' 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 emergencyCall [This RFC] Call-Info purpose emergencyCallData [This RFC]
9.3. URN Sub-Namespace Registration for provided-by Registry Entry 9.3. URN Sub-Namespace Registration for provided-by Registry Entry
This section registers the namespace specified in Section 9.5.1 in This section registers the namespace specified in Section 9.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 schema used by this document is The schema for the provided-by schema used by this document is
specified in Section 6.6. specified in Section 6.6.
9.4. MIME Registrations 9.4. MIME Registrations
9.4.1. MIME Content-type Registration for 'application/ 9.4.1. MIME Content-type Registration for 'application/
emergencyCall.ProviderInfo+xml' emergencyCallData.ProviderInfo+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: emergencyCall.ProviderInfo+xml MIME subtype name: emergencyCallData.ProviderInfo+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Indicates the character encoding of Optional parameters: charset Indicates the character encoding of
enclosed XML. enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 3023 [RFC3023]. Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 50, line 50 skipping to change at page 61, line 37
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>
9.4.2. MIME Content-type Registration for 'application/ 9.4.2. MIME Content-type Registration for 'application/
emergencyCall.SvcInfo+xml' emergencyCallData.SvcInfo+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: emergencyCall.SvcInfo+xml MIME subtype name: emergencyCallData.SvcInfo+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Indicates the character encoding of Optional parameters: charset Indicates the character encoding of
enclosed XML. enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 3023 [RFC3023]. Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 51, line 50 skipping to change at page 62, line 37
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>
9.4.3. MIME Content-type Registration for 'application/ 9.4.3. MIME Content-type Registration for 'application/
emergencyCall.DevInfo+xml' emergencyCallData.DevInfo+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: emergencyCall.DevInfo+xml MIME subtype name: emergencyCallData.DevInfo+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Indicates the character encoding of Optional parameters: charset Indicates the character encoding of
enclosed XML. enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 3023 [RFC3023]. Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 52, line 50 skipping to change at page 63, line 37
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>
9.4.4. MIME Content-type Registration for 'application/ 9.4.4. MIME Content-type Registration for 'application/
emergencyCall.SubInfo+xml' emergencyCallData.SubInfo+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: emergencyCall.SubInfo+xml MIME subtype name: emergencyCallData.SubInfo+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Indicates the character encoding of Optional parameters: charset Indicates the character encoding of
enclosed XML. enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 3023 [RFC3023]. Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 53, line 50 skipping to change at page 64, line 37
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>
9.4.5. MIME Content-type Registration for 'application/ 9.4.5. MIME Content-type Registration for 'application/
emergencyCall.Comment+xml' emergencyCallData.Comment+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: emergencyCall.Comment+xml MIME subtype name: emergencyCallData.Comment+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Indicates the character encoding of Optional parameters: charset Indicates the character encoding of
enclosed XML. enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
Section 3.2 of RFC 3023 [RFC3023]. Section 3.2 of RFC 3023 [RFC3023].
skipping to change at page 54, line 51 skipping to change at page 65, line 38
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>
9.5. URN Sub-Namespace Registration 9.5. URN Sub-Namespace Registration
9.5.1. Registration for urn:ietf:params:xml:ns:emergencyCallAddlData 9.5.1. Registration for urn:ietf:params:xml:ns:emergencycalldata
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:emergencyCallAddlData URI: urn:ietf:params:xml:ns:emergencycalldata
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
skipping to change at page 55, line 32 skipping to change at page 66, line 20
<title>Namespace for Additional Emergency Call Data</title> <title>Namespace for Additional Emergency Call Data</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>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
9.5.2. Registration for 9.5.2. Registration for
urn:ietf:params:xml:ns:emergencyCallProviderInfo urn:ietf:params:xml:ns:emergencycalldata:providerinfo
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:emergencyCallProviderInfo URI: urn:ietf:params:xml:ns:emergencycalldata:providerinfo
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
skipping to change at page 56, line 20 skipping to change at page 67, line 6
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
9.5.3. Registration for urn:ietf:params:xml:ns:emergencyCall.SvcInfo 9.5.3. Registration for
urn:ietf:params:xml:ns:emergencycalldata:svcinfo
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:emergencyCall.SvcInfo URI: urn:ietf:params:xml:ns:emergencycalldata:svcinfo
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
skipping to change at page 57, line 5 skipping to change at page 67, line 38
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
9.5.4. Registration for urn:ietf:params:xml:ns:emergencyCall.DevInfo 9.5.4. Registration for
urn:ietf:params:xml:ns:emergencycalldata:devinfo
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:emergencyCall.DevInfo URI: urn:ietf:params:xml:ns:emergencycalldata:devinfo
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
skipping to change at page 57, line 36 skipping to change at page 68, line 28
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
9.5.5. Registration for urn:ietf:params:xml:ns:emergencyCall.SubInfo 9.5.5. Registration for
urn:ietf:params:xml:ns:emergencycalldata:subinfo
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:emergencyCall.SubInfo URI: urn:ietf:params:xml:ns:emergencycalldata:subinfo
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
skipping to change at page 58, line 22 skipping to change at page 69, line 16
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
9.5.6. Registration for urn:ietf:params:xml:ns:emergencyCall.Comment 9.5.6. Registration for
urn:ietf:params:xml:ns:emergencycalldata:comment
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:emergencyCall.Comment URI: urn:ietf:params:xml:ns:emergencycalldata:comment
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:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
skipping to change at page 59, line 12 skipping to change at page 70, line 10
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
9.6. Schema Registrations 9.6. Schema Registrations
This specification registers five schemas, as per the guidelines in This specification registers five schemas, as per the guidelines in
RFC 3688 [RFC3688]. RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:schema:additional- URI: urn:ietf:params:xml:schema:emergencycalldata:providerinfo
data:emergencyCallProviderInfo
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 14. XML: The XML schema can be found in Figure 15.
URI: urn:ietf:params:xml:schema:additional-data:addCallSvcInfo URI: urn:ietf:params:xml:schema:emergencycalldata:svcinfo
Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as Registrant Contact: IETF, ECRIT Working Group (ectit@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 15. XML: The XML schema can be found in Figure 16.
URI: urn:ietf:params:xml:schema:additional- URI: urn:ietf:params:xml:schema:emergencycalldata:devinfo
data:emergencyCallDevInfo
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 16. XML: The XML schema can be found in Figure 17.
URI: urn:ietf:params:xml:schema:additional- URI: urn:ietf:params:xml:schema:emergencycalldata:subinfo
data:emergencyCall.SubInfo
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 Section 6.4. XML: The XML schema can be found in Section 6.4.
URI: urn:ietf:params:xml:schema:additional- URI: urn:ietf:params:xml:schema:emergencycalldata:comment
data:emergencyCall.Comment
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 Section 6.5. XML: The XML schema can be found in Section 6.5.
9.7. VCard Parameter Value Registration 9.7. VCard Parameter Value Registration
This document registers a new value in the vCARD Parameter Values This document registers a new value in the vCARD Parameter Values
registry as defined by [RFC6350] with the following template: registry as defined by [RFC6350] with the following template:
skipping to change at page 61, line 42 skipping to change at page 72, line 37
Initiation Protocol (SIP)", RFC 5621, September 2009. Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC
6351, August 2011. 6351, August 2011.
11.2. Informational References 11.2. Informational References
[I-D.gellens-negotiating-human-language]
Randy, R., "Negotiating Human Language Using SDP", draft-
gellens-negotiating-human-language-02 (work in progress),
February 2013.
[I-D.ietf-ecrit-psap-callback]
Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
Patel, "Public Safety Answering Point (PSAP) Callback",
draft-ietf-ecrit-psap-callback-13 (work in progress),
October 2013.
[I-D.ietf-geopriv-relative-location] [I-D.ietf-geopriv-relative-location]
Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.
Thomson, "Relative Location Representation", draft-ietf- Thomson, "Relative Location Representation", draft-ietf-
geopriv-relative-location-08 (work in progress), September geopriv-relative-location-08 (work in progress), September
2013. 2013.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
 End of changes. 199 change blocks. 
284 lines changed or deleted 756 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/