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

[Alexey Melnikov <[e-mail]>]

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
>