See [TBD: This document].
END 13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control This section registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. URI: urn:ietf:params:xml:ns:eCall:control Registrant Contact: IETF, ECRIT working group,See [TBD: This document].
END 13.8. Registry creation This document creates a new registry called 'eCall Control Data'. The following sub-registries are created for this registry. 13.8.1. eCall Control Action Registry This document creates a new sub-registry called "eCall Control Action Registry". As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed action is within the purview of a vehicle, is sufficiently distinguishable from other actions, and the actions is clearly and fully described. In most cases, a published and stable document is referenced for the description of the action. The content of this registry includes: Name: The identifier to be used in the 'action' attribute of an eCall control 'request' element. Description: A description of the action. In most cases this will be a reference to a published and stable document. The description MUST specify if any attributes or child elements are optional or mandatory, and describe the action to be taken by the vehicle. The initial set of values is listed in Table 2. Gellens & Tschofenig Expires September 8, 2015 [Page 26] Internet-Draft Next-Generation eCall March 2015 +-------------+------------------------------+ | Name | Description | +-------------+------------------------------+ | send-data | Section xxx of this document | | | | | msg-static | Section xxx of this document | | | | | msg-dynamic | Section xxx of this document | | | | | honk | Section xxx of this document | | | | | lamp | Section xxx of this document | +-------------+------------------------------+ Table 2: eCall Control Action Registry Initial Values 13.8.2. eCall Static Message Registry This document creates a new sub-registry called "eCall Static Message Registry". 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 imply 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) and that the proposed message is sufficiently distinguishable from other messages. The content of this registry includes: ID: An integer identifier to be used in the 'msgid' attribute of an eCall control 'request' 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. When new messages are added to the registry, the message text is 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. Gellens & Tschofenig Expires September 8, 2015 [Page 27] Internet-Draft Next-Generation eCall March 2015 +----+--------------------------------------------------------------+ | ID | Message | +----+--------------------------------------------------------------+ | 1 | Emergency authorities are aware of your incident and | | | location. No one is free to speak with you right now. We | | | will help you as soon as possible. | +----+--------------------------------------------------------------+ Table 3: eCall Static Message Registry 13.8.3. eCall Reason Registry This document creates a new sub-registry called "eCall Reason Registry" which contains values for the 'reason' attribute of the 'ActionResult' element. As defined in [RFC5226], this registry operates under "Expert Review" rules. The expert should determine that the proposed reason is sufficiently distinguishable from other reasons and that the proposed description is understandable and correctly worded. The content of this registry includes: ID: A short string identifying the reason, for use in the 'reason' attribute of an 'ActionResult' element. Description: A description of the reason. The initial set of values is listed in Table 4. +------------------+------------------------------------------------+ | ID | Description | +------------------+------------------------------------------------+ | unsupported | The 'action' is not supported. | | | | | unable | The 'action' could not be accomplished. | | | | | data-unsupported | The data item referenced in a 'send-data' | | | request is not supported. | +------------------+------------------------------------------------+ Table 4: eCall Reason Registry 13.8.4. eCall Lamp ID Registry This document creates a new sub-registry called "eCall Lamp ID Registry" to standardize 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 Gellens & Tschofenig Expires September 8, 2015 [Page 28] Internet-Draft Next-Generation eCall March 2015 clearly understandable and is sufficiently distinguishable from other lamp names. The content of this registry includes: Name: The identifier to be used in the 'lamp-ID' attribute of an eCall control 'request' element. Description: A description of the lamp (light). The initial set of values is listed in Table 5. +----------------+---------------------------------------------+ | Name | Description | +----------------+---------------------------------------------+ | head | The main lamps used to light the road ahead | | | | | interior | Interior lamp, often at the top center | | | | | fog-front | Front fog lamps | | | | | fog-rear | Rear fog lamps | | | | | brake | Brake indicator lamps | | | | | position-front | Front position/parking/standing lamps | | | | | 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 5: eCall Lamp ID Registry Initial Values 14. Contributors Brian Rosen was a co-author of the original document upon which this document is based. 15. Acknowledgements We would like to thank Bob Williams and Ban Al-Bakri for their feedback and suggestions, and Keith Drage for his review comments. We would like to thank Michael Montag, Arnoud van Wijk, Gunnar Gellens & Tschofenig Expires September 8, 2015 [Page 29] Internet-Draft Next-Generation eCall March 2015 Hellstrom, and Ulrich Dietz for their help with the original document upon which this document is based. 16. Changes from Previous Versions 16.1. Changes from draft-ietf-01 to draft-ietf-02 o Added clarifying text reinforcing that the data exchange is for small blocks of data infrequently transmitted o Clarified that dynamic media is conveyed using SIP re-INVITE to establish a one-way media stream o Clarified that the scope is the needs of eCall within the SIP emergency call environment o Added informative statement that the document may be suitable for reuse by other ACN systems o Clarified that normative language for the control block applies to both IVS and PSAP o Removed 'ref', 'supported-mime', and 'media' elements o Minor wording improvements and clarifications 16.2. 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 in addition to eCall o Added details of the eCall metadata and control functionality o Added IANA registration for the MIME content type for the eCall control object o Added IANA registries for protocol elements and tokens used in the eCall control object o Minor wording improvements and clarifications 16.3. Changes from draft-gellens-03 to draft-ietf-00 o Renamed from draft-gellens- to draft-ietf-. o Added mention of and reference to ETSI TR "Mobile Standards Group (MSG); eCall for VoIP" o Added text to Introduction regarding migration/co-existence being out of scope o Added mention in Security Considerations that even if the network- supplied location is just the cell site, this can be useful as a sanity check on the IVS-supplied location o Minor wording improvements and clarifications Gellens & Tschofenig Expires September 8, 2015 [Page 30] Internet-Draft Next-Generation eCall March 2015 16.4. Changes from draft-gellens-02 to -03 o Clarifications and editorial improvements. 16.5. Changes from draft-gellens-01 to -02 o Minor wording improvements o Removed ".automatic" and ".manual" from "urn:service:test.sos.ecall" registration and discussion text. 16.6. Changes from draft-gellens-00 to -01 o Now using 'EmergencyCallData' for purpose parameter values and MIME subtypes, in accordance with changes to [additional-data-draft] o Added reference to RFC 6443 o Fixed bug that caused Figure captions to not appear 17. References 17.1. Normative References [EN_16072] CEN, , "Intelligent transport systems - eSafety - Pan- European eCall operating requirements", December 2011. [I-D.ietf-ecrit-additional-data] Randy, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data related to an Emergency Call", draft-ietf-ecrit-additional-data-24 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Gellens & Tschofenig Expires September 8, 2015 [Page 31] Internet-Draft Next-Generation eCall March 2015 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013. [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, July 2014. [TS22.101] 3GPP, , "Technical Specification Group Services and System Aspects; Service aspects; Service principles", . [additional-data-draft] Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and J. Winterbottom, "Additional Data related to an Emergency Call", draft-ietf-ecrit-additional-data-11 (work in progress), July 2013. [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall minimum set of data (MSD), EN 15722", June 2011. 17.2. Informative references [CEN] "European Committee for Standardization",