--- 1/draft-ietf-ecrit-car-crash-12.txt 2016-10-03 11:16:12.029705896 -0700 +++ 2/draft-ietf-ecrit-car-crash-13.txt 2016-10-03 11:16:12.117708110 -0700 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: March 29, 2017 NeuStar, Inc. +Expires: April 6, 2017 NeuStar, Inc. H. Tschofenig Individual - September 25, 2016 + October 3, 2016 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-12.txt + draft-ietf-ecrit-car-crash-13.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 29, 2017. + This Internet-Draft will expire on April 6, 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 @@ -110,34 +110,35 @@ 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 . . . . . . . . . . . . . . . . 34 15.3. New Action Values . . . . . . . . . . . . . . . . . . . 34 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-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 + 17.1. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 37 + 17.2. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 + 17.3. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 + 17.4. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 + 17.5. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 38 + 17.6. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 38 + 17.7. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 38 + 17.8. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 + 17.9. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 + 17.10. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 + 17.11. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 + 17.12. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 39 + 17.13. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 39 + 17.14. Changes from draft-gellens-01 to -02 . . . . . . . . . . 39 + 17.15. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 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]. @@ -600,31 +601,31 @@ 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 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'. A VEDS data block is carried in a - SIP INFO request by using the INFO package defined in Section 11. + emergencyCallData.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'. 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.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 @@ -873,66 +874,66 @@ 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 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 - Remain calm. Help is on the way. - + Figure 7: Request Example 9.3. The element In [I-D.ietf-ecrit-ecall], the element is transmitted by the PSAP to acknowledge the MSD. Here, the element is also transmitted by the PSAP to acknowledge the VEDS data and by the IVS to acknowledge receipt of a element that requested the IVS 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 - - + Figure 8: Ack Example from IVS to PSAP 9.4. The element The element ([I-D.ietf-ecrit-ecall]) is transmitted by the IVS to indicate its capabilities to the PSAP. The element contains a child element per action supported by the vehicle. The vehicle MUST support sending @@ -956,37 +957,37 @@ created in Section 15.5 to contain lamp ID values. 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 - - + Figure 9: Capabilities Example 10. Test Calls An NG-ACN test call is a call that is recognized and treated to some extent as an NG-ACN call but not given emergency call treatment and not handled by a call taker. The specific handling of test NG-ACN calls is not itself standardized; the test call facility is intended to allow the IVS, user, or TSP to verify that an NG-ACN call can be @@ -1384,39 +1385,39 @@ false --boundary1 Content-Type: application/emergencyCallData.control+xml Content-ID: <1234567892@atlanta.example.com> Content-Disposition: by-reference;handling=optional - - + --boundary1-- 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 @@ -1707,129 +1708,132 @@ 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-10 to draft-ietf-11 +17.1. Changes from draft-ietf-11 to draft-ietf-13 + + o Fixed typos + +17.2. 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 +17.3. 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.3. Changes from draft-ietf-08 to draft-ietf-09 +17.4. 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.4. Changes from draft-ietf-07 to draft-ietf-08 +17.5. 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.5. Changes from draft-ietf-06 to draft-ietf-07 +17.6. Changes from draft-ietf-06 to draft-ietf-07 o Minor editorial changes -17.6. Changes from draft-ietf-05 to draft-ietf-06 +17.7. 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.7. Changes from draft-ietf-04 to draft-ietf-05 +17.8. 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.8. Changes from draft-ietf-03 to draft-ietf-04 +17.9. 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.9. Changes from draft-ietf-02 to draft-ietf-03 +17.10. Changes from draft-ietf-02 to draft-ietf-03 o Additional clarifications and corrections -17.10. Changes from draft-ietf-01 to draft-ietf-02 +17.11. 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.11. Changes from draft-ietf-00 to draft-ietf-01 +17.12. 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.12. Changes from draft-gellens-02 to draft-ietf-00 +17.13. 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.13. Changes from draft-gellens-01 to -02 +17.14. Changes from draft-gellens-01 to -02 o Fixed case of 'EmergencyCallData', in accordance with changes to [RFC7852] -17.14. Changes from draft-gellens-00 to -01 +17.15. 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 [I-D.ietf-ecrit-ecall] Gellens, R. and H. Tschofenig, "Next-Generation Pan- - European eCall", draft-ietf-ecrit-ecall-11 (work in - progress), August 2016. + European eCall", draft-ietf-ecrit-ecall-13 (work in + progress), September 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, .