--- 1/draft-ietf-ecrit-car-crash-18.txt 2016-11-14 18:13:09.131052367 -0800 +++ 2/draft-ietf-ecrit-car-crash-19.txt 2016-11-14 18:13:09.219054477 -0800 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: April 21, 2017 NeuStar, Inc. +Expires: May 18, 2017 NeuStar, Inc. H. Tschofenig Individual - October 18, 2016 + November 14, 2016 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-18.txt + draft-ietf-ecrit-car-crash-19.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 @@ -52,21 +52,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 April 21, 2017. + This Internet-Draft will expire on May 18, 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 @@ -75,80 +75,81 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 - 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9 - 6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 10 + 6. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Data Transport . . . . . . . . . . . . . . . . . . . . . . . 14 8. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 17 10. New Metadata/Control Values . . . . . . . . . . . . . . . . . 17 - 10.1. New values for the 'action' attribute' . . . . . . . . . 18 + 10.1. New values for the 'action' attribute' . . . . . . . . . 19 10.2. Request Example . . . . . . . . . . . . . . . . . . . . 19 - 10.3. The element . . . . . . . . . . . . . . . . . . . 19 + 10.3. The element . . . . . . . . . . . . . . . . . . . 20 10.4. The element . . . . . . . . . . . . . . . 20 11. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. The emergencyCallData.eCall.VEDS INFO package . . . . . . . . 22 - 12.1. Overall Description . . . . . . . . . . . . . . . . . . 22 + 12.1. Overall Description . . . . . . . . . . . . . . . . . . 23 12.2. Applicability . . . . . . . . . . . . . . . . . . . . . 23 - 12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 23 - 12.4. Info Package Parameters . . . . . . . . . . . . . . . . 23 - 12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 23 + 12.3. Info Package Name . . . . . . . . . . . . . . . . . . . 24 + 12.4. Info Package Parameters . . . . . . . . . . . . . . . . 24 + 12.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . 24 12.6. INFO Request Body Parts . . . . . . . . . . . . . . . . 24 12.7. Info Package Usage Restrictions . . . . . . . . . . . . 24 - 12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 24 + 12.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 25 12.9. Info Package Security Considerations . . . . . . . . . . 25 12.10. Implementation Details . . . . . . . . . . . . . . . . . 25 12.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 16.1. MIME Media Type Registration for 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 32 16.2. Registration of the 'VEDS' entry in the Emergency Call Additional Data registry . . . . . . . . . . . . . . . . 33 16.3. New Action Values . . . . . . . . . . . . . . . . . . . 33 - 16.4. Static Message Registry . . . . . . . . . . . . . . . . 34 - 16.5. Lamp ID Registry . . . . . . . . . . . . . . . . . . . . 35 - 16.6. Camera ID Registry . . . . . . . . . . . . . . . . . . . 36 + 16.4. Emergency Call Static Message Registry . . . . . . . . . 34 + 16.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 35 + 16.6. Emergency Call Vehicle Camera ID Registry . . . . . . . 36 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 18. Changes from Previous Versions . . . . . . . . . . . . . . . 37 - 18.1. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 37 - 18.2. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 - 18.3. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 - 18.4. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 - 18.5. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 - 18.6. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 - 18.7. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 - 18.8. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 38 - 18.9. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 - 18.10. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 - 18.11. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 - 18.12. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 - 18.13. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 - 18.14. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 - 18.15. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 - 18.16. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 - 18.17. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 - 18.18. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 - 18.19. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 + 18.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 37 + 18.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 + 18.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 + 18.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 + 18.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 + 18.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 + 18.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 + 18.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 + 18.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 + 18.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 + 18.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 + 18.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 + 18.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 + 18.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 + 18.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 + 18.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 + 18.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 + 18.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 + 18.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 + 18.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 19.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 19.2. Informative references . . . . . . . . . . . . . . . . . 42 + 19.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]. @@ -956,26 +958,28 @@ 10.4.1. Capabilities Example + supported-values="head;interior;fog-front; + fog-rear;brake;position-front;position-rear; + turn-left;turn-right;hazard"/> - + Figure 9: Capabilities Example 11. 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 @@ -1440,43 +1444,43 @@ implementations need to be careful that access is only provided within the context of an emergency call or to an emergency services provider (e.g., by verifying that the request for camera access is signed by a certificate issued by an emergency services registrar). 16. IANA Considerations This document registers the 'application/EmergencyCall.VEDS+xml' MIME media type, and adds "VEDS" to the Emergency Call Additional Data registry. This document adds to and creates sub-registries in the - 'Metadata/Control Data' registry created in [I-D.ietf-ecrit-ecall]. - This document registers a new INFO package. + "Emergency Call Metadata/Control Data" registry created in + [I-D.ietf-ecrit-ecall]. This document registers a new INFO package. 16.1. MIME Media Type Registration for 'application/ EmergencyCall.VEDS+xml' This specification requests the registration of a new MIME media type - according to the procedures of RFC 4288 [RFC4288] and guidelines in - RFC 3023 [RFC3023]. + according to the procedures of RFC 6838 [RFC6838] and guidelines in + RFC 7303 [RFC7303]. MIME media type name: application MIME subtype name: EmergencyCallData.VEDS+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See - Section 3.2 of RFC 3023 [RFC3023]. + Section 3.2 of RFC 7303 [RFC7303]. Security considerations: This media type is designed to carry vehicle crash data during an emergency call. This data can contain personal information including vehicle VIN, location, direction, etc. Appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. @@ -1521,53 +1525,54 @@ Data registry This specification requests IANA to add the 'VEDS' entry to the Emergency Call Additional Data registry, with a reference to this document. The Emergency Call Additional Data registry was established by [RFC7852]. 16.3. New Action Values This document adds new values for the 'action' attribute of the - element in the "Action Registry" registry created by + element in the "Emergency Call Action" registry created by [I-D.ietf-ecrit-ecall]. +---------------+--------------------------------------+ | Name | Description | +---------------+--------------------------------------+ | msg-static | Section 10.1 of [TBD: THIS DOCUMENT] | | | | | msg-dynamic | Section 10.1 of [TBD: THIS DOCUMENT] | | | | | honk | Section 10.1 of [TBD: THIS DOCUMENT] | | | | | lamp | Section 10.1 of [TBD: THIS DOCUMENT] | | | | | enable-camera | Section 10.1 of [TBD: THIS DOCUMENT] | +---------------+--------------------------------------+ - Table 2: Action Registry New Values + Table 2: Emergency Call Action Registry New Values -16.4. Static Message Registry +16.4. Emergency Call Static Message Registry - This document creates a new sub-registry called "Static Message - Registry" in the "Metadata/Control Data" registry established by - [I-D.ietf-ecrit-ecall]. Because all compliant vehicles are expected - to support all static messages translated into all languages - supported by the vehicle, it is important to limit the number of such - messages. As defined in [RFC5226], this registry operates under - "Publication Required" rules, which require a stable, public document - and implies expert review of the publication. The expert should - determine that the document has been published by an appropriate - emergency services organization (e.g., NENA, EENA, APCO) or by the - IETF with input from an emergency services organization, and that the - proposed message is sufficiently distinguishable from other messages. + This document creates a new sub-registry called "Emergency Call + Static Message" in the "Emergency Call Metadata/Control Data" + registry established by [I-D.ietf-ecrit-ecall]. Because all + compliant vehicles are expected to support all static messages + translated into all languages supported by the vehicle, it is + important to limit the number of such messages. As defined in + [RFC5226], this registry operates under "Publication Required" rules, + which require a stable, public document and implies expert review of + the publication. The expert should determine that the document has + been published by an appropriate emergency services organization + (e.g., NENA, EENA, APCO) or by the IETF with input from an emergency + services organization, and that the proposed message is sufficiently + distinguishable from other messages. The contents of this registry are: ID: An integer identifier to be used in the 'msgid' attribute of a metadata/control element. Message: The text of the message. Messages are listed in the registry in English; vehicles are expected to implement translations into languages supported by the vehicle. @@ -1575,37 +1580,37 @@ determined by the registrant; IANA assigns the IDs. Each message is assigned a consecutive integer value as its ID. This allows an IVS to indicate by a single integer value that it supports all messages with that value or lower. The initial set of values is listed in Table 3. +----+--------------------------------------------------------------+ | ID | Message | +----+--------------------------------------------------------------+ - | 1 | Emergency authorities are aware of your incident and | - | | location, but are unable to speak with you right now. We | - | | will help you as soon as possible. | + | 1 | Emergency services has noted your information and location, | + | | but cannot speak with you right now. We will help you as | + | | soon as possible. | +----+--------------------------------------------------------------+ - Table 3: Static Message Registry + Table 3: Emergency Call Static Message Registry Initial Values -16.5. Lamp ID Registry +16.5. Emergency Call Vehicle Lamp ID Registry - This document creates a new sub-registry called "Lamp ID Registry" in - the "Metadata/Control Data" registry established by - [I-D.ietf-ecrit-ecall]. This new sub-registry uniquely identifies - the names of automotive lamps (lights). As defined in [RFC5226], - this registry operates under "Expert Review" rules. The expert - should determine that the proposed lamp name is clearly - understandable and is sufficiently distinguishable from other lamp - names. + This document creates a new sub-registry called "Emergency Call + Vehicle Lamp ID" in the "Emergency Call Metadata/Control Data" + registry established by [I-D.ietf-ecrit-ecall]. This new sub- + registry uniquely identifies the names of automotive lamps (lights). + As defined in [RFC5226], this registry operates under "Expert Review" + rules. The expert should determine that the proposed lamp name is + clearly understandable and is sufficiently distinguishable from other + lamp names. The contents of this registry are: Name: The identifier to be used in the 'lamp-ID' attribute of a metadata/control element. Description: A description of the lamp (light). The initial set of values is listed in Table 4. @@ -1628,31 +1633,32 @@ | | | | position-rear | Rear position/parking/standing lamps | | | | | turn-left | Left turn/directional lamps | | | | | turn-right | Right turn/directional lamps | | | | | hazard | Hazard/four-way lamps | +----------------+---------------------------------------------+ - Table 4: Lamp ID Registry Initial Values + Table 4: Emergency Call Lamp ID Registry Initial Values -16.6. Camera ID Registry +16.6. Emergency Call Vehicle Camera ID Registry - 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. + This document creates a new sub-registry called "Emergency Call + Vehicle Camera ID" in the "Emergency Call 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 a control element. Description: A description of the camera. The initial set of values is listed in Table 5. @@ -1678,218 +1684,198 @@ | | | | lane | Used by systems to identify road lane and/or | | | monitor vehicle's position within lane | | | | | 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 + Table 5: Emergency Call Vehicle Camera ID Registry Initial Values 17. Acknowledgements - 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. + We would like to thank Lena Chaponniere, Stephen Edge, Christer + Holmberg, and Allison Mankin 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. 18. Changes from Previous Versions -18.1. Changes from draft-ietf-17 to draft-ietf-18 +18.1. Changes from draft-ietf-18 to draft-ietf-19 + + o Fixed various nits + +18.2. Changes from draft-ietf-17 to draft-ietf-18 o Added additional text to "Rate of Info Requests" o Further corrected "content type" to "media type" -18.2. Changes from draft-ietf-16 to draft-ietf-17 +18.3. 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.3. Changes from draft-ietf-14 to draft-ietf-15 +18.4. Changes from draft-ietf-14 to draft-ietf-15 o Moved VEDS text from Introduction to new Vehicle Data section o Various clarifications and simplifications -18.4. Changes from draft-ietf-13 to draft-ietf-14 +18.5. Changes from draft-ietf-13 to draft-ietf-14 o Body parts now always sent enclosed in multipart (even if only body part in SIP message) and hence always have a Content- Disposition of By-Reference o Fixed typos. -18.5. Changes from draft-ietf-11 to draft-ietf-13 +18.6. Changes from draft-ietf-11 to draft-ietf-13 o Fixed typos -18.6. Changes from draft-ietf-10 to draft-ietf-11 +18.7. 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 -18.7. Changes from draft-ietf-09 to draft-ietf-10 +18.8. 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. -18.8. Changes from draft-ietf-08 to draft-ietf-09 +18.9. 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. -18.9. Changes from draft-ietf-07 to draft-ietf-08 +18.10. 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" -18.10. Changes from draft-ietf-06 to draft-ietf-07 +18.11. Changes from draft-ietf-06 to draft-ietf-07 o Minor editorial changes -18.11. Changes from draft-ietf-05 to draft-ietf-06 +18.12. 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. -18.12. Changes from draft-ietf-04 to draft-ietf-05 +18.13. Changes from draft-ietf-04 to draft-ietf-05 o Reworded security text in main document and in MIME registration for the VEDS object -18.13. Changes from draft-ietf-03 to draft-ietf-04 +18.14. 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 -18.14. Changes from draft-ietf-02 to draft-ietf-03 +18.15. Changes from draft-ietf-02 to draft-ietf-03 o Additional clarifications and corrections -18.15. Changes from draft-ietf-01 to draft-ietf-02 +18.16. 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 -18.16. Changes from draft-ietf-00 to draft-ietf-01 +18.17. 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 -18.17. Changes from draft-gellens-02 to draft-ietf-00 +18.18. 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 -18.18. Changes from draft-gellens-01 to -02 +18.19. Changes from draft-gellens-01 to -02 o Fixed case of 'EmergencyCallData', in accordance with changes to [RFC7852] -18.19. Changes from draft-gellens-00 to -01 +18.20. 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 19. References 19.1. Normative References [I-D.ietf-ecrit-ecall] Gellens, R. and H. Tschofenig, "Next-Generation Pan- - European eCall", draft-ietf-ecrit-ecall-17 (work in + European eCall", draft-ietf-ecrit-ecall-19 (work in progress), October 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, - . - - [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object - Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, - . - - [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and - Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, - December 2005, . - - [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for - Emergency and Other Well-Known Services", RFC 5031, - DOI 10.17487/RFC5031, January 2008, - . - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . - [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV - Presence Information Data Format Location Object (PIDF-LO) - Usage Clarification, Considerations, and Recommendations", - RFC 5491, DOI 10.17487/RFC5491, March 2009, - . - - [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. - Thomson, "Dynamic Extensions to the Presence Information - Data Format Location Object (PIDF-LO)", RFC 5962, - DOI 10.17487/RFC5962, September 2010, - . - - [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, - "Framework for Emergency Calling Using Internet - Multimedia", RFC 6443, DOI 10.17487/RFC6443, December - 2011, . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, . + [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, + DOI 10.17487/RFC7303, July 2014, + . + [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, . [VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/ NENA Data Standardization Workgroup, , "Vehicular Emergency Data Set (VEDS) version 3", July 2012, . @@ -1905,20 +1891,25 @@ Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, DOI 10.17487/RFC5069, January 2008, . [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, . + [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling Using Internet + Multimedia", RFC 6443, DOI 10.17487/RFC6443, December + 2011, . + [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, December 2014, . [triage-2008] National Center for Injury Prevention and Control, and Centers for Disease Control and Prevention, "Recommendations from the Expert Panel: Advanced Automatic Collision Notification and Triage of the Injured Patient", 2008, .