draft-ietf-ecrit-car-crash-17.txt   draft-ietf-ecrit-car-crash-18.txt 
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Core Technology Consulting Internet-Draft Core Technology Consulting
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: April 20, 2017 NeuStar, Inc. Expires: April 21, 2017 NeuStar, Inc.
H. Tschofenig H. Tschofenig
Individual Individual
October 17, 2016 October 18, 2016
Next-Generation Vehicle-Initiated Emergency Calls Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-17.txt draft-ietf-ecrit-car-crash-18.txt
Abstract Abstract
This document describes how to use IP-based emergency services This document describes how to use IP-based emergency services
mechanisms to support the next generation of emergency calls placed mechanisms to support the next generation of emergency calls placed
by vehicles (automatically in the event of a crash or serious by vehicles (automatically in the event of a crash or serious
incident, or manually invoked by a vehicle occupant) and conveying incident, or manually invoked by a vehicle occupant) and conveying
vehicle, sensor, and location data related to the crash or incident. vehicle, sensor, and location data related to the crash or incident.
Such calls are often referred to as "Automatic Crash Notification" Such calls are often referred to as "Automatic Crash Notification"
(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 20, 2017. This Internet-Draft will expire on April 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 45 skipping to change at page 2, line 45
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8
5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9
6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13 7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 14
8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16
10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 18 10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17
10.1. New values for the 'action' attribute' . . . . . . . . . 19 10.1. New values for the 'action' attribute' . . . . . . . . . 18
10.2. Request Example . . . . . . . . . . . . . . . . . . . . 20 10.2. Request Example . . . . . . . . . . . . . . . . . . . . 19
10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 20 10.3. The <ack> element . . . . . . . . . . . . . . . . . . . 19
10.4. The <capabilities> element . . . . . . . . . . . . . . . 21 10.4. The <capabilities> element . . . . . . . . . . . . . . . 20
11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 23 12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22
12.1. Overall Description . . . . . . . . . . . . . . . . . . 23 12.1. Overall Description . . . . . . . . . . . . . . . . . . 22
12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 24 12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23
12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24 12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23
12.4. Info Package Parameters . . . . . . . . . . . . . . . . 24 12.4. Info Package Parameters . . . . . . . . . . . . . . . . 23
12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24 12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23
12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24 12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24
12.7. Info Package Usage Restrictions . . . . . . . . . . . . 25 12.7. Info Package Usage Restrictions . . . . . . . . . . . . 24
12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25 12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24
12.9. Info Package Security Considerations . . . . . . . . . . 25 12.9. Info Package Security Considerations . . . . . . . . . . 25
12.10. Implementation Details . . . . . . . . . . . . . . . . . 26 12.10. Implementation Details . . . . . . . . . . . . . . . . . 25
12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26 12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
16.1. MIME Content-type Registration for 16.1. MIME Media Type Registration for
'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32
16.2. Registration of the 'VEDS' entry in the Emergency Call 16.2. Registration of the 'VEDS' entry in the Emergency Call
Additional Data registry . . . . . . . . . . . . . . . . 33 Additional Data registry . . . . . . . . . . . . . . . . 33
16.3. New Action Values . . . . . . . . . . . . . . . . . . . 34 16.3. New Action Values . . . . . . . . . . . . . . . . . . . 33
16.4. Static Message Registry . . . . . . . . . . . . . . . . 34 16.4. Static Message Registry . . . . . . . . . . . . . . . . 34
16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35 16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35
16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36 16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
18. Changes from Previous Versions . . . . . . . . . . . . . . . 37 18. Changes from Previous Versions . . . . . . . . . . . . . . . 37
18.1. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 37 18.1. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 37
18.2. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 18.2. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38
18.3. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 18.3. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38
18.4. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 18.4. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
18.5. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 18.5. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
18.6. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 18.6. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
18.7. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 18.7. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
18.8. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 18.8. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
18.9. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 18.9. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39
18.10. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 18.10. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39
18.11. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 18.11. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39
18.12. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 18.12. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
18.13. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 18.13. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
18.14. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 18.14. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
18.15. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 18.15. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
18.16. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 18.16. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40
18.17. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 18.17. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40
18.18. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 18.18. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
18.19. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
19.1. Normative References . . . . . . . . . . . . . . . . . . 40 19.1. Normative References . . . . . . . . . . . . . . . . . . 40
19.2. Informative references . . . . . . . . . . . . . . . . . 41 19.2. Informative references . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document re-uses terminology defined in Section 3 of [RFC5012]. This document re-uses terminology defined in Section 3 of [RFC5012].
skipping to change at page 7, line 13 skipping to change at page 7, line 13
set of vehicle (crash) data, specifically, the Vehicle Emergency Data set of vehicle (crash) data, specifically, the Vehicle Emergency Data
Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This
document is an extension of [I-D.ietf-ecrit-ecall], with the document is an extension of [I-D.ietf-ecrit-ecall], with the
differences being that this document makes the MSD data set optional differences being that this document makes the MSD data set optional
and VEDS mandatory, and adds new attribute values to the metadata/ and VEDS mandatory, and adds new attribute values to the metadata/
control object defined in that document. This document also control object defined in that document. This document also
registers a new INFO package (identical to that defined in registers a new INFO package (identical to that defined in
[I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type). [I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type).
This document registers the 'application/EmergencyCallData.VEDS+xml' This document registers the 'application/EmergencyCallData.VEDS+xml'
MIME content-type, registers the 'VEDS' entry in the Emergency Call MIME media type, registers the 'VEDS' entry in the Emergency Call
Additional Data registry, and registers an INFO package to enable Additional Data registry, and registers an INFO package to enable
carrying this and related data in INFO requests. carrying this and related data in INFO requests.
Section 6 introduces VEDS. Section 7 describes how VEDS data and Section 6 introduces VEDS. Section 7 describes how VEDS data and
metadata/control blocks are transported within NG-ACN calls. metadata/control blocks are transported within NG-ACN calls.
Section 8 describes how such calls are placed. Section 8 describes how such calls are placed.
These mechanisms are used to place emergency calls that are These mechanisms are used to place emergency calls that are
identifiable as ACN calls and that carry standardized crash data in identifiable as ACN calls and that carry standardized crash data in
an interoperable way. an interoperable way.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
the likelihood of severe injuries to the vehicle occupants, etc. the likelihood of severe injuries to the vehicle occupants, etc.
This data better informs the PSAP and emergency responders as to the This data better informs the PSAP and emergency responders as to the
type of response that might be needed. Some of this information has type of response that might be needed. Some of this information has
been included in U.S. government guidelines for field triage of been included in U.S. government guidelines for field triage of
injured patients [triage-2008] [triage-2011]. These guidelines are injured patients [triage-2008] [triage-2011]. These guidelines are
designed to help responders identify the potential existence of designed to help responders identify the potential existence of
severe internal injuries and to make critical decisions about how and severe internal injuries and to make critical decisions about how and
where a patient needs to be transported. where a patient needs to be transported.
VEDS is an XML structure (see [VEDS]) transported in SIP using the VEDS is an XML structure (see [VEDS]) transported in SIP using the
'application/EmergencyCallData.VEDS+xml' MIME content-type. 'application/EmergencyCallData.VEDS+xml' MIME media type.
VEDS is a versatile structure that can accomodate varied needs.
However, if additional sets of data are needed (e.g., in the future
or in different regions), the steps to enable each data block are
very briefly summarized below:
o A standardized format and encoding (such as XML) is defined and If new data blocks are needed (e.g., in other regions or for enhanced
published by a Standards Development Organization (SDO) data), the steps required during standardization are briefly
summarized below:
o A MIME Content-Type is registered for it (typically under the o A set of data is standardized by an SDO or appropriate
'Application' media type) with a sub-type in the organization
'EmergencyCallData.' tree o A MIME media type for the crash data set is registered with IANA
o An entry for the block is added to the Emergency Call Additional * If the data is specifically for use in emergency calling, the
Data Blocks sub-registry (established by [RFC7852]); the registry MIME media type is normally under the 'application' type with a
entry is the root of the MIME sub-type (not including the subtype starting with 'EmergencyCallData.'
'EmergencyCallData.' prefix and any suffix such as '+xml') * If the data format is XML, then by convention the name has a
suffix of '+xml'
o The item is registered in the Emergency Call Additional Data
registry, as defined in Section 9.1.7 of [RFC7852]
o A new INFO package is registered that permits carrying the new * For emergency-call-specific formats, the registered name is the
media type and the metadata/control object (defined in root of the MIME media type (not including the
[I-D.ietf-ecrit-ecall]) in INFO requests. 'EmergencyCallData' prefix and any suffix such as '+xml') as
described in Section 4.1 of [RFC7852].
o A new INFO package is registered that permits carrying the the new
media type, the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
objects, in INFO messages.
7. Data Transport 7. Data Transport
[RFC7852] establishes a general mechanism for attaching blocks of [RFC7852] establishes a general mechanism for attaching blocks of
data to a SIP emergency call. This mechanism permits certain data to a SIP emergency call. This mechanism permits certain
emergency call MIME types to be attached to SIP messages. This emergency call MIME types to be attached to SIP messages. This
document makes use of that mechanism. This document also registers document makes use of that mechanism. This document also registers
an INFO package (in Section 12) to enable NG-ACN related data blocks an INFO package (in Section 12) to enable NG-ACN related data blocks
to be carried in SIP INFO requests (per [RFC6086], new INFO usages to be carried in SIP INFO requests (per [RFC6086], new INFO usages
require the definition of an INFO package). require the definition of an INFO package).
An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS]) An In-Vehicle System (IVS) transmits a VEDS data block (see [VEDS])
by attaching it to a SIP message as a MIME body part per [RFC7852]. by attaching it to a SIP message as a MIME body part per [RFC7852].
The body part is identified by its MIME content-type ('application/ The body part is identified by its MIME media type ('application/
emergencyCallData.VEDS+xml') in the Content-Type header field of the emergencyCallData.VEDS+xml') in the Content-Type header field of the
body part. The body part is assigned a unique identifier which is body part. The body part is assigned a unique identifier which is
listed in a Content-ID header field in the body part. The SIP listed in a Content-ID header field in the body part. The SIP
message is marked as containing the VEDS data by adding (or appending message is marked as containing the VEDS data by adding (or appending
to) a Call-Info header field at the top level of the SIP message. to) a Call-Info header field at the top level of the SIP message.
This Call-Info header field contains a CID URL referencing the body This Call-Info header field contains a CID URL referencing the body
part's unique identifier, and a 'purpose' parameter identifying the part's unique identifier, and a 'purpose' parameter identifying the
data as a VEDS data block per the Emergency Call Additional Data data as a VEDS data block per the Emergency Call Additional Data
Blocks registry entry; the 'purpose' parameter's value is Blocks registry entry; the 'purpose' parameter's value is
'emergencyCallData.VEDS'. A VEDS data block is carried in a SIP INFO 'emergencyCallData.VEDS'. A VEDS data block is carried in a SIP INFO
request by using the INFO package defined in Section 12. request by using the INFO package defined in Section 12.
A PSAP or IVS transmits a metadata/control object (see A PSAP or IVS transmits a metadata/control object (see
[I-D.ietf-ecrit-ecall]) by attaching it to a SIP message as a MIME [I-D.ietf-ecrit-ecall]) by attaching it to a SIP message as a MIME
body part per [RFC7852]. The body part is identified by its MIME body part per [RFC7852]. The body part is identified by its MIME
content-type ('application/emergencyCallData.control+xml') in the media type ('application/emergencyCallData.control+xml') in the
Content-Type header field of the body part. The body part is Content-Type header field of the body part. The body part is
assigned a unique identifier which is listed in a Content-ID header assigned a unique identifier which is listed in a Content-ID header
field in the body part. The SIP message is marked as containing the field in the body part. The SIP message is marked as containing the
metadata/control block by adding (or appending to) a Call-Info header metadata/control block by adding (or appending to) a Call-Info header
field at the top level of the SIP message. This Call-Info header field at the top level of the SIP message. This Call-Info header
field contains a CID URL referencing the body part's unique field contains a CID URL referencing the body part's unique
identifier, and a 'purpose' parameter identifying the data as a identifier, and a 'purpose' parameter identifying the data as a
metadata/control block per the Emergency Call Additional Data Blocks metadata/control block per the Emergency Call Additional Data Blocks
registry entry; the 'purpose' parameter's value is registry entry; the 'purpose' parameter's value is
'emergencyCallData.control'. A metadata/control object is carried in 'emergencyCallData.control'. A metadata/control object is carried in
skipping to change at page 16, line 13 skipping to change at page 16, line 17
VEDS). VEDS).
8. Call Setup 8. Call Setup
A next-generation In-Vehicle System (IVS) initiates an NG-ACN call A next-generation In-Vehicle System (IVS) initiates an NG-ACN call
with a SIP INVITE using one of the SOS sub-services with a SIP INVITE using one of the SOS sub-services
"SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI, "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,
standard sets of crash data and capabilities data encoded in standard sets of crash data and capabilities data encoded in
standardized and registered formats, attached as additional data standardized and registered formats, attached as additional data
blocks as specified in Section 4.1 of [RFC7852]. As described in blocks as specified in Section 4.1 of [RFC7852]. As described in
that document, each data block is identified by its MIME content- that document, each data block is identified by its MIME media type,
type, and pointed to by a CID URL in a Call-Info header with a and pointed to by a CID URL in a Call-Info header with a 'purpose'
'purpose' parameter value corresponding to the data block. parameter value corresponding to the data block.
If new data blocks are needed (e.g., in other regions or in the
future), the steps required during standardization are briefly
summarized below:
o A set of data is standardized by an SDO or appropriate
organization
o A MIME Content-Type for the crash data set is registered with IANA
* If the data is specifically for use in emergency calling, the
MIME type is normally under the 'application' type with a
subtype starting with 'EmergencyCallData.'
* If the data format is XML, then by convention the name has a
suffix of '+xml'
o The item is registered in the Emergency Call Additional Data
registry, as defined in Section 9.1.7 of [RFC7852]
* For emergency-call-specific formats, the registered name is the
root of the MIME Content-Type (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') as
described in Section 4.1 of [RFC7852].
o A new INFO package is registered that permits carrying the the new
media type, the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
objects, in INFO messages.
When placing an emergency call, the crash data set and IVS capability When placing an emergency call, the crash data set and IVS capability
data are transported as described in Section 7. data are transported as described in Section 7.
The Vehicle Emergency Data Set (VEDS) is an XML structure defined by The Vehicle Emergency Data Set (VEDS) is an XML structure defined by
the Association of Public-Safety Communications Officials (APCO) and the Association of Public-Safety Communications Officials (APCO) and
the National Emergency Number Association (NENA) [VEDS]. It is the National Emergency Number Association (NENA) [VEDS]. It is
carried in body part with MIME content-type 'application/ carried in a body part with MIME media type 'application/
EmergencyCallData.VEDS+xml'. EmergencyCallData.VEDS+xml'.
Entities along the path between the vehicle and the PSAP are able to Entities along the path between the vehicle and the PSAP are able to
identify the call as an ACN call and handle it appropriately. The identify the call as an ACN call and handle it appropriately. The
PSAP is able to identify the crash and capabilities data attached to PSAP is able to identify the crash and capabilities data attached to
the INVITE by examining the Call-Info header fields for 'purpose' the INVITE by examining the Call-Info header fields for 'purpose'
parameters whose values start with 'EmergencyCallData.' The PSAP is parameters whose values start with 'EmergencyCallData.' The PSAP is
able to access the data it is capable of handling and is interested able to access the data it is capable of handling and is interested
in by checking the 'purpose' parameter values. in by checking the 'purpose' parameter values.
skipping to change at page 25, line 35 skipping to change at page 24, line 42
See [TBD: THIS DOCUMENT] for more information. See [TBD: THIS DOCUMENT] for more information.
12.7. Info Package Usage Restrictions 12.7. Info Package Usage Restrictions
Usage is limited to vehicle-initiated emergency calls as defined in Usage is limited to vehicle-initiated emergency calls as defined in
[TBD: THIS DOCUMENT]. [TBD: THIS DOCUMENT].
12.8. Rate of INFO Requests 12.8. Rate of INFO Requests
The rate of SIP INFO requests associated with the The SIP INFO request is used within an established emergency call
emergencyCallData.eCall.VEDS info package is normally quite low (most dialog for the PSAP to request the IVS to send an updated data set,
dialogs are likely to contain zero INFO requests, while others can be and for the IVS to send the requested data set. Because this is
expected to carry an occasional request). normally done only on manual request of the PSAP call taker (who
suspects some aspect of the vehicle state has changed), the rate of
SIP INFO requests associated with the emergencyCallData.eCall.VEDS
info package is normally quite low (most dialogs are likely to
contain zero INFO requests, while others can be expected to carry an
occasional request).
12.9. Info Package Security Considerations 12.9. Info Package Security Considerations
The MIME media type registations for the data blocks that can be The MIME media type registations for the data blocks that can be
carried using this INFO package contains a discussion of the security carried using this INFO package contains a discussion of the security
and/or privacy considerations specific to that data block. The and/or privacy considerations specific to that data block. The
"Security Considerations" and "Privacy Considerations" sections of "Security Considerations" and "Privacy Considerations" sections of
[TBD: THIS DOCUMENT] discuss security and privacy considerations of [TBD: THIS DOCUMENT] discuss security and privacy considerations of
the data carried in vehicle-initiated emergency calls as described in the data carried in vehicle-initiated emergency calls as described in
that document. that document.
skipping to change at page 32, line 24 skipping to change at page 32, line 7
signed by a certificate issued by an emergency services registrar). signed by a certificate issued by an emergency services registrar).
16. IANA Considerations 16. IANA Considerations
This document registers the 'application/EmergencyCall.VEDS+xml' MIME This document registers the 'application/EmergencyCall.VEDS+xml' MIME
media type, and adds "VEDS" to the Emergency Call Additional Data media type, and adds "VEDS" to the Emergency Call Additional Data
registry. This document adds to and creates sub-registries in the registry. This document adds to and creates sub-registries in the
'Metadata/Control Data' registry created in [I-D.ietf-ecrit-ecall]. 'Metadata/Control Data' registry created in [I-D.ietf-ecrit-ecall].
This document registers a new INFO package. This document registers a new INFO package.
16.1. MIME Content-type Registration for 'application/ 16.1. MIME Media Type Registration for 'application/
EmergencyCall.VEDS+xml' EmergencyCall.VEDS+xml'
This specification requests the registration of a new MIME media type This specification requests the registration of a new MIME media 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: EmergencyCallData.VEDS+xml MIME subtype name: EmergencyCallData.VEDS+xml
skipping to change at page 37, line 47 skipping to change at page 37, line 47
We would like to thank Lena Chaponniere, Stephen Edge, and Christer We would like to thank Lena Chaponniere, Stephen Edge, and Christer
Holmberg for their review and suggestions; Robert Sparks and Paul Holmberg for their review and suggestions; Robert Sparks and Paul
Kyzivat for their help with the SIP mechanisms; Michael Montag, Kyzivat for their help with the SIP mechanisms; Michael Montag,
Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex
Buddenberg for their feedback; and Ulrich Dietz for his help with Buddenberg for their feedback; and Ulrich Dietz for his help with
earlier versions of the original version of this document. earlier versions of the original version of this document.
18. Changes from Previous Versions 18. Changes from Previous Versions
18.1. Changes from draft-ietf-16 to draft-ietf-17 18.1. Changes from draft-ietf-17 to draft-ietf-18
o Added additional text to "Rate of Info Requests"
o Further corrected "content type" to "media type"
18.2. Changes from draft-ietf-16 to draft-ietf-17
o Clarified that an INFO request is expected to have at least one o Clarified that an INFO request is expected to have at least one
VEDS, MSD or metadata/control body part VEDS, MSD or metadata/control body part
o Corrected "content type" to "media type" o Corrected "content type" to "media type"
18.2. Changes from draft-ietf-14 to draft-ietf-15 18.3. Changes from draft-ietf-14 to draft-ietf-15
o Moved VEDS text from Introduction to new Vehicle Data section o Moved VEDS text from Introduction to new Vehicle Data section
o Various clarifications and simplifications o Various clarifications and simplifications
18.3. Changes from draft-ietf-13 to draft-ietf-14 18.4. Changes from draft-ietf-13 to draft-ietf-14
o Body parts now always sent enclosed in multipart (even if only o Body parts now always sent enclosed in multipart (even if only
body part in SIP message) and hence always have a Content- body part in SIP message) and hence always have a Content-
Disposition of By-Reference Disposition of By-Reference
o Fixed typos. o Fixed typos.
18.4. Changes from draft-ietf-11 to draft-ietf-13 18.5. Changes from draft-ietf-11 to draft-ietf-13
o Fixed typos o Fixed typos
18.5. Changes from draft-ietf-10 to draft-ietf-11 18.6. Changes from draft-ietf-10 to draft-ietf-11
o Clarifications suggested by Christer o Clarifications suggested by Christer
o Corrections to Content-Disposition text and examples as suggested o Corrections to Content-Disposition text and examples as suggested
by Paul Kyzivat by Paul Kyzivat
o Clarifications to Content-Disposition text and examples to clarify o Clarifications to Content-Disposition text and examples to clarify
that handling=optional is only used in the initial INVITE that handling=optional is only used in the initial INVITE
18.6. Changes from draft-ietf-09 to draft-ietf-10 18.7. Changes from draft-ietf-09 to draft-ietf-10
o Fixed errors in examples found by Dale in eCall draft o Fixed errors in examples found by Dale in eCall draft
o Removed enclosing sub-section of INFO package registration section o Removed enclosing sub-section of INFO package registration section
o Added text per Christer and Dale's suggestions that the MSD and o Added text per Christer and Dale's suggestions that the MSD and
metadata/control blocks are sent in INFO with a Call-Info header metadata/control blocks are sent in INFO with a Call-Info header
field referencing them field referencing them
o Other text changes per comments received from Christer and Ivo o Other text changes per comments received from Christer and Ivo
against eCall draft. against eCall draft.
18.7. Changes from draft-ietf-08 to draft-ietf-09 18.8. Changes from draft-ietf-08 to draft-ietf-09
o Added INFO package registration for eCall.VEDS o Added INFO package registration for eCall.VEDS
o Moved <capabilities> element and other extension points back to o Moved <capabilities> element and other extension points back to
eCall document so that extension points are in base spec (and also eCall document so that extension points are in base spec (and also
to get XML schema to compile) to get XML schema to compile)
o Text changes for clarification. o Text changes for clarification.
18.8. Changes from draft-ietf-07 to draft-ietf-08 18.9. Changes from draft-ietf-07 to draft-ietf-08
o Moved much of the metadata/control object from o Moved much of the metadata/control object from
[I-D.ietf-ecrit-ecall] to this document as extensions [I-D.ietf-ecrit-ecall] to this document as extensions
o Editorial clarifications and simplifications o Editorial clarifications and simplifications
o Moved "Call Routing" to be a subsection of "Call Setup" o Moved "Call Routing" to be a subsection of "Call Setup"
o Deleted "Profile" section and moved some of its text into o Deleted "Profile" section and moved some of its text into
"Introduction" "Introduction"
18.9. Changes from draft-ietf-06 to draft-ietf-07 18.10. Changes from draft-ietf-06 to draft-ietf-07
o Minor editorial changes o Minor editorial changes
18.10. Changes from draft-ietf-05 to draft-ietf-06 18.11. Changes from draft-ietf-05 to draft-ietf-06
o Added clarifying text regarding signed and encrypted data o Added clarifying text regarding signed and encrypted data
o Additional informative text in "Migration to Next-Generation" o Additional informative text in "Migration to Next-Generation"
section section
o Additional clarifying text regarding security and privacy. o Additional clarifying text regarding security and privacy.
18.11. Changes from draft-ietf-04 to draft-ietf-05 18.12. Changes from draft-ietf-04 to draft-ietf-05
o Reworded security text in main document and in MIME registration o Reworded security text in main document and in MIME registration
for the VEDS object for the VEDS object
18.12. Changes from draft-ietf-03 to draft-ietf-04 18.13. Changes from draft-ietf-03 to draft-ietf-04
o Added example VEDS object o Added example VEDS object
o Additional clarifications and corrections o Additional clarifications and corrections
o Removed references from Abstract o Removed references from Abstract
o Moved Document Scope section to follow Introduction o Moved Document Scope section to follow Introduction
18.13. Changes from draft-ietf-02 to draft-ietf-03 18.14. Changes from draft-ietf-02 to draft-ietf-03
o Additional clarifications and corrections o Additional clarifications and corrections
18.14. Changes from draft-ietf-01 to draft-ietf-02 18.15. Changes from draft-ietf-01 to draft-ietf-02
o This document now refers to [I-D.ietf-ecrit-ecall] for technical o This document now refers to [I-D.ietf-ecrit-ecall] for technical
aspects including the service URN; this document no longer aspects including the service URN; this document no longer
proposes a unique service URN for non-eCall NG-ACN calls; the same proposes a unique service URN for non-eCall NG-ACN calls; the same
service URN is now used for all NG-ACN calls including NG-eCall service URN is now used for all NG-ACN calls including NG-eCall
and non-eCall and non-eCall
o Added discussion of an NG-ACN call placed to a PSAP that doesn't o Added discussion of an NG-ACN call placed to a PSAP that doesn't
support it support it
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
18.15. Changes from draft-ietf-00 to draft-ietf-01 18.16. Changes from draft-ietf-00 to draft-ietf-01
o Added further discussion of test calls o Added further discussion of test calls
o Added further clarification to the document scope o Added further clarification to the document scope
o Mentioned that multi-region vehicles may need to support other o Mentioned that multi-region vehicles may need to support other
crash notification specifications such as eCall crash notification specifications such as eCall
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
18.16. Changes from draft-gellens-02 to draft-ietf-00 18.17. Changes from draft-gellens-02 to draft-ietf-00
o Renamed from draft-gellens- to draft-ietf- o Renamed from draft-gellens- to draft-ietf-
o Added text to Introduction to clarify that during a CS ACN, the o Added text to Introduction to clarify that during a CS ACN, the
PSAP call taker usually needs to listen to the data and transcribe PSAP call taker usually needs to listen to the data and transcribe
it it
18.17. Changes from draft-gellens-01 to -02 18.18. Changes from draft-gellens-01 to -02
o Fixed case of 'EmergencyCallData', in accordance with changes to o Fixed case of 'EmergencyCallData', in accordance with changes to
[RFC7852] [RFC7852]
18.18. Changes from draft-gellens-00 to -01 18.19. Changes from draft-gellens-00 to -01
o Now using 'EmergencyCallData' for purpose parameter values and o Now using 'EmergencyCallData' for purpose parameter values and
MIME subtypes, in accordance with changes to [RFC7852] MIME subtypes, in accordance with changes to [RFC7852]
o Added reference to RFC 6443 o Added reference to RFC 6443
o Fixed bug that caused Figure captions to not appear o Fixed bug that caused Figure captions to not appear
19. References 19. References
19.1. Normative References 19.1. Normative References
 End of changes. 43 change blocks. 
123 lines changed or deleted 108 lines changed or added

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