< draft-ietf-ecrit-ecall-13.txt   draft-ietf-ecrit-ecall-14.txt >
ECRIT R. Gellens ECRIT R. Gellens
Internet-Draft Core Technology Consulting Internet-Draft Core Technology Consulting
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: March 26, 2017 Individual Expires: April 6, 2017 Individual
September 22, 2016 October 3, 2016
Next-Generation Pan-European eCall Next-Generation Pan-European eCall
draft-ietf-ecrit-ecall-13.txt draft-ietf-ecrit-ecall-14.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 the Pan European in- mechanisms to support the next generation of the Pan European in-
vehicle emergency call service defined under the eSafety initiative vehicle emergency call service defined under the eSafety initiative
of the European Commission (generally referred to as "eCall"). eCall of the European Commission (generally referred to as "eCall"). eCall
is a standardized and mandated system for a special form of emergency is a standardized and mandated system for a special form of emergency
calls placed by vehicles, providing real-time communications and an calls placed by vehicles, providing real-time communications and an
integrated set of related data. integrated set of related data.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 March 26, 2017. This Internet-Draft will expire on April 6, 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 9 skipping to change at page 3, line 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
15.1. Service URN Registrations . . . . . . . . . . . . . . . 30 15.1. Service URN Registrations . . . . . . . . . . . . . . . 30
15.2. MIME Content-type Registration for 15.2. MIME Content-type Registration for
'application/emergencyCallData.eCall.MSD+per' . . . . . 31 'application/emergencyCallData.eCall.MSD+per' . . . . . 31
15.3. MIME Content-type Registration for 15.3. MIME Content-type Registration for
'application/emergencyCallData.control+xml' . . . . . . 32 'application/emergencyCallData.control+xml' . . . . . . 32
15.4. Registration of the 'eCall.MSD' entry in the Emergency 15.4. Registration of the 'eCall.MSD' entry in the Emergency
Call Additional Data Blocks registry . . . . . . . . . . 33 Call Additional Data Blocks registry . . . . . . . . . . 34
15.5. Registration of the 'control' entry in the Emergency 15.5. Registration of the 'control' entry in the Emergency
Call Additional Data Blocks registry . . . . . . . . . . 34 Call Additional Data Blocks registry . . . . . . . . . . 34
15.6. Registration of the emergencyCallData.eCall Info Package 34 15.6. Registration of the emergencyCallData.eCall Info Package 34
15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34 15.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 34
15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34 15.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 34
15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35 15.7.2. Registration for urn:ietf:params:xml:ns:control . . 35
15.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 15.8. Registry creation . . . . . . . . . . . . . . . . . . . 36
15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 35 15.8.1. Action Registry . . . . . . . . . . . . . . . . . . 36
15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 36 15.8.2. Reason Registry . . . . . . . . . . . . . . . . . . 37
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
18. Changes from Previous Versions . . . . . . . . . . . . . . . 37 18. Changes from Previous Versions . . . . . . . . . . . . . . . 38
18.1. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 37 18.1. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38
18.2. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 38 18.2. Changes from draft-ietf-12 to draft-ietf-13 . . . . . . 38
18.3. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 38 18.3. Changes from draft-ietf-11 to draft-ietf-12 . . . . . . 38
18.4. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 18.4. Changes from draft-ietf-09 to draft-ietf-11 . . . . . . 38
18.5. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 18.5. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39
18.6. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 18.6. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39
18.7. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 18.7. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 40
18.8. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 18.8. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 40
18.9. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 18.9. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 40
18.10. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 18.10. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 40
18.11. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 18.11. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40
18.12. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 18.12. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40
18.13. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40 18.13. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 41
18.14. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40 18.14. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 41
18.15. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41 18.15. Changes from draft-gellens-02 to -03 . . . . . . . . . . 41
18.16. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41 18.16. Changes from draft-gellens-01 to -02 . . . . . . . . . . 41
18.17. Changes from draft-gellens-00 to -01 . . . . . . . . . . 41
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
19.1. Normative References . . . . . . . . . . . . . . . . . . 41 19.1. Normative References . . . . . . . . . . . . . . . . . . 42
19.2. Informative references . . . . . . . . . . . . . . . . . 42 19.2. Informative references . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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].
Additionally, we use the following abbreviations: Additionally, we use the following abbreviations:
skipping to change at page 10, line 51 skipping to change at page 10, line 51
eCall requires the ability for the PSAP to acknowledge successful eCall requires the ability for the PSAP to acknowledge successful
receipt of an MSD sent by the IVS, and for the PSAP to request that receipt of an MSD sent by the IVS, and for the PSAP to request that
the IVS send an MSD (e.g., the call taker can initiate a request for the IVS send an MSD (e.g., the call taker can initiate a request for
a new MSD to see if there have been changes in the vehicle's state, a new MSD to see if there have been changes in the vehicle's state,
e.g., location, direction, number of fastened seatbelts). e.g., location, direction, number of fastened seatbelts).
This document defines a block of metadata/control data as an XML This document defines a block of metadata/control data as an XML
structure containing elements used for eCall and other vehicle- structure containing elements used for eCall and other vehicle-
initiated emergency call systems (i.e., in other regions) and initiated emergency call systems (i.e., in other regions) and
extension points. (This metadata/control block is in effect a high- extension points. (This metadata/control block is in effect a high-
level protocol between the PSAP and IVS.) When the PSAP sends an level protocol between the PSAP and IVS.) When the PSAP sends a
eCall metadata/control block in response to data sent by the IVS in a metadata/control block in response to data sent by the IVS in a SIP
SIP request other than INFO (e.g., the MSD in the initial INVITE), request other than INFO (e.g., the MSD in the initial INVITE), the
the metadata/control block is sent in the SIP response to that metadata/control block is sent in the SIP response to that request
request (e.g., the response to the INVITE request). When the PSAP (e.g., the response to the INVITE request). When the PSAP sends a
sends a control block in other circumstances (e.g., mid-call), the control block in other circumstances (e.g., mid-call), the control
control block is transmitted from the PSAP to the IVS in a SIP INFO block is transmitted from the PSAP to the IVS in a SIP INFO request
request within the established dialog. The IVS sends the requested within the established dialog. The IVS sends the requested data (the
data (the MSD) in a new INFO request (per [RFC6086]). This mechanism MSD) in a new INFO request (per [RFC6086]). This mechanism flexibly
flexibly allows the PSAP to send eCall-specific data to the IVS and allows the PSAP to send eCall-specific data to the IVS and the IVS to
the IVS to respond. INFO requests are sent using an appropriate INFO respond. INFO requests are sent using an appropriate INFO Package.
Package. See Section 6 for more information on attaching a metadata/ See Section 6 for more information on attaching a metadata/control
control block to a SIP message. See Section 10 for information about block to a SIP message. See Section 10 for information about the use
the use of INFO requests to carry data within an eCall. of INFO requests to carry data within an eCall.
This mechanism requires This mechanism requires
o An XML definition of the control object o An XML definition of the control object
o Extension points for use by eCall-like systems in other regions o Extension points for use by eCall-like systems in other regions
o A MIME type registration for the control object (so it can be o A MIME type registration for the control object (so it can be
carried in SIP messages and responses) carried in SIP messages and responses)
o An entry in the Emergency Call Additional Data Blocks registry so o An entry in the Emergency Call Additional Data Blocks registry so
that the control block can be recognized as emergency call that the control block can be recognized as emergency call
specific data within SIP messages specific data within SIP messages
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Examples: Examples:
<request action="send-data" supported-values="eCall.MSD" /> <request action="send-data" supported-values="eCall.MSD" />
It is OPTIONAL for the IVS to support the <capabilities> element. If It is OPTIONAL for the IVS to support the <capabilities> element. If
the IVS does not send a <capabilities> element, this indicates that the IVS does not send a <capabilities> element, this indicates that
the only <request> action supported by the IVS is 'send-data' with the only <request> action supported by the IVS is 'send-data' with
'datatype' set to 'eCall.MSD'. 'datatype' set to 'eCall.MSD'.
9.1.2.2. Capabilities Example 9.1.2.2. Capabilities Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<EmergencyCallData.eCallControl <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"> xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control">
<capabilities> <capabilities>
<request action="send-data" supported-values="eCall.MSD"/> <request action="send-data" supported-values="eCall.MSD"/>
</capabilities> </capabilities>
</EmergencyCallData.eCallControl> </EmergencyCallData.Control>
Figure 4: Capabilities Example Figure 4: Capabilities Example
9.1.3. The <request> element 9.1.3. The <request> element
A <request> element appears one or more times on its own or as a A <request> element appears one or more times on its own or as a
child of a <capabilities> element. It allows the PSAP to request child of a <capabilities> element. It allows the PSAP to request
that the IVS perform an action. The only action that MUST be that the IVS perform an action. The only action that MUST be
supported is to send an MSD. The following attributes and child supported is to send an MSD. The following attributes and child
elements are defined: elements are defined:
skipping to change at page 28, line 17 skipping to change at page 28, line 17
targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control" targetNamespace="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control" xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:control"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2009/01/xml.xsd"/> schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
<xs:element name="EmergencyCallData.eCallControl" <xs:element name="EmergencyCallData.control"
type="pi:eCallControlType"/> type="pi:controlType"/>
<xs:complexType name="eCallControlType"> <xs:complexType name="controlType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice> <xs:choice>
<xs:element name="capabilities" <xs:element name="capabilities"
type="pi:capabilitiesType"/> type="pi:capabilitiesType"/>
<xs:element name="request" type="pi:requestType"/> <xs:element name="request" type="pi:requestType"/>
<xs:element name="ack" type="pi:ackType"/> <xs:element name="ack" type="pi:ackType"/>
<xs:any namespace="##any" processContents="lax" <xs:any namespace="##any" processContents="lax"
minOccurs="0" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
skipping to change at page 30, line 25 skipping to change at page 30, line 25
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 12: Control Block Schema Figure 12: Control Block Schema
15. IANA Considerations 15. IANA Considerations
This document formalizes the "EmergencyCallData" media (MIME) subtype
tree. This tree is used only for content associated with emergency
communications. New subtypes in this tree can be registered by the
IETF or by other standards organizations working with emergency
communications, using the "Specification Required" rule, which
implies expert review. The designated expert is the ECRIT working
group.
15.1. Service URN Registrations 15.1. Service URN Registrations
IANA is requested to register the URN 'urn:service:sos.ecall' under IANA is requested to register the URN 'urn:service:sos.ecall' under
the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].
This service requests resources associated with an emergency call This service requests resources associated with an emergency call
placed by an in-vehicle system, carrying a standardized set of data placed by an in-vehicle system, carrying a standardized set of data
related to the vehicle and incident. Two sub-services are registered related to the vehicle and incident. Two sub-services are registered
as well: as well:
skipping to change at page 35, line 38 skipping to change at page 36, line 26
<body> <body>
<h1>Namespace for eCall Data</h1> <h1>Namespace for eCall Data</h1>
<h2>Control Block</h2> <h2>Control Block</h2>
<p>See [TBD: This document].</p> <p>See [TBD: This document].</p>
</body> </body>
</html> </html>
END END
15.8. Registry creation 15.8. Registry creation
This document creates a new registry called 'eCall Metadata/Control This document creates a new registry called 'Metadata/Control Data'.
Data'. The following sub-registries are created for this registry. The following sub-registries are created for this registry.
15.8.1. Action Registry 15.8.1. Action Registry
This document creates a new sub-registry called "Action Registry". This document creates a new sub-registry called "Action Registry".
As defined in [RFC5226], this registry operates under "Expert Review" As defined in [RFC5226], this registry operates under "Expert Review"
rules. The expert should determine that the proposed action is rules. The expert should determine that the proposed action is
within the purview of a vehicle, is sufficiently distinguishable from within the purview of a vehicle, is sufficiently distinguishable from
other actions, and the action is clearly and fully described. In other actions, and the action is clearly and fully described. In
most cases, a published and stable document is referenced for the most cases, a published and stable document is referenced for the
description of the action. description of the action.
skipping to change at page 37, line 44 skipping to change at page 38, line 23
feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith feedback and suggestion; Rex Buddenberg, Lena Chaponniere, Keith
Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and Drage, Stephen Edge, Wes George, Christer Holmberg, Ivo Sedlacek, and
James Winterbottom for their review and comments; Robert Sparks and James Winterbottom for their review and comments; Robert Sparks and
Paul Kyzivat for their help with the SIP mechanisms. We would like Paul Kyzivat for their help with the SIP mechanisms. We would like
to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and to thank Michael Montag, Arnoud van Wijk, Gunnar Hellstrom, and
Ulrich Dietz for their help with the original document upon which Ulrich Dietz for their help with the original document upon which
this document is based. this document is based.
18. Changes from Previous Versions 18. Changes from Previous Versions
18.1. Changes from draft-ietf-12 to draft-ietf-13 18.1. Changes from draft-ietf-13 to draft-ietf-14
o Added text to the IANA Considerations to formalize the
EmergencyCallData media subtree
o Fixed some typos
18.2. Changes from draft-ietf-12 to draft-ietf-13
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.2. Changes from draft-ietf-11 to draft-ietf-12 18.3. Changes from draft-ietf-11 to draft-ietf-12
o Fixed errors in examples found by Dale o Fixed errors in examples found by Dale
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 Deleted Call Routing section (7.1) in favor of a statement that o Deleted Call Routing section (7.1) in favor of a statement that
call routing is outside the scope of the document call routing is outside the scope of the document
o Other text changes per comments received from Christer and Ivo. o Other text changes per comments received from Christer and Ivo.
18.3. Changes from draft-ietf-09 to draft-ietf-11 18.4. Changes from draft-ietf-09 to draft-ietf-11
o Renamed INFO package to emergencyCallData.eCall.MSD o Renamed INFO package to emergencyCallData.eCall.MSD
o Changed INFO package to only permit MSD and metadata/control MIME o Changed INFO package to only permit MSD and metadata/control MIME
types types
o Moved <capabilities> element back from car-crash but made it o Moved <capabilities> element back from car-crash but made it
OPTIONAL OPTIONAL
o Moved other extension points back from car-crash so that extension o Moved other extension points back from car-crash so that extension
points are in base spec (and also to get XML schema to compile) points are in base spec (and also to get XML schema to compile)
o Text changes for clarification. o Text changes for clarification.
18.4. Changes from draft-ietf-08 to draft-ietf-09 18.5. Changes from draft-ietf-08 to draft-ietf-09
o Created a new "Data Transport" section that describes how the MSD o Created a new "Data Transport" section that describes how the MSD
and metadata/control blocks are attached, and then referred to and metadata/control blocks are attached, and then referred to
that section rather than repeat the information about the CID and that section rather than repeat the information about the CID and
Call-Info and so forth, which means most references to the Call-Info and so forth, which means most references to the
additional-data draft have now been deleted additional-data draft have now been deleted
o Mentioned edge cases where a PSAP response to INVITE isn't o Mentioned edge cases where a PSAP response to INVITE isn't
received by the IVS received by the IVS
o Reworded description of which status codes are used when a PSAP o Reworded description of which status codes are used when a PSAP
wishes to reject a call but inform the vehicle occupants that it wishes to reject a call but inform the vehicle occupants that it
is aware of the situation to be more definite is aware of the situation to be more definite
o Added examples showing INFO o Added examples showing INFO
o Added references for eCall test call requirement o Added references for eCall test call requirement
o Described meaning of eCall URNs in Section 8 as well as in IANA o Described meaning of eCall URNs in Section 8 as well as in IANA
registration registration
18.5. Changes from draft-ietf-07 to draft-ietf-08 18.6. Changes from draft-ietf-07 to draft-ietf-08
o eCall MSD now encoded as ASN.1 PER, using binary content transfer o eCall MSD now encoded as ASN.1 PER, using binary content transfer
encoding encoding
o Added text to point out aspects of call handling and metadata/ o Added text to point out aspects of call handling and metadata/
control usage, such as use in rejected calls, and solicited MSDs control usage, such as use in rejected calls, and solicited MSDs
o Revised use of INFO to require that when a request for an MSD is o Revised use of INFO to require that when a request for an MSD is
sent in INFO, the MSD sent in response is in its own INFO, not the sent in INFO, the MSD sent in response is in its own INFO, not the
response to the requesting INFO response to the requesting INFO
o Added material to INFO package registation to comply with o Added material to INFO package registation to comply with
Section 10 of [RFC6086] Section 10 of [RFC6086]
o Moved material not required by 3GPP into o Moved material not required by 3GPP into
[I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/ [I-D.ietf-ecrit-car-crash], e.g., some of the eCall metadata/
control elements, attributes, and values control elements, attributes, and values
o Revised test call wording to clarify that specific handling is out o Revised test call wording to clarify that specific handling is out
of scope of scope
o Revised wording throughout the document to simplify o Revised wording throughout the document to simplify
o Moved new Section 7.1 to be a subsection of 7 o Moved new Section 7.1 to be a subsection of 7
o Moved new Section Section 10 to be a main section instead of a o Moved new Section Section 10 to be a main section instead of a
subsection of Section 9 subsection of Section 9
o Revised SIP INFO usage and package registration per advice from o Revised SIP INFO usage and package registration per advice from
Robert Sparks and Paul Kyzivat Robert Sparks and Paul Kyzivat
18.6. Changes from draft-ietf-06 to draft-ietf-07 18.7. Changes from draft-ietf-06 to draft-ietf-07
o Fixed typo in Acknowledgements o Fixed typo in Acknowledgements
18.7. Changes from draft-ietf-05 to draft-ietf-06 18.8. Changes from draft-ietf-05 to draft-ietf-06
o Added additional security and privacy clarifications regarding o Added additional security and privacy clarifications regarding
signed and encrypted data signed and encrypted data
o Additional security and privacy text o Additional security and privacy text
o Deleted informative section on ESINets as unnecessary. o Deleted informative section on ESINets as unnecessary.
18.8. Changes from draft-ietf-04 to draft-ietf-05 18.9. Changes from draft-ietf-04 to draft-ietf-05
o Reworked the security and privacy considerations material in the o Reworked the security and privacy considerations material in the
document as a whole and in the MIME registation sections of the document as a whole and in the MIME registation sections of the
MSD and control objects MSD and control objects
o Clarified that the <actionResult> element can appear multiple o Clarified that the <actionResult> element can appear multiple
times within an <ack> element times within an <ack> element
o Fixed IMS definition o Fixed IMS definition
o Added clarifying text for the 'msgid' attribute o Added clarifying text for the 'msgid' attribute
18.9. Changes from draft-ietf-03 to draft-ietf-04 18.10. Changes from draft-ietf-03 to draft-ietf-04
o Added Privacy Considerations section o Added Privacy Considerations section
o Reworded most uses of non-normative "may", "should", "must", and o Reworded most uses of non-normative "may", "should", "must", and
"recommended." "recommended."
o Fixed nits in examples o Fixed nits in examples
18.10. Changes from draft-ietf-02 to draft-ietf-03 18.11. Changes from draft-ietf-02 to draft-ietf-03
o Added request to enable cameras o Added request to enable cameras
o Improved examples and XML schema o Improved examples and XML schema
o Clarifications and wording improvements o Clarifications and wording improvements
18.11. Changes from draft-ietf-01 to draft-ietf-02 18.12. Changes from draft-ietf-01 to draft-ietf-02
o Added clarifying text reinforcing that the data exchange is for o Added clarifying text reinforcing that the data exchange is for
small blocks of data infrequently transmitted small blocks of data infrequently transmitted
o Clarified that dynamic media is conveyed using SIP re-INVITE to o Clarified that dynamic media is conveyed using SIP re-INVITE to
establish a one-way media stream establish a one-way media stream
o Clarified that the scope is the needs of eCall within the SIP o Clarified that the scope is the needs of eCall within the SIP
emergency call environment emergency call environment
o Added informative statement that the document may be suitable for o Added informative statement that the document may be suitable for
reuse by other ACN systems reuse by other ACN systems
o Clarified that normative language for the control block applies to o Clarified that normative language for the control block applies to
both IVS and PSAP both IVS and PSAP
o Removed 'ref', 'supported-mime', and <media> elements o Removed 'ref', 'supported-mime', and <media> elements
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
18.12. Changes from draft-ietf-00 to draft-ietf-01 18.13. 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 in addition to eCall crash notification specifications in addition to eCall
o Added details of the eCall metadata and control functionality o Added details of the eCall metadata and control functionality
o Added IANA registration for the MIME content type for the control o Added IANA registration for the MIME content type for the control
object object
o Added IANA registries for protocol elements and tokens used in the o Added IANA registries for protocol elements and tokens used in the
control object control object
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
18.13. Changes from draft-gellens-03 to draft-ietf-00 18.14. Changes from draft-gellens-03 to draft-ietf-00
o Renamed from draft-gellens- to draft-ietf-. o Renamed from draft-gellens- to draft-ietf-.
o Added mention of and reference to ETSI TR "Mobile Standards Group o Added mention of and reference to ETSI TR "Mobile Standards Group
(MSG); eCall for VoIP" (MSG); eCall for VoIP"
o Added text to Introduction regarding migration/co-existence being o Added text to Introduction regarding migration/co-existence being
out of scope out of scope
o Added mention in Security Considerations that even if the network- o Added mention in Security Considerations that even if the network-
supplied location is just the cell site, this can be useful as a supplied location is just the cell site, this can be useful as a
sanity check on the IVS-supplied location sanity check on the IVS-supplied location
o Minor wording improvements and clarifications o Minor wording improvements and clarifications
18.14. Changes from draft-gellens-02 to -03 18.15. Changes from draft-gellens-02 to -03
o Clarifications and editorial improvements. o Clarifications and editorial improvements.
18.15. Changes from draft-gellens-01 to -02 18.16. Changes from draft-gellens-01 to -02
o Minor wording improvements o Minor wording improvements
o Removed ".automatic" and ".manual" from o Removed ".automatic" and ".manual" from
"urn:service:test.sos.ecall" registration and discussion text. "urn:service:test.sos.ecall" registration and discussion text.
18.16. Changes from draft-gellens-00 to -01 18.17. 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
[EN_16062] [EN_16062]
CEN, , "Intelligent transport systems - eSafety - eCall CEN, , "Intelligent transport systems - eSafety - eCall
High Level Application Requirements (HLAP) Using GSM/UMTS High Level Application Requirements (HLAP) Using GSM/UMTS
Circuit Switched Networks, EN 16062", April 2015. Circuit Switched Networks, EN 16062", April 2015.
[EN_16072] [EN_16072]
CEN, , "Intelligent transport systems - eSafety - Pan- CEN, , "Intelligent transport systems - eSafety - Pan-
European eCall operating requirements, EN 16072", April European eCall operating requirements, EN 16072", April
skipping to change at page 42, line 42 skipping to change at page 43, line 27
principles". principles".
19.2. Informative references 19.2. Informative references
[CEN] "European Committee for Standardization", [CEN] "European Committee for Standardization",
<http://www.cen.eu>. <http://www.cen.eu>.
[I-D.ietf-ecrit-car-crash] [I-D.ietf-ecrit-car-crash]
Gellens, R., Rosen, B., and H. Tschofenig, "Next- Gellens, R., Rosen, B., and H. Tschofenig, "Next-
Generation Vehicle-Initiated Emergency Calls", draft-ietf- Generation Vehicle-Initiated Emergency Calls", draft-ietf-
ecrit-car-crash-09 (work in progress), August 2016. ecrit-car-crash-12 (work in progress), September 2016.
[MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for
VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04),
April 2014. April 2014.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, DOI 10.17487/RFC5012, January 2008, RFC 5012, DOI 10.17487/RFC5012, January 2008,
<http://www.rfc-editor.org/info/rfc5012>. <http://www.rfc-editor.org/info/rfc5012>.
 End of changes. 33 change blocks. 
70 lines changed or deleted 84 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/