--- 1/draft-ietf-ecrit-car-crash-10.txt 2016-09-22 21:15:54.784500489 -0700 +++ 2/draft-ietf-ecrit-car-crash-11.txt 2016-09-22 21:15:54.868502577 -0700 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: March 25, 2017 NeuStar, Inc. +Expires: March 26, 2017 NeuStar, Inc. H. Tschofenig Individual - September 21, 2016 + September 22, 2016 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-10.txt + draft-ietf-ecrit-car-crash-11.txt Abstract This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the @@ -51,21 +51,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 25, 2017. + This Internet-Draft will expire on March 26, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -85,60 +85,61 @@ 6. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 13 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16 9. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17 9.1. New values for the 'action' attribute' . . . . . . . . . 18 9.2. Request Example . . . . . . . . . . . . . . . . . . . . . 19 9.3. The element . . . . . . . . . . . . . . . . . . . . 19 9.4. The element . . . . . . . . . . . . . . . 20 10. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22 - 11.1. Overall Description . . . . . . . . . . . . . . . . . . 22 + 11.1. Overall Description . . . . . . . . . . . . . . . . . . 23 11.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23 11.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23 - 11.4. Info Package Parameters . . . . . . . . . . . . . . . . 23 - 11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23 - 11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 23 - 11.7. Info Package Usage Restrictions . . . . . . . . . . . . 24 - 11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24 + 11.4. Info Package Parameters . . . . . . . . . . . . . . . . 24 + 11.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24 + 11.6. INFO Message Body Parts . . . . . . . . . . . . . . . . 24 + 11.7. Info Package Usage Restrictions . . . . . . . . . . . . 25 + 11.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25 11.9. Info Package Security Considerations . . . . . . . . . . 25 11.10. Implementation Details . . . . . . . . . . . . . . . . . 25 11.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.1. MIME Content-type Registration for 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32 15.2. Registration of the 'VEDS' entry in the Emergency Call Additional Data registry . . . . . . . . . . . . . . . . 33 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 33 15.4. Static Message Registry . . . . . . . . . . . . . . . . 34 15.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35 15.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17. Changes from Previous Versions . . . . . . . . . . . . . . . 37 - 17.1. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 37 - 17.2. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 - 17.3. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 - 17.4. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 - 17.5. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 - 17.6. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 - 17.7. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 38 - 17.8. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 38 - 17.9. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 - 17.10. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 - 17.11. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 - 17.12. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 - 17.13. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 17.1. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 37 + 17.2. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 + 17.3. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 + 17.4. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 + 17.5. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 + 17.6. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 + 17.7. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 38 + 17.8. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 + 17.9. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 + 17.10. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 + 17.11. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 + 17.12. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 + 17.13. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 + 17.14. Changes from draft-gellens-00 to -01 . . . . . . . . . . 39 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 40 18.2. Informative references . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document re-uses terminology defined in Section 3 of [RFC5012]. @@ -315,21 +316,21 @@ 'Application' media type) with a sub-type starting with 'EmergencyCallData.' o An entry for the block is added to the Emergency Call Additional Data Blocks sub-registry (established by [RFC7852]); the registry entry is the root of the MIME sub-type (not including the 'EmergencyCallData' prefix and any suffix such as '+xml') o A new INFO package is registered that permits carrying the new content type and the metadata/control object (defined in - [I-D.ietf-ecrit-ecall]) in INFO messages. + [I-D.ietf-ecrit-ecall]) in INFO requests. Section 6 describes how VEDS data and metadata/control are transported within NG-ACN calls. Section 7 describes how such calls are placed. These mechanisms are thus used to place emergency calls that are identifiable as ACN calls and that carry standardized crash data in an interoperable way. Calls by in-vehicle systems are placed using cellular networks, which @@ -371,21 +372,21 @@ technical aspects of [I-D.ietf-ecrit-ecall], which uses [RFC7852]; this makes it straightforward to use a different data set while keeping other technical aspects unchanged. Hence, both NG-eCall and the NG-ACN mechanism described here are compatible, differing primarily in the specific data block that is sent (the eCall MSD in the case of NG-eCall, and the APCO/NENA VEDS used in this document), and some additions to the metadata/control data block. If other regions adopt their own vehicle data sets, this can be similarly accomodated without changing other technical aspects. Note that any additional data blocks require a new INFO package to permit transport - within INFO messages. + within INFO requests. 4. Overview of Legacy Deployment Models Legacy (circuit-switched) systems for placing emergency calls by in- vehicle systems generally have some ability to convey at least location and in some cases telematics data to the PSAP. Most such systems use one of three architectural models, which are described here as: "Telematics Service Provider" (TSP), "direct", and "paired". These three models are illustrated below. @@ -576,104 +577,123 @@ +---+ ///----\\\ (undefined) | H | standard +------+ ||| IVS |||------------------>| S +------------------->+ PSAP | \\\----/// (undefined) +---+ crash + other data +------+ Figure 6: Next-Generation Paired Model If the call is routed to a PSAP that is not capable of processing the vehicle data, the PSAP ignores (or does not receive) the vehicle data. This is detectable by the IVS or TSP when the status response - to the INVITE (e.., 200 OK) lacks an eCall control structure - acknowledging receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or - TSP then proceeds as it would for a CS-ACN call (e.g., verbal - conveyance of data) + to the INVITE (e.., 200 OK) lacks a control structure acknowledging + receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then + proceeds as it would for a CS-ACN call (e.g., verbal conveyance of + data) 6. Data Transport [RFC7852] establishes a general mechanism for attaching blocks of data to a SIP emergency call. This mechanism permits certain emergency call MIME types to be attached to SIP messages. This document makes use of that mechanism. This document also registers an INFO package (in Section 11) to enable NG-ACN related data blocks - to be carried in INFO messages. + to be carried in SIP INFO requests (per [RFC6086], new INFO usages + require the definition of an INFO package). 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]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.VEDS+xml') in the Content-Type header field of the 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 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. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as a VEDS data block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's - value is 'emergencyCallData.VEDS'. The body part has a Content- - Disposition header field value of "By-Reference; handling=optional". - A VEDS data block is carried in an INFO message by using the INFO - package registration (defined in Section 11). + value is 'emergencyCallData.VEDS'. A VEDS data block is carried in a + SIP INFO request by using the INFO package defined in Section 11. 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 body part per [RFC7852]. The body part is identified by its MIME - content-type ('application/emergencyCallData.eCall.control+xml') in - the Content-Type header field of the body part. The body part is + content-type ('application/emergencyCallData.control+xml') in the + Content-Type header field of the 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 message is marked as containing the 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 contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as a metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is - 'emergencyCallData.eCall.control'. The body part has a Content- - Disposition header field value of "By-Reference; handling=optional". - A metadata/control object is carried in an INFO message by using the - INFO package registration (defined in Section 11). + 'emergencyCallData.control'. A metadata/control object is carried in + a SIP INFO request by using the INFO package defined in Section 11. + + As is necessary with message bodies, if a VEDS or a metadata/control + block is sent in the same message with another body part, a + multipart/mixed body part encloses all body parts. In some cases, + there are intermediate multipart body parts between the top level + multipart/mixed and the body part containing the VEDS or metadata/ + control object. + + A body part containing a VEDS or metadata/control object has a + Content-Disposition header field value containing "By-Reference" + unless it is the only body part in a SIP INFO request, in which case, + per [RFC6086], "INFO-Package" is used. An In-Vehicle System (IVS) initiating an NG-ACN call includes in the initial INVITE a VEDS data block and a metadata/control object - informing the PSAP of its capabilities. The PSAP creates a metadata/ + informing the PSAP of its capabilities. The VEDS and metadata/ + control body parts (and PIDF-LO) have a Content-Disposition header + field with the value "By-Reference; handling=optional". Specifying + handling=optional prevents the INVITE from being rejected if it is + processed by a legacy element (e.g., a gateway between SIP and + circuit-switched environments) that does not understand the VEDS or + metadata/control (or PIDF-LO) objects. The PSAP creates a metadata/ control object acknowledging receipt of the VEDS data and includes it - in the SIP final response to the INVITE. + in the SIP final response to the INVITE. The metadata/control object + is not attached to provisional (e.g., 180) responses. + + If the IVS receives an acknowledgment for a VEDS data object with + received=false, it indicates some fault with the transfer of the + VEDS, the VEDS content, or the PSAP's ability to properly receive, + decode and act on the VEDS. The IVS action is not defined (e.g., it + might only log an error). Since the PSAP is able to request an + updated VEDS during the call, if an initial VEDS is unsatisfactory in + any way, the PSAP can choose to request another one. A PSAP can request that the vehicle send an updated VEDS data block during a call. To do so, the PSAP creates a metadata/control object - requesting VEDS data and attaches it to a SIP INFO message which it - sends within the dialog. The IVS then attaches an updated VEDS data - object to a SIP INFO message and sends it within the dialog. The - metadata/control object and the VEDS data are both associated with - the INFO package registered by this document (in Section 11), and - hence sent per [RFC6086]. In addition, to align with the way a VEDS - or metadata/control block is transmitted in a non-INFO message, one - or more Call-Info header fields are included in the INFO message to - reference the VEDS or metadata/control block. If the body part - containing the VEDS or metadata/control block is the only body part - in the INFO, it has a Content-Disposition header field value of - "Info-Package; handling=optional". If it is contained within a - multipart body part, it has a Content-Disposition header field value - of "By-Reference; handling=optional". See Section 11 for more - information. + requesting VEDS data and attaches it to a SIP INFO request and sends + it within the dialog. The IVS then attaches an updated VEDS data + object to a SIP INFO request and sends it within the dialog. If the + IVS is unable to send the VEDS, it instead sends a metadata/control + object acknowledging the request with the 'success' parameter set to + 'false' and a 'reason' parameter (and optionally a 'details' + parameter) indicating why the request cannot be accomplished. Per + [RFC6086], metadata/control objects and VEDS data are sent using the + INFO package defined in Section 11. In addition, to align with the + way a VEDS or metadata/control block is transmitted in a SIP message + other than an INFO request, one or more Call-Info header fields are + included in the SIP INFO request to reference the VEDS or metadata/ + control block. See Section 11 for more information on the use of + INFO requests within NG-ACN calls. - If the IVS is aware that the VEDS data it sent previously has - changed, it MAY send an unsolicited MSD (in any convenient SIP - message, including an INFO) during the call. The PSAP sends an + If the IVS is aware that VEDS data it sent previously has changed, it + MAY send an unsolicited VEDS (in any convenient SIP message, + including an INFO request) during the call. The PSAP sends an acknowledgment of an unsolicited VEDS object (if the IVS sent the - unsolicited VEDS in an INFO, the acknowledgment is sent in a new - INFO, otherwise it is sent in the response to the message containing - the VEDS). - - Indicating "handling=optional" in the Content-Disposition header - field value protects the body part from being discarded by - intermediate entities that do not support it. + unsolicited VEDS in an INFO request, the acknowledgment is sent in a + new INFO request, otherwise it is sent in the response to the message + containing the VEDS). 7. Call Setup A next-generation In-Vehicle System (IVS) initiates an NG-ACN call with a SIP INVITE using one of the SOS sub-services "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI, standard sets of crash data and capabilities data encoded in standardized and registered formats, attached as additional data blocks as specified in Section 4.1 of [RFC7852]. As described in that document, each data block is identified by its MIME content- @@ -850,24 +869,23 @@ a feed from a camera. 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 one-way media stream for this purpose. 9.2. Request Example + xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control"> Remain calm. Help is on the way. @@ -883,26 +901,26 @@ 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 transmit VEDS data would not result in a separate element being sent, since the data object itself serves as acknowledgment.) An element sent by an IVS references the unique ID of the metadata/control object containing the request(s) and indicates whether the request was successfully performed, and if not, optionally includes an explanation. 9.3.1. Ack Examples + + xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control"> Figure 8: Ack Example from IVS to PSAP @@ -935,24 +953,23 @@ If the "enable-camera" action is supported, a child element with the 'action' attribute set to "enable-camera" is included, with the 'supported-values' attribute set to all supported camera IDs. A registry is created in Section 15.6 to contain camera ID values. 9.4.1. Capabilities Example + xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control"> @@ -1073,46 +1090,44 @@ None 11.6. INFO Message Body Parts The body for an emergencyCallData.eCall.VEDS info package is: o an application/emergencyCallData.eCall.VEDS+xml (containing a VEDS data block), or - o an application/emergencyCallData.eCall.control+xml (containing a + o an application/emergencyCallData.control+xml (containing a metadata/control object), or o an application/emergencyCallData.eCall.MSD+per (containing an MSD), or o a multipart body containing: * zero or one application/emergencyCallData.eCall.VEDS+xml part (containing a VEDS data block), - * zero or more application/emergencyCallData.eCall.control+xml + * zero or more application/emergencyCallData.control+xml (containing a metadata/control object), * zero or one application/emergencyCallData.eCall.MSD+per part (containing an MSD), 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 associated body part is referenced by a Call-Info header field at the top level of the SIP message. If the body part is the only body part, it has a Content-Disposition header field value of "INFO- - Package; handling=optional". If the body part is contained within a - multipart body part, it has a Content-Disposition header field value - of "By-Reference; handling=optional" (the top-level multipart body - part has "INFO-Package" in its Content-Disposition value). + Package". If the body part is contained within a multipart, it has a + Content-Disposition header field value of "By-Reference". Service providers are not expected to attach [RFC7852] Additional Data to an INFO request. See [TBD: THIS DOCUMENT] for more information. 11.7. Info Package Usage Restrictions Usage is limited to vehicle-initiated emergency calls as defined in [TBD: THIS DOCUMENT]. @@ -1228,39 +1243,38 @@ INVITE urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: Geolocation-Routing: no Call-Info: ; purpose=EmergencyCallData.VEDS Call-Info: ; - purpose=EmergencyCallData.ecall.control + purpose=emergencyCallData.control Accept: application/sdp, application/pidf+xml, - application/emergencyCallData.eCall.control+xml + application/emergencyCallData.control+xml Recv-Info: emergencyCallData.eCall Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE CSeq: 31862 INVITE - Content-Disposition: info-package - Content-Transfer-Encoding: binary Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp - ...Session Description Protocol (SDP) goes here + ...Session Description Protocol (SDP) goes here --boundary1 Content-Type: application/pidf+xml Content-ID: + Content-Disposition: by-reference;handling=optional @@ -1357,49 +1371,48 @@ true false true Driver false --boundary1 - Content-Type: application/EmergencyCallData.ecall.control+xml + Content-Type: application/emergencyCallData.control+xml Content-ID: <1234567892@atlanta.example.com> Content-Disposition: by-reference;handling=optional + xsi:schemaLocation="urn:ietf:params:xml:ns:EmergencyCallData:control"> --boundary1-- - Figure 11: SIP INVITE indicating a Vehicule-Initated Emergency Call + Figure 11: SIP INVITE for a Vehicle-Initated Emergency Call 13. Security Considerations Since this document relies on [I-D.ietf-ecrit-ecall] and [RFC7852], the security considerations described there and in [RFC5069] apply here. Implementors are cautioned to read and understand the discussion in those documents. As with emergency service systems where location data is supplied or determined with the assistance of an end host, there is the @@ -1636,22 +1649,22 @@ This document creates a new sub-registry called "Camera ID Registry" in the "Metadata/Control Data" registry established by [I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies automotive cameras. As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed camera name is clearly understandable and is sufficiently distinguishable from other camera names. The contents of this registry are: - Name: The identifier to be used in the 'camera-ID' attribute of an - eCall control element. + Name: The identifier to be used in the 'camera-ID' attribute of a + control element. Description: A description of the camera. The initial set of values is listed in Table 5. +-------------+-----------------------------------------------------+ | Name | Description | +-------------+-----------------------------------------------------+ | backup | Shows what is behind the vehicle, e.g., often used | | | for driver display when the vehicle is in reverse. | @@ -1676,114 +1689,124 @@ | interior | Shows the interior (e.g., driver) | | | | | night-front | Night-vision view of what is in front of the | | | vehicle | +-------------+-----------------------------------------------------+ Table 5: Camera ID Registry Initial Values 16. Acknowledgements - We would like to thank Christer Holmberg for his suggestions; Michael - Montag, Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, - and Rex Buddenberg for their feedback; and Ulrich Dietz for his help - with earlier versions of the original version of this document. + We would like to thank Lena Chaponniere, Stephen Edge, and Christer + Holmberg for their review and suggestions; Robert Sparks and Paul + Kyzivat for their help with the SIP mechanisms; Michael Montag, + Arnoud van Wijk, Ban Al-Bakri, Wes George, Gunnar Hellstrom, and Rex + Buddenberg for their feedback; and Ulrich Dietz for his help with + earlier versions of the original version of this document. 17. Changes from Previous Versions -17.1. Changes from draft-ietf-09 to draft-ietf-10 +17.1. Changes from draft-ietf-10 to draft-ietf-11 + + o Clarifications suggested by Christer + o Corrections to Content-Disposition text and examples as suggested + by Paul Kyzivat + + o Clarifications to Content-Disposition text and examples to clarify + that handling=optional is only used in the initial INVITE + +17.2. Changes from draft-ietf-09 to draft-ietf-10 o Fixed errors in examples found by Dale in eCall draft o Removed enclosing sub-section of INFO package registration section 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 field referencing them - o Other text changes per comments received from Christer and Ivo against eCall draft. -17.2. Changes from draft-ietf-08 to draft-ietf-09 +17.3. Changes from draft-ietf-08 to draft-ietf-09 o Added INFO package registration for eCall.VEDS o Moved element and other extension points back to eCall document so that extension points are in base spec (and also to get XML schema to compile) o Text changes for clarification. -17.3. Changes from draft-ietf-07 to draft-ietf-08 +17.4. Changes from draft-ietf-07 to draft-ietf-08 o Moved much of the metadata/control object from [I-D.ietf-ecrit-ecall] to this document as extensions o Editorial clarifications and simplifications o Moved "Call Routing" to be a subsection of "Call Setup" o Deleted "Profile" section and moved some of its text into "Introduction" -17.4. Changes from draft-ietf-06 to draft-ietf-07 +17.5. Changes from draft-ietf-06 to draft-ietf-07 o Minor editorial changes -17.5. Changes from draft-ietf-05 to draft-ietf-06 +17.6. Changes from draft-ietf-05 to draft-ietf-06 o Added clarifying text regarding signed and encrypted data o Additional informative text in "Migration to Next-Generation" section o Additional clarifying text regarding security and privacy. -17.6. Changes from draft-ietf-04 to draft-ietf-05 +17.7. Changes from draft-ietf-04 to draft-ietf-05 o Reworded security text in main document and in MIME registration for the VEDS object -17.7. Changes from draft-ietf-03 to draft-ietf-04 +17.8. Changes from draft-ietf-03 to draft-ietf-04 o Added example VEDS object o Additional clarifications and corrections o Removed references from Abstract o Moved Document Scope section to follow Introduction -17.8. Changes from draft-ietf-02 to draft-ietf-03 +17.9. Changes from draft-ietf-02 to draft-ietf-03 o Additional clarifications and corrections -17.9. Changes from draft-ietf-01 to draft-ietf-02 +17.10. Changes from draft-ietf-01 to draft-ietf-02 o This document now refers to [I-D.ietf-ecrit-ecall] for technical aspects including the service URN; this document no longer 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 and non-eCall o Added discussion of an NG-ACN call placed to a PSAP that doesn't support it o Minor wording improvements and clarifications -17.10. Changes from draft-ietf-00 to draft-ietf-01 +17.11. Changes from draft-ietf-00 to draft-ietf-01 o Added further discussion of test calls o Added further clarification to the document scope o Mentioned that multi-region vehicles may need to support other crash notification specifications such as eCall o Minor wording improvements and clarifications -17.11. Changes from draft-gellens-02 to draft-ietf-00 +17.12. Changes from draft-gellens-02 to draft-ietf-00 o Renamed from draft-gellens- to draft-ietf- 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 it -17.12. Changes from draft-gellens-01 to -02 +17.13. Changes from draft-gellens-01 to -02 o Fixed case of 'EmergencyCallData', in accordance with changes to [RFC7852] -17.13. Changes from draft-gellens-00 to -01 +17.14. Changes from draft-gellens-00 to -01 o Now using 'EmergencyCallData' for purpose parameter values and MIME subtypes, in accordance with changes to [RFC7852] o Added reference to RFC 6443 o Fixed bug that caused Figure captions to not appear 18. References 18.1. Normative References