< draft-ietf-ecrit-additional-data-12.txt   draft-ietf-ecrit-additional-data-13.txt >
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: April 19, 2014 Nokia Solutions and Networks Expires: April 19, 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 October 16, 2013
Additional Data related to an Emergency Call Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data-12.txt draft-ietf-ecrit-additional-data-13.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 3, line 11 skipping to change at page 3, line 11
3.3.7. Device/Service Specific Additional Data Structure 3.3.7. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 21 Type . . . . . . . . . . . . . . . . . . . . . . . . 21
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 . . . 22
3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22 3.3.9. emergencyCall.DevInfo Example . . . . . . . . . . . . 22
3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 23 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 23
3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 23 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 23
3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 24 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 24
3.4.3. emergencyCall.SubInfo Example . . . . . . . . . . . . 24 3.4.3. emergencyCall.SubInfo Example . . . . . . . . . . . . 24
3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 26 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27 3.5.2. emergencyCall.Comment Example . . . . . . . . . . . . 27
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Transmitting Blocks using the Call-Info Header . . . . . 29 4.1. Transmitting Blocks using the Call-Info Header . . . . . 29
4.2. Transmitting Blocks by Reference using the Provided-By 4.2. Transmitting Blocks by Reference using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 Element . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3. Transmitting Blocks by Value using the Provided-By 4.3. Transmitting Blocks by Value using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 30 Element . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4. The Content-Disposition Parameter . . . . . . . . . . . . 31 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 31
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 36 6.1. emergencyCall.ProviderInfo XML Schema . . . . . . . . . . 36
6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 37 6.2. emergencyCall.SvcInfo XML Schema . . . . . . . . . . . . 37
6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 38 6.3. emergencyCall.DevInfo XML Schema . . . . . . . . . . . . 38
6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 39 6.4. emergencyCall.SubInfo XML Schema . . . . . . . . . . . . 39
6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 39 6.5. emergencyCall.Comment XML Schema . . . . . . . . . . . . 39
6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 40 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 45 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 46
9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 46 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 46
9.1.2. Service Provider Type Registry . . . . . . . . . . . 46 9.1.2. Service Provider Type Registry . . . . . . . . . . . 46
9.1.3. Service Delivered Registry . . . . . . . . . . . . . 46 9.1.3. Service Delivered Registry . . . . . . . . . . . . . 47
9.1.4. Device Classification Registry . . . . . . . . . . . 47 9.1.4. Device Classification Registry . . . . . . . . . . . 47
9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 47 9.1.5. Device ID Type Type Registry . . . . . . . . . . . . 47
9.1.6. Device/Service Data Type Registry . . . . . . . . . . 47 9.1.6. Device/Service Data Type Registry . . . . . . . . . . 48
9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48 9.1.7. Additional Data Blocks Registry . . . . . . . . . . . 48
9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 49 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 49
9.3. URN Sub-Namespace Registration for provided-by Registry 9.3. URN Sub-Namespace Registration for provided-by Registry
Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 49 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 49
9.4.1. MIME Content-type Registration for 9.4.1. MIME Content-type Registration for
'application/emergencyCall.ProviderInfo+xml' . . . . 49 'application/emergencyCall.ProviderInfo+xml' . . . . 49
9.4.2. MIME Content-type Registration for 9.4.2. MIME Content-type Registration for
'application/emergencyCall.SvcInfo+xml' . . . . . . . 50 'application/emergencyCall.SvcInfo+xml' . . . . . . . 50
9.4.3. MIME Content-type Registration for 9.4.3. MIME Content-type Registration for
skipping to change at page 4, line 13 skipping to change at page 4, line 13
9.4.5. MIME Content-type Registration for 9.4.5. MIME Content-type Registration for
'application/emergencyCall.Comment+xml' . . . . . . . 53 'application/emergencyCall.Comment+xml' . . . . . . . 53
9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 54 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 54
9.5.1. Registration for 9.5.1. Registration for
urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 54 urn:ietf:params:xml:ns:emergencyCallAddlData . . . . 54
9.5.2. Registration for 9.5.2. Registration for
urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 55 urn:ietf:params:xml:ns:emergencyCallProviderInfo . . 55
9.5.3. Registration for 9.5.3. Registration for
urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 56 urn:ietf:params:xml:ns:emergencyCall.SvcInfo . . . . 56
9.5.4. Registration for 9.5.4. Registration for
urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 56 urn:ietf:params:xml:ns:emergencyCall.DevInfo . . . . 57
9.5.5. Registration for 9.5.5. Registration for
urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 57 urn:ietf:params:xml:ns:emergencyCall.SubInfo . . . . 57
9.5.6. Registration for 9.5.6. Registration for
urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 58 urn:ietf:params:xml:ns:emergencyCall.Comment . . . . 58
9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 58 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 59
9.7. VCard Parameter Value Registration . . . . . . . . . . . 59 9.7. VCard Parameter Value Registration . . . . . . . . . . . 60
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.1. Normative References . . . . . . . . . . . . . . . . . . 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 60
11.2. Informational References . . . . . . . . . . . . . . . . 61 11.2. Informational References . . . . . . . . . . . . . . . . 61
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 62 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85
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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
created the structure of the call. NOTE: In the US, the NENA created the structure of the call. NOTE: In the US, the NENA
Company ID must appear here. Additional information can be found Company ID must appear here. Additional information can be found
at http://www.nena.org/nena-company-id. The NENA Company ID MUST at http://www.nena.org/nena-company-id. The NENA Company ID MUST
be in the form of a URI in the following format: be in the form of a URI in the following format:
urn:nena:companyid:<NENA Company ID> urn:nena:companyid:<NENA Company ID>
Reason for Need: Inform the call taker of the identity of the entity Reason for Need: Inform the call taker of the identity of the entity
providing the additional call data structure. providing the additional call data structure.
How Used by Call Taker: Where jurisdictions have lists of providers How Used by Call Taker: Where jurisdictions have lists of providers
the Data Provider ID can be useful. the Data Provider ID provides useful information about the data
source.
3.1.3. Data Provider ID Series 3.1.3. Data Provider ID Series
Data Element: Data Provider ID Series Data Element: Data Provider ID Series
Use: Conditional. If Data Provider ID is provided, Data Provider ID Use: Conditional. If Data Provider ID is provided, Data Provider ID
Series is required. Series is required.
XML Element: <ProviderIDSeries> XML Element: <ProviderIDSeries>
skipping to change at page 9, line 32 skipping to change at page 9, line 32
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| 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 | |Service Provider Subcontractor| A contractor to another kind of 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 |
|Expert Advice Provider | An SP giving expert advice | |Emergency Service Provider | An emergency service provider |
| | conveying information to another |
| | 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, |
| | video relay for sign language | | | video relay for sign language |
| | interpreting | | | interpreting |
|Other | Any other type of service provider | |Other | Any other type of service provider |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Figure 1: Type of Data Provider ID Registry. Figure 1: Type of Data Provider ID Registry.
Reason for Need: Identifies what kind of data provider this is. Reason for Need: Identifies what kind of data provider this is.
skipping to change at page 9, line 50 skipping to change at page 10, line 4
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Figure 1: Type of Data Provider ID Registry. Figure 1: Type of Data Provider ID Registry.
Reason for Need: Identifies what kind of data provider this is. Reason for Need: Identifies what kind of data provider this is.
How Used by Call Taker: To decide who to contact when further How Used by Call Taker: To decide who to contact when further
information is needed information is needed
3.1.5. Data Provider Contact URI 3.1.5. Data Provider Contact URI
Data Element: Data Provider Contact URI Data Element: Data Provider Contact URI
Use: Required Use: Required
XML Element: <ContactURI> XML Element: <ContactURI>
Description: For a service provider or access provider the contact Description: When provided by a service provider or an access
SHOULD be a contact URI. This MUST be either a tel uri or a SIP provider, this information MUST be a URI to a 24/7 support
URI. If a telephone number is the contact address it SHOULD be
provided as a tel URI, if it is provided as a SIP URI then it MUST
be in the form of sip:telephonenumber@serviceprovider:user=phone.
If the call is from a device, this would reflect the contact
information of the owner of the device. When provided by a
service or access provider, this would 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. call. If the call is from a device, this would reflect the
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
provided as a SIP URI then it MUST be in the form of
sip:telephonenumber@serviceprovider:user=phone.
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 11, line 31 skipping to change at page 11, line 31
information. information.
How Used by Call Taker: Assists call taker by providing additional How Used by Call Taker: Assists call taker by providing additional
contact information that may not be included in the SIP invite or contact information that may not be included in the SIP invite or
the PIDF-LO. the PIDF-LO.
3.1.8. Subcontractor Principal 3.1.8. Subcontractor Principal
Data Element: Subcontractor Principal Data Element: Subcontractor Principal
Use: Conditional Use: Conditional. This data is required if the Data Provider type
is subcontractor.
XML Element: <SubcontratorPrincipal> XML Element: <SubcontratorPrincipal>
Description: If the data provider is a subcontractor to another Description: If the data provider is a subcontractor to another
provider such as an access infrastructure provider or telematics provider, such as an access infrastructure provider or telematics
provider, this element contains the DataProviderString of the provider, this element contains the DataProviderString of the
service provider to indicate which provider the subcontractor is service provider to indicate which provider the subcontractor is
working for. This data is required if the Data Provider type is working for.
subcontractor.
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
skipping to change at page 20, line 8 skipping to change at page 20, line 8
Use: Optional Use: Optional
XML Element: <UniqueDeviceID> XML Element: <UniqueDeviceID>
Description: String that identifies the specific device making the Description: String that identifies the specific device making the
call or creating an event. call or creating an event.
Reason for Need: Uniquely identifies the device as opposed to any Reason for Need: Uniquely identifies the device as opposed to any
signaling identifiers encountered in the call signaling stream. signaling identifiers encountered in the call signaling stream.
How Used by Call Taker: Probably not used by the calltaker they How Used by Call Taker: Probably not used by the calltaker; they
would need to refer to management for investigation. would need to refer to management for investigation.
3.3.5. Type of Device Identifier 3.3.5. Type of Device Identifier
Data Element: Type of Device Identifier Data Element: Type of Device Identifier
Use: Conditional: must be provided if the DeviceID is provided Use: Conditional: must be provided if the DeviceID is provided
XML Element: <TypeOfDeviceID> XML Element: <TypeOfDeviceID>
skipping to change at page 23, line 37 skipping to change at page 23, line 37
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
provided. The interpretation of how this is applied is left to the provided. The interpretation of how this is applied is left to the
receiving jurisdiction as the custodians of the local regulatory receiving jurisdiction as the custodians of the local regulatory
requirements. requirements.
3.4.1. Subscriber Data Privacy Indicator 3.4.1. Subscriber Data Privacy Indicator
Attribute: privacyRequested, boolean. Attribute: privacyRequested, boolean.
Use: Mandatory: Specifically expresses the subscriber's desire for Use: Conditional. This attribute MUST be provided if the owner/
privacy. subscriber information block is not empty.
Description: In some jurisdictions subscriber services can have a Description: The subscriber data privacy indicator specifically
specific "Type of Service" which prohibits information such as the expresses the subscriber's desire for privacy. In some
name of the subscriber from being displayed. This attribute jurisdictions subscriber services can have a specific "Type of
should be used to explicitly indicate whether the subscriber Service" which prohibits information, such as the name of the
service includes such constraints. subscriber, from being displayed. This attribute should be used
to explicitly indicate whether the subscriber service includes
such constraints.
Reason for Need: Some jurisdictions require subscriber privacy to be Reason for Need: Some jurisdictions require subscriber privacy to be
observed. observed.
How Used by Call Taker: Where privacy is indicated the call taker How Used by Call Taker: Where privacy is indicated the call taker
MAY not have access to some aspects of the subscriber information. may not have access to some aspects of the subscriber information.
3.4.2. xCard for Subscriber's Data 3.4.2. xCard for Subscriber's Data
Data Element: xCARD for Subscriber's Data Data Element: xCARD for Subscriber's Data
Use: Conditional: Some services (e.g., prepaid phones, initialized Use: Conditional. Subscriber data is provided unless it is not
phones, etc.) may not have this information. available. Some services, for example prepaid phones, non-
initialized phones, etc., do not have information about the
subscriber.
XML Element: <SubscriberData> XML Element: <SubscriberData>
Description: Information known by the service provider or device Description: Information known by the service provider or device
about the subscriber; e.g., Name, Address, Individual Telephone about the subscriber; e.g., Name, Address, Individual Telephone
Number, Main Telephone Number and any other data. N, ORG (if Number, Main Telephone Number and any other data. N, ORG (if
appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more
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.
skipping to change at page 60, line 26 skipping to change at page 60, line 34
large number of participants in NENA standardization efforts, large number of participants in NENA standardization efforts,
originally in the Long Term Definition Working Group, the Data originally in the Long Term Definition Working Group, the Data
Technical Committee and most recently the Additional Data working Technical Committee and most recently the Additional Data working
group. The authors are grateful for the initial work and extended group. The authors are grateful for the initial work and extended
comments provided by many NENA participants, including Delaine comments provided by many NENA participants, including Delaine
Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James Arnold, Marc Berryman, Guy Caron, Mark Fletcher, Brian Dupras, James
Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra, Leyerle, Kathy McMahon, Christian, Militeau, Ira Pyles, Matt Serra,
and Robert (Bob) Sherry. and Robert (Bob) Sherry.
We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin We would also like to thank Paul Kyzivat, Gunnar Hellstrom, Martin
Thomson, Keith Drage, and Laura Liess for their review comments. Thomson, Keith Drage, Laura Liess, and Barbara Stark for their review
comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
 End of changes. 24 change blocks. 
38 lines changed or deleted 44 lines changed or added

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