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

RFC7852 created the EmergencyCallData tree.

Brian

> On Jul 5, 2021, at 9:58 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> Hi Randy,
> 
> On 22/06/2021 00:26, Randall Gellens wrote:
>> 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
>> 
> This wouldn't work, as this effectively requires creation of a new registration tree "EmergencyCallData", which requires publication of an IETF Standard Track document (see Section 3.5 of RFC 6838). I don't think this is what you want.
> 
> Two possible work arounds: either make it "vnd.EmergencyCallData.LegacyESN+json" or "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.
>> 
> I think this means "binary", as this can be serialized into 1 long line longer than 1000 octets.
> 
> I skimmed the rest of your message and it looked fine to me.
> 
> Best Regards,
> 
> Alexey
> 
>> 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 rg+nena.mime@randy.pensive.org <mailto:rg+nena.mime@randy.pensive.org>
>> 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#" <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:+13145551111@example.com> <mailto:sip:+13145551111@example.com>;tag=9fxced76sl
>> Call-ID: 3848276298220188511@atlanta.example.com <mailto:3848276298220188511@atlanta.example.com>
>> Geolocation: <cid:target123@example.com> <cid:target123@example.com>
>> Geolocation-Routing: no
>> Call-Info: <cid:1234567890@atlanta.example.com> <cid:1234567890@atlanta.example.com>;
>>           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: <target123@atlanta.example.com> <mailto:target123@atlanta.example.com>
>> 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" <http://www.opengis.net/gml>
>>    xmlns:gs="http://www.opengis.net/pidflo/1.0" <http://www.opengis.net/pidflo/1.0>
>>    entity="sip:+13145551111@example.com" <mailto:sip:+13145551111@example.com>>
>>    <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: <1234567890@atlanta.example.com> <mailto:1234567890@atlanta.example.com>
>> Content-Disposition: by-reference;handling=optional
>> 
>> {
>> "esn": "555",
>> "locality": "Belcher's Corners, Arachnid County, Maryland"
>> }
>> 
>> --boundary1--
>> Thank you.
>> 
>> --Randall
>> 
>> 
>> 
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org <mailto:media-types@ietf.org>
>> https://www.ietf.org/mailman/listinfo/media-types <https://www.ietf.org/mailman/listinfo/media-types>