< draft-ietf-ecrit-car-crash-16.txt   draft-ietf-ecrit-car-crash-17.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 19, 2017 NeuStar, Inc. Expires: April 20, 2017 NeuStar, Inc.
H. Tschofenig H. Tschofenig
Individual Individual
October 16, 2016 October 17, 2016
Next-Generation Vehicle-Initiated Emergency Calls Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-16.txt draft-ietf-ecrit-car-crash-17.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
case of manual trigger. The "Advanced" qualifier refers to the case of manual trigger. The "Advanced" qualifier refers to the
ability to carry a richer set of data. ability to carry a richer set of data.
This document also registers a MIME Content Type and Emergency Call This document also registers a MIME media type and Emergency Call
Additional Data Block for the vehicle, sensor, and location data Additional Data Block for the vehicle, sensor, and location data
(often referred to as "crash data" even though there is not (often referred to as "crash data" even though there is not
necessarily a crash) and an INFO package to enable carrying this and necessarily a crash) and an INFO package to enable carrying this and
related data in INFO requests. An external specification for the related data in INFO requests. An external specification for the
data format, contents, and structure are referenced in this document. data format, contents, and structure are referenced in this document.
This document reuses the technical aspects of next-generation pan- This document reuses the technical aspects of next-generation pan-
European eCall (a mandated and standardized system for emergency European eCall (a mandated and standardized system for emergency
calls by in-vehicle systems within Europe and other regions). calls by in-vehicle systems within Europe and other regions).
However, this document specifies a different set of vehicle (crash) However, this document specifies a different set of vehicle (crash)
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 19, 2017. This Internet-Draft will expire on April 20, 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 3, line 32 skipping to change at page 3, line 32
16.1. MIME Content-type Registration for 16.1. MIME Content-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 . . . . . . . . . . . . . . . . . . . 34
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-14 to draft-ietf-15 . . . . . . 37 18.1. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 37
18.2. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 18.2. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38
18.3. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 18.3. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
18.4. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 18.4. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38
18.5. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 18.5. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38
18.6. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 18.6. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38
18.7. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 18.7. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38
18.8. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 18.8. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38
18.9. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 18.9. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39
18.10. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 18.10. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39
18.11. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 18.11. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39
18.12. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 18.12. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39
18.13. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 18.13. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39
18.14. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 18.14. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39
18.15. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 18.15. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39
18.16. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 18.16. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40
18.17. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 18.17. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40
18.18. 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 . . . . . . . . . . . . . . . . . 41
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 13, line 43 skipping to change at page 13, line 43
o A MIME Content-Type is registered for it (typically under the o A MIME Content-Type is registered for it (typically under the
'Application' media type) with a sub-type in the 'Application' media type) with a sub-type in the
'EmergencyCallData.' tree 'EmergencyCallData.' tree
o An entry for the block is added to the Emergency Call Additional o An entry for the block is added to the Emergency Call Additional
Data Blocks sub-registry (established by [RFC7852]); the registry Data Blocks sub-registry (established by [RFC7852]); the registry
entry is the root of the MIME sub-type (not including the entry is the root of the MIME sub-type (not including the
'EmergencyCallData.' prefix and any suffix such as '+xml') 'EmergencyCallData.' prefix and any suffix such as '+xml')
o A new INFO package is registered that permits carrying the new o A new INFO package is registered that permits carrying the new
content type and the metadata/control object (defined in media type and the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]) in INFO requests. [I-D.ietf-ecrit-ecall]) in INFO requests.
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
skipping to change at page 16, line 42 skipping to change at page 16, line 42
o The item is registered in the Emergency Call Additional Data o The item is registered in the Emergency Call Additional Data
registry, as defined in Section 9.1.7 of [RFC7852] registry, as defined in Section 9.1.7 of [RFC7852]
* For emergency-call-specific formats, the registered name is the * For emergency-call-specific formats, the registered name is the
root of the MIME Content-Type (not including the root of the MIME Content-Type (not including the
'EmergencyCallData' prefix and any suffix such as '+xml') as 'EmergencyCallData' prefix and any suffix such as '+xml') as
described in Section 4.1 of [RFC7852]. described in Section 4.1 of [RFC7852].
o A new INFO package is registered that permits carrying the the new o A new INFO package is registered that permits carrying the the new
content type, the metadata/control object (defined in media type, the metadata/control object (defined in
[I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS [I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS
objects, in INFO messages. 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 body part with MIME content-type 'application/
skipping to change at page 20, line 7 skipping to change at page 20, line 7
enable-camera adds a one-way media stream (established via SIP re- enable-camera adds a one-way media stream (established via SIP re-
INVITE sent by the vehicle) to enable the PSAP call taker to view INVITE sent by the vehicle) to enable the PSAP call taker to view
a feed from a camera. a feed from a camera.
Note that there is no 'request' action to play dynamic media (such as Note that there is no 'request' action to play dynamic media (such as
an audio message). The PSAP can send a SIP re-INVITE to establish a an audio message). The PSAP can send a SIP re-INVITE to establish a
one-way media stream for this purpose. one-way media stream for this purpose.
10.2. Request Example 10.2. Request Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.control <EmergencyCallData.control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
<request action="send-data" datatype="VEDS"/> <request action="send-data" datatype="VEDS"/>
<request action="lamp" lamp-id="hazard" <request action="lamp" lamp-id="hazard"
lamp-action="flash" persistance="PT1H"/> lamp-action="flash" persistance="PT1H"/>
<request action="msg-static" msgid="1"/> <request action="msg-static" msgid="1"/>
<request action="msg-dynamic"> <request action="msg-dynamic">
<text>Remain calm. Help is on the way.</text> <text>Remain calm. Help is on the way.</text>
</request> </request>
</EmergencyCallData.control> </EmergencyCallData.control>
Figure 7: Request Example Figure 7: Request Example
10.3. The <ack> element 10.3. The <ack> element
In [I-D.ietf-ecrit-ecall], the <ack> element is transmitted by the In [I-D.ietf-ecrit-ecall], the <ack> element is transmitted by the
PSAP to acknowledge the MSD. Here, the <ack> element is also PSAP to acknowledge the MSD. Here, the <ack> element is also
transmitted by the PSAP to acknowledge the VEDS data and by the IVS transmitted by the PSAP to acknowledge the VEDS data and by the IVS
to acknowledge receipt of a <request> element that requested the IVS to acknowledge receipt of a <request> element that requested the IVS
to perform an action other than transmitting a data object (e.g., a to perform an action other than transmitting a data object (e.g., a
request to display a message would be acknowledged, but a request to request to display a message would be acknowledged, but a request to
transmit VEDS data would not result in a separate <ack> element being transmit VEDS data would not result in a separate <ack> element being
sent, since the data object itself serves as acknowledgment.) An sent, since the data object itself serves as acknowledgment.) An
<ack> element sent by an IVS references the unique ID of the <ack> element sent by an IVS references the unique ID of the
metadata/control object containing the request(s) and indicates metadata/control object containing the request(s) and indicates
whether the request was successfully performed, and if not, whether the request was successfully performed, and if not,
optionally includes an explanation. optionally includes an explanation.
10.3.1. Ack Examples 10.3.1. Ack Examples
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.control <EmergencyCallData.control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
<ack ref="1234567890@atlanta.example.com"> <ack ref="1234567890@atlanta.example.com">
<actionResult action="msg-dynamic" success="true"/> <actionResult action="msg-dynamic" success="true"/>
<actionResult action="lamp" success="false" reason="unable" <actionResult action="lamp" success="false" reason="unable"
details="The requested lamp is inoperable"/> details="The requested lamp is inoperable"/>
</ack> </ack>
</EmergencyCallData.control> </EmergencyCallData.control>
Figure 8: Ack Example from IVS to PSAP Figure 8: Ack Example from IVS to PSAP
10.4. The <capabilities> element 10.4. The <capabilities> element
The <capabilities> element ([I-D.ietf-ecrit-ecall]) is transmitted by The <capabilities> element ([I-D.ietf-ecrit-ecall]) is transmitted by
the IVS to indicate its capabilities to the PSAP. the IVS to indicate its capabilities to the PSAP.
The <capabilities> element contains a <request> child element per The <capabilities> element contains a <request> child element per
action supported by the vehicle. The vehicle MUST support sending action supported by the vehicle. The vehicle MUST support sending
skipping to change at page 22, line 10 skipping to change at page 22, line 10
If the "enable-camera" action is supported, a <request> child element If the "enable-camera" action is supported, a <request> child element
with the 'action' attribute set to "enable-camera" is included, with with the 'action' attribute set to "enable-camera" is included, with
the 'supported-values' attribute set to all supported camera IDs. A the 'supported-values' attribute set to all supported camera IDs. A
registry is created in Section 16.6 to contain camera ID values. registry is created in Section 16.6 to contain camera ID values.
10.4.1. Capabilities Example 10.4.1. Capabilities Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.control <EmergencyCallData.control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
<capabilities> <capabilities>
<request action="send-data" supported-values="VEDS"/> <request action="send-data" supported-values="VEDS"/>
<request action="lamp" <request action="lamp"
supported-values="head;interior;fog-front;fog-rear;brake; supported-values="head;interior;fog-front;fog-rear;brake;
position-front;position-rear;turn-left;turn-right;hazard"/> position-front;position-rear;turn-left;turn-right;hazard"/>
<request action="msg-static" msgid="3"/> <request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="honk"/> <request action="honk"/>
<request action="enable-camera" supported-values="backup; interior"/> <request action="enable-camera" supported-values="backup; interior"/>
skipping to change at page 25, line 5 skipping to change at page 25, line 5
None None
12.6. INFO Request Body Parts 12.6. INFO Request Body Parts
The body for an emergencyCallData.eCall.VEDS info package is a The body for an emergencyCallData.eCall.VEDS info package is a
multipart body which MAY contain zero or one application/ multipart body which MAY contain zero or one application/
emergencyCallData.eCall.VEDS+xml (containing a VEDS data block) part, emergencyCallData.eCall.VEDS+xml (containing a VEDS data block) part,
zero or more application/emergencyCallData.control+xml (containing a zero or more application/emergencyCallData.control+xml (containing a
metadata/control object) parts, and zero or one application/ metadata/control object) parts, and zero or one application/
emergencyCallData.eCall.MSD+per (containing an MSD) part. emergencyCallData.eCall.MSD+per (containing an MSD) part. At least
one VEDS, MSD, or metadata/control body part is expected; the
behavior upon receiving an INFO request with none is undefined.
The body parts are sent per [RFC6086], and in addition, to align with The body parts are sent per [RFC6086], and in addition, to align with
with how these body parts are sent in non-INFO messages, each with how these body parts are sent in non-INFO messages, each
associated body part is referenced by a Call-Info header field at the associated body part is referenced by a Call-Info header field at the
top level of the SIP message. The body part has a Content- top level of the SIP message. The body part has a Content-
Disposition header field set to "By-Reference". Disposition header field set to "By-Reference".
A VEDS or metadata/control block is always enclosed in a multipart A VEDS or metadata/control block is always enclosed in a multipart
body part (even if it would otherwise be the only body part in the body part (even if it would otherwise be the only body part in the
SIP message), since as of the date of this document, the use of SIP message), since as of the date of this document, the use of
skipping to change at page 25, line 40 skipping to change at page 25, line 42
12.8. Rate of INFO Requests 12.8. Rate of INFO Requests
The rate of SIP INFO requests associated with the The rate of SIP INFO requests associated with the
emergencyCallData.eCall.VEDS info package is normally quite low (most emergencyCallData.eCall.VEDS info package is normally quite low (most
dialogs are likely to contain zero INFO requests, while others can be dialogs are likely to contain zero INFO requests, while others can be
expected to carry an occasional request). expected to carry an occasional request).
12.9. Info Package Security Considerations 12.9. Info Package Security Considerations
The MIME content 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.
12.10. Implementation Details 12.10. Implementation Details
See [TBD: THIS DOCUMENT] for protocol details. See [TBD: THIS DOCUMENT] for protocol details.
skipping to change at page 27, line 49 skipping to change at page 27, line 49
In addition to the information about the vehicle, further indications In addition to the information about the vehicle, further indications
are provided, namely the presence of fuel leakage are provided, namely the presence of fuel leakage
('FuelLeakingIndicator' element), an indication whether the vehicle ('FuelLeakingIndicator' element), an indication whether the vehicle
was subjected to multiple impacts ('MultipleImpactsIndicator' was subjected to multiple impacts ('MultipleImpactsIndicator'
element), the orientation of the vehicle at final rest element), the orientation of the vehicle at final rest
('VehicleFinalRestOrientationCategoryCode' element) and an indication ('VehicleFinalRestOrientationCategoryCode' element) and an indication
that there are no parts of the vehicle on fire (the that there are no parts of the vehicle on fire (the
'VehicleFireIndicator' element). 'VehicleFireIndicator' element).
INVITE urn:service:sos.ecall.automatic SIP/2.0 INVITE urn:service:sos.ecall.automatic SIP/2.0
To: urn:service:sos.ecall.automatic To: urn:service:sos.ecall.automatic
From: <sip:+13145551111@example.com>;tag=9fxced76sl From: <sip:+13145551111@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@example.com> Geolocation: <cid:target123@example.com>
Geolocation-Routing: no Geolocation-Routing: no
Call-Info: <cid:1234567890@atlanta.example.com>; Call-Info: <cid:1234567890@atlanta.example.com>;
purpose=EmergencyCallData.VEDS purpose=EmergencyCallData.VEDS
Call-Info: <cid:1234567892@atlanta.example.com>; Call-Info: <cid:1234567892@atlanta.example.com>;
purpose=emergencyCallData.control purpose=emergencyCallData.control
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.control+xml application/emergencyCallData.control+xml
Recv-Info: emergencyCallData.eCall Recv-Info: emergencyCallData.eCall
Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
SUBSCRIBE, NOTIFY, UPDATE SUBSCRIBE, NOTIFY, UPDATE
CSeq: 31862 INVITE CSeq: 31862 INVITE
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
...Session Description Protocol (SDP) goes here ...Session Description Protocol (SDP) goes 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
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic" xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="sip:+13145551111@example.com"> entity="sip:+13145551111@example.com">
<dm:device id="123"> <dm:device id="123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
</gml:Point> </gml:Point>
<dyn:Dynamic> <dyn:Dynamic>
<dyn:heading>278</dyn:heading> <dyn:heading>278</dyn:heading>
<dyn:direction><dyn:direction> <dyn:direction><dyn:direction>
</dyn:Dynamic> </dyn:Dynamic>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>gps</method> <method>gps</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2012-04-5T10:18:29Z</timestamp> <timestamp>2012-04-5T10:18:29Z</timestamp>
<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID> <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.VEDS+xml Content-Type: application/EmergencyCallData.VEDS+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"?> <?xml version="1.0" encoding="UTF-8"?>
<AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0" <AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Crash> <Crash>
<CrashVehicle> <CrashVehicle>
<ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0"> <ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0">
Saab Saab
</ItemMakeName> </ItemMakeName>
<ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0"> <ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0">
9-5 9-5
</ItemModelName> </ItemModelName>
<ItemModelYearDate <ItemModelYearDate
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
2015 2015
</ItemModelYearDate> </ItemModelYearDate>
<Airbag> <Airbag>
<AirbagCategoryCode>FRONT</AirbagCategoryCode> <AirbagCategoryCode>FRONT</AirbagCategoryCode>
<AirbagDeployedIndicator>true <AirbagDeployedIndicator>true
</AirbagDeployedIndicator> </AirbagDeployedIndicator>
</Airbag> </Airbag>
<ConvertibleIndicator>false</ConvertibleIndicator> <ConvertibleIndicator>false</ConvertibleIndicator>
<PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode> <PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode>
<VehicleBodyCategoryCode <VehicleBodyCategoryCode
xmlns="http://niem.gov/niem/domains/jxdm/4.1"> xmlns="http://niem.gov/niem/domains/jxdm/4.1">
101 101
</VehicleBodyCategoryCode> </VehicleBodyCategoryCode>
<VehicleCrashPulse> <VehicleCrashPulse>
<CrashPulseChangeInVelocityMeasure> <CrashPulseChangeInVelocityMeasure>
<MeasurePointValue <MeasurePointValue
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
100 100
</MeasurePointValue> </MeasurePointValue>
<MeasureUnitText <MeasureUnitText
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
MPH</MeasureUnitText> MPH</MeasureUnitText>
</CrashPulseChangeInVelocityMeasure> </CrashPulseChangeInVelocityMeasure>
<CrashPulsePrincipalDirectionOfForceValue>12 <CrashPulsePrincipalDirectionOfForceValue>12
</CrashPulsePrincipalDirectionOfForceValue> </CrashPulsePrincipalDirectionOfForceValue>
<CrashPulseRolloverQuarterTurnsValue>1 <CrashPulseRolloverQuarterTurnsValue>1
</CrashPulseRolloverQuarterTurnsValue> </CrashPulseRolloverQuarterTurnsValue>
</VehicleCrashPulse> </VehicleCrashPulse>
<VehicleRollbarDeployedIndicator>false <VehicleRollbarDeployedIndicator>false
</VehicleRollbarDeployedIndicator> </VehicleRollbarDeployedIndicator>
<VehicleSeat> <VehicleSeat>
<VehicleSeatLocationCategoryCode>1 <VehicleSeatLocationCategoryCode>1
</VehicleSeatLocationCategoryCode> </VehicleSeatLocationCategoryCode>
<VehicleSeatOccupiedIndicator>true <VehicleSeatOccupiedIndicator>true
</VehicleSeatOccupiedIndicator> </VehicleSeatOccupiedIndicator>
<VehicleSeatbeltFastenedIndicator>true <VehicleSeatbeltFastenedIndicator>true
</VehicleSeatbeltFastenedIndicator> </VehicleSeatbeltFastenedIndicator>
<VehicleSeatbeltMonitoredIndicator>true <VehicleSeatbeltMonitoredIndicator>true
</VehicleSeatbeltMonitoredIndicator> </VehicleSeatbeltMonitoredIndicator>
</VehicleSeat> </VehicleSeat>
<VehicleUnladenWeightMeasure <VehicleUnladenWeightMeasure
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
<MeasurePointValue <MeasurePointValue
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
600 600
</MeasurePointValue> </MeasurePointValue>
<MeasureUnitText <MeasureUnitText
xmlns="http://niem.gov/niem/niem-core/2.0"> xmlns="http://niem.gov/niem/niem-core/2.0">
kilogram kilogram
</MeasureUnitText> </MeasureUnitText>
</VehicleUnladenWeightMeasure> </VehicleUnladenWeightMeasure>
</CrashVehicle> </CrashVehicle>
<FuelLeakingIndicator>true</FuelLeakingIndicator> <FuelLeakingIndicator>true</FuelLeakingIndicator>
<MultipleImpactsIndicator>false</MultipleImpactsIndicator> <MultipleImpactsIndicator>false</MultipleImpactsIndicator>
<SevereInjuryIndicator>true</SevereInjuryIndicator> <SevereInjuryIndicator>true</SevereInjuryIndicator>
<VehicleFinalRestOrientationCategoryCode>Driver <VehicleFinalRestOrientationCategoryCode>Driver
</VehicleFinalRestOrientationCategoryCode> </VehicleFinalRestOrientationCategoryCode>
<VehicleFireIndicator>false</VehicleFireIndicator> <VehicleFireIndicator>false</VehicleFireIndicator>
</Crash> </Crash>
</AutomatedCrashNotification> </AutomatedCrashNotification>
--boundary1 --boundary1
Content-Type: application/emergencyCallData.control+xml Content-Type: application/emergencyCallData.control+xml
Content-ID: <1234567892@atlanta.example.com> Content-ID: <1234567892@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.control <EmergencyCallData.control
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
<capabilities> <capabilities>
<request action="send-data" supported-datatypes="VEDS"/> <request action="send-data" supported-datatypes="VEDS"/>
<request action="lamp" <request action="lamp"
supported-values="head;interior;fog-front;fog-rear; supported-values="head;interior;fog-front;fog-rear;
brake;position-front;position-rear;turn-left; brake;position-front;position-rear;turn-left;
turn-right;hazard"/> turn-right;hazard"/>
<request action="msg-static" msgid="3"/> <request action="msg-static" msgid="3"/>
<request action="msg-dynamic"/> <request action="msg-dynamic"/>
<request action="honk"/> <request action="honk"/>
<request action="enable-camera" <request action="enable-camera"
supported-values="backup; interior"/> supported-values="backup; interior"/>
</capabilities> </capabilities>
</EmergencyCallData.control> </EmergencyCallData.control>
--boundary1-- --boundary1--
Figure 11: SIP INVITE for a Vehicle-Initated Emergency Call Figure 11: SIP INVITE for a Vehicle-Initated Emergency Call
14. Security Considerations 14. Security Considerations
Since this document relies on [I-D.ietf-ecrit-ecall] and [RFC7852], Since this document relies on [I-D.ietf-ecrit-ecall] and [RFC7852],
the security considerations described there and in [RFC5069] apply the security considerations described there and in [RFC5069] apply
here. Implementors are cautioned to read and understand the here. Implementors are cautioned to read and understand the
discussion in those documents. discussion in those documents.
skipping to change at page 32, line 20 skipping to change at page 32, line 19
The additional functionality enabled by this document, such as access The additional functionality enabled by this document, such as access
to vehicle camera streams, carries a burden of protection and so to vehicle camera streams, carries a burden of protection and so
implementations need to be careful that access is only provided implementations need to be careful that access is only provided
within the context of an emergency call or to an emergency services within the context of an emergency call or to an emergency services
provider (e.g., by verifying that the request for camera access is provider (e.g., by verifying that the request for camera access is
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
content 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 Content-type Registration for 'application/
EmergencyCall.VEDS+xml' EmergencyCall.VEDS+xml'
This specification requests the registration of a new MIME content This specification requests the registration of a new MIME media type
type according to the procedures of RFC 4288 [RFC4288] and guidelines according to the procedures of RFC 4288 [RFC4288] and guidelines in
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
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: 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].
Security considerations: Security considerations:
This content type is designed to carry vehicle crash data This media type is designed to carry vehicle crash data during
during an emergency call. an emergency call.
This data can contain personal information including vehicle This data can contain personal information including vehicle
VIN, location, direction, etc. Appropriate precautions need to VIN, location, direction, etc. Appropriate precautions need to
be taken to limit unauthorized access, inappropriate disclosure be taken to limit unauthorized access, inappropriate disclosure
to third parties, and eavesdropping of this information. to third parties, and eavesdropping of this information.
Please refer to Section 7 and Section 8 of [RFC7852] for more Please refer to Section 7 and Section 8 of [RFC7852] for more
information. information.
When this content type is contained in a signed or encrypted When this media type is contained in a signed or encrypted body
body part, the enclosing multipart (e.g., multipart/signed or part, the enclosing multipart (e.g., multipart/signed or
multipart/encrypted) has the same Content-ID as the data part. multipart/encrypted) has the same Content-ID as the data part.
This allows an entity to identify and access the data blocks it This allows an entity to identify and access the data blocks it
is interested in without having to dive deeply into the message is interested in without having to dive deeply into the message
structure or decrypt parts it is not interested in. (The structure or decrypt parts it is not interested in. (The
'purpose' parameter in a Call-Info header field identifies the 'purpose' parameter in a Call-Info header field identifies the
data, and the CID URL points to the data block in the body, data, and the CID URL points to the data block in the body,
which has a matching Content-ID body part header field). which has a matching Content-ID body part header field).
Interoperability considerations: None Interoperability considerations: None
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-14 to draft-ietf-15 18.1. Changes from draft-ietf-16 to draft-ietf-17
o Clarified that an INFO request is expected to have at least one
VEDS, MSD or metadata/control body part
o Corrected "content type" to "media type"
18.2. 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.2. Changes from draft-ietf-13 to draft-ietf-14 18.3. 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.3. Changes from draft-ietf-11 to draft-ietf-13 18.4. Changes from draft-ietf-11 to draft-ietf-13
o Fixed typos o Fixed typos
18.4. Changes from draft-ietf-10 to draft-ietf-11 18.5. 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.5. Changes from draft-ietf-09 to draft-ietf-10 18.6. 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.6. Changes from draft-ietf-08 to draft-ietf-09 18.7. 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.7. Changes from draft-ietf-07 to draft-ietf-08 18.8. 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.8. Changes from draft-ietf-06 to draft-ietf-07 18.9. Changes from draft-ietf-06 to draft-ietf-07
o Minor editorial changes o Minor editorial changes
18.9. Changes from draft-ietf-05 to draft-ietf-06 18.10. 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.10. Changes from draft-ietf-04 to draft-ietf-05 18.11. 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.11. Changes from draft-ietf-03 to draft-ietf-04 18.12. 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.12. Changes from draft-ietf-02 to draft-ietf-03 18.13. Changes from draft-ietf-02 to draft-ietf-03
o Additional clarifications and corrections o Additional clarifications and corrections
18.13. Changes from draft-ietf-01 to draft-ietf-02 18.14. 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.14. Changes from draft-ietf-00 to draft-ietf-01 18.15. 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.15. Changes from draft-gellens-02 to draft-ietf-00 18.16. 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.16. Changes from draft-gellens-01 to -02 18.17. 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.17. Changes from draft-gellens-00 to -01 18.18. 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
[I-D.ietf-ecrit-ecall] [I-D.ietf-ecrit-ecall]
Gellens, R. and H. Tschofenig, "Next-Generation Pan- Gellens, R. and H. Tschofenig, "Next-Generation Pan-
European eCall", draft-ietf-ecrit-ecall-13 (work in European eCall", draft-ietf-ecrit-ecall-17 (work in
progress), September 2016. progress), October 2016.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
<http://www.rfc-editor.org/info/rfc3023>. <http://www.rfc-editor.org/info/rfc3023>.
 End of changes. 53 change blocks. 
231 lines changed or deleted 237 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/