[media-types] Proposed registration of the Application/LegacyESN media type

[Randall Gellens <[e-mail]>]

Hi All,

A document currently in development by the National Emergency Number 
Association (NENA) i3 Architecture WG of the 911 Core Services Committee 
seeks to register a media type to carry legacy emergency service number 
(ESN) information as an Emergency Call Data block. This will be used by 
gateway systems for interoperability between next-generation (NG) and 
legacy emergency call systems in North America.  The document is the 
*NENA Legacy Selective Router Gateway (LSRG) Standard*, NENA-STA-034.1 
(work in progress).

The media registration template follows:

----
**MIME media type name:** application
**MIME subtype name:** EmergencyCallData.LegacyESN+json
**Mandatory parameters:** none
**Optional parameters:** charset
Indicates the character encoding of enclosed JSON.
**Encoding considerations:** Uses JSON, which can employ 8-bit 
characters, depending on the character encoding used.
**Security considerations:** This media type carries a legacy ESN during 
an emergency call.

This data contains location information.  Appropriate precautions should 
be taken to limit unauthorized access, inappropriate disclosure to third 
parties, and eavesdropping of this information.  Please refer to Section 
9 and Section 10 of RFC7852 [13] for more information.

This media format contains only static information (no active content).

When this media type is contained in an encrypted body part, the 
enclosing multipart (e.g., 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 to 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).

The published specification (see below) contains a fuller description of 
the security and privacy considerations.

**Interoperability considerations:** None
**Published specification:** [THIS DOCUMENT -- NENA-STA-034.1]
**Applications which use this media type:** Emergency Services
**Additional information:** None
**Magic Number:** None
**File Extension:** .json
**Macintosh file type code:** 'TEXT'
**Persons and email addresses for further information:** Randall Gellens 
[e-mail]
**Intended usage:** LIMITED USE
**Author:** This specification is a work item of the National Emergency 
Number Association (NENA) 911 Core Services Committee, i3 Architecture 
Working Group.
**Change controller:** NENA.

----

The document under development currently includes the following sections 
related to this MIME subtype:

**8	The Legacy ESN Additional Data Block**

This section defines the Legacy ESN additional data block per RFC 7852 
[13].  A Legacy ESN additional data block contains an ESN and a 
‘locality’ string indicating the source, locality, or area of 
significance of the ESN.  The ESN is a 3-5 digit integer number encoded 
as a string.  The ‘locality’ string helps in identifying the ESN’s 
context (since ESNs are local rather than national in scope).

A Legacy ESN Additional Data block is encoded as a JavaScript Object 
Notation (JSON) [47] object.  An ESN additional data block is 
transported as a MIME object (e.g., in SIP) using the 
'application/EmergencyCallData.LegacyESN+json' media type.

**8.1	JSON Scheme Description for the Legacy ESN Additional Data Block**

The following JSON schema defines the Legacy ESN object:

     {
       "$schema":     "http://json-schema.org/draft-07/schema#",
       "$id":         
"urn:nena:schema:json:EmergencyCallData:LegacyESN:1.0",
       "title":       "EmergencyCallData.LegacyESN",

       "type": "object",
       "properties":
       {

          "esn":
          {
             "description": "A legacy Emergency Service Number as a 3-5 
digit string.",
             "examples":    [ "555" ],
             "minLength":   3,
             "maxLength":   5,
             "type":        "string",
             "pattern":     "^[0-9]{3,5}$"
          },

          "locality":
          {
             "description": "The source, locality, or area of 
significance of the ESN.",
             "type":        "string"
          }

       },


       "required": [ "esn" ]

     }

**8.2	Example Legacy ESN Additional Data Block**

The following is an example of a valid Legacy ESN object:

     {
       "esn": "555",
       "locality": "Belcher's Corners, Arachnid County, Maryland"
     }

**8.3	Security and Privacy Considerations for the Legacy ESN Additional 
Data Block**

ESNs have been used within legacy emergency services in North America 
for decades.  ESNs are not directly used within next-generation 
emergency services, but may be conveyed by next-generation systems 
interconnected with legacy systems.  The information carried in an ESN 
data block does not introduce new security issues, although it may be 
advisable for systems to perform a basic sanity check on the values, to 
avoid sending an invalid ESN to a legacy selective router.

A Legacy ESN data block contains only static information; no active 
content is conveyed.

ESNs are intrinsically associated with a location.  As with emergency 
service systems where location data is supplied or determined with the 
assistance of an end host, there is the possibility that  an ESN is 
incorrect, either intentially (e.g., in a denial of service attack 
against the emergency services infrastructure) or due to a 
malfunctioning device. The reader is referred to RFC 7378 [13]  for a 
discussion of some of these vulnerabilities.

An ESN is associated with a location, and so should be protected against 
unauthorized disclosure, as discussed in RFC 7852 [13].  Local 
regulations may impose additional privacy protection requirements.

**8.4	Example Call with a Legacy ESN Additional Data Block**

The following is an example INVITE containing a Legacy ESN Additional 
Data Block:

     INVITE urn:service:sos SIP/2.0
     To: urn:service:sos
     From: <sip:[e-mail]>;tag=9fxced76sl
     Call-ID: [e-mail]
     Geolocation: <cid:[e-mail]>
     Geolocation-Routing: no
     Call-Info: <cid:[e-mail]>;
               purpose=EmergencyCallData.LegacyESN
     Accept: application/sdp, application/pidf+xml,
             application/EmergencyCallData.LegacyESN+json
     Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
            SUBSCRIBE, NOTIFY, UPDATE
     CSeq: 31862 INVITE
     Content-Type: multipart/mixed; boundary=boundary1
     Content-Length: ...

     --boundary1
     Content-Type: application/sdp

     ...Session Description Protocol (SDP) goes here

     --boundary1
     Content-Type: application/pidf+xml
     Content-ID: <[e-mail]>
     Content-Disposition: by-reference;handling=optional

     <?xml version="1.0" encoding="UTF-8"?>
     <presence
        xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
        xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
        xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
        xmlns:gml="http://www.opengis.net/gml"
        xmlns:gs="http://www.opengis.net/pidflo/1.0"
        entity="sip:[e-mail]">
        <dm:device id="123">
            <gp:geopriv>
                <gp:location-info>
                    <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                       <gml:pos>-34.407 150.883</gml:pos>
                    </gml:Point>
                     <dyn:Dynamic>
                        <dyn:heading>278</dyn:heading>
                        <dyn:direction><dyn:direction>
                     </dyn:Dynamic>
                </gp:location-info>
                <gp:usage-rules/>
                <method>gps</method>
            </gp:geopriv>
            <timestamp>2012-04-5T10:18:29Z</timestamp>
            <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
        </dm:device>
     </presence>

     --boundary1
     Content-Type: application/EmergencyCallData.LegacyESN+json
     Content-ID: <[e-mail]>
     Content-Disposition: by-reference;handling=optional

     {
     "esn": "555",
     "locality": "Belcher's Corners, Arachnid County, Maryland"
     }

     --boundary1--

----


Thank you.

--Randall