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

[Alexey Melnikov <[e-mail]>]

Hi Brian,

On 05/07/2021 15:07, Brian Rosen wrote:
> RFC7852 created the EmergencyCallData tree.

Thank you for pointing me to RFC 7852, I was not aware of it.

To be completely pedantic, RFC 7852 doesn't do such thing. It doesn't 
say that it registers any new "tree" (neither the word "tree" nor 
"facet" can be found in RFC 7852). However it does register several 
media types with the same "EmergencyCallData." prefix, so this can be 
considered such a registration.

Best Regards,

Alexey

> 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
>