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

[Randall Gellens <[e-mail]>]

Thanks for reviewing it, Alexey.

--Randall

On 5 Jul 2021, at 7:29, Alexey Melnikov wrote:

> On 05/07/2021 15:28, Randall Gellens wrote:
>
>> Actually, it's RFC 8147 (Section 14.1) that created the 
>> "EmergencyCallData" media subtree. (It should have been RFC 7852, 
>> which first used it but didn't create it, so we retroactively created 
>> it in RFC 8147.)
>>
> Much better :-).
>>
>> --Randall
>>
>> On 5 Jul 2021, at 7:07, Brian Rosen wrote:
>>
>>     RFC7852 created the EmergencyCallData tree.
>>
>>     Brian
>>
>>>     On Jul 5, 2021, at 9:58 AM, Alexey Melnikov
>>>     <[e-mail] <mailto:[e-mail]>> 
>>> 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 [e-mail]
>>>>     <mailto:[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
>>>>
>>>>
>>>>     _______________________________________________
>>>>     media-types mailing list
>>>>     [e-mail]
>>>>     https://www.ietf.org/mailman/listinfo/media-types
>>