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

[Alexey Melnikov <[e-mail]>]

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