Subject: [media-types] Review request for application/EmergencyCall.VEDS+xml

From: Randall Gellens <[email-masked]>
Date: Wed, 21 Sep 2016 16:29:52 -0700

Hi all,

ECRIT draft https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10 
seeks to register a media type to carry the Vehicle Emergency Data 
Set (VEDS), defined by two emergency-services organizations, APCO and 
NENA.  This will be used by SIP-based vehicle-initiated emergency 
call systems.

The media registration is at 
https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10#page-32

Thank you.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A Sunday school is a prison in which children do penance for the
evil conscience of their parents.                --H. L. Mencken

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Sep 2016 10:03:19 -0700

At 4:29 PM -0700 9/21/16, Randall Gellens wrote:

>  Hi all,
>
>  ECRIT draft 
> https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10 seeks to 
> register a media type to carry the Vehicle Emergency Data Set 
> (VEDS), defined by two emergency-services organizations, APCO and 

Apologies for not including the verbatim text originally:

       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].

       Security considerations:

          This content 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.
          Please refer to Section 7 and Section 8 of [RFC7852] for more
          information.

          When this content type is contained in a signed or encrypted
          body part, the enclosing multipart (e.g., multipart/signed or
          multipart/encrypted) has the same Content-ID as the data part.
          This allows an entity to identify and access the data blocks it
          is interested in without having to dive deeply into the message
          structure or decrypt parts it is not interested in.  (The
          'purpose' parameter in a Call-Info header field identifies the
          data, and the CID URL points to the data block in the body,
          which has a matching Content-ID body part header field).

       Interoperability considerations: None

       Published specification: [VEDS]

       Applications which use this media type: Emergency Services

       Additional information: None

       Magic Number: None

       File Extension: .xml

       Macintosh file type code: 'TEXT'

       Persons and email addresses for further information: Randall
       Gellensm [email-masked]; Hannes Tschofenig,
       [email-masked]

       Intended usage: LIMITED USE

       Author: This specification is a work item of the IETF ECRIT
       working group, with mailing list address <[email-masked]>.

       Change controller: The IESG <[email-masked]>

-------------- Randomly selected tag: ---------------
Buy the latest Pentium so you can reboot faster.