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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 5 Jul 2021 14:58:25 +0100

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 
> [email-masked] <mailto:[email-masked]>
> *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:[email-masked]>;tag=9fxced76sl Call-ID: 
> [email-masked] Geolocation: 
> <cid:[email-masked]> Geolocation-Routing: no Call-Info: 
> <cid:[email-masked]>; 
> 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: 
> <[email-masked]> 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:[email-masked]"> <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: <[email-masked]> Content-Disposition: 
> by-reference;handling=optional { "esn": "555", "locality": "Belcher's 
> Corners, Arachnid County, Maryland" } --boundary1-- |
> ------------------------------------------------------------------------
>
> Thank you.
>
> --Randall
>
>
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 05 Jul 2021 07:28:09 -0700

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

--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 
>> <[email-masked]> wrote:
>>
>> Hi Randy,
>>
>>> service number (ESN) information as an Emergency Call Data block. 
>>> This will be used by gateway systems for interoperability between 
>>> America. The document is the NENA Legacy Selective Router Gateway 
>>> (LSRG) Standard, NENA-STA-034.1 (work in progress).
>>>
>>> MIME media type name: application
>>> MIME subtype name: EmergencyCallData.LegacyESN+json
>>>
>> 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.
>>
>>> Mandatory parameters: none
>>> Optional parameters: charset
>>> Encoding considerations: Uses JSON, which can employ 8-bit 
>> I think this means "binary", as this can be serialized into 1 long 
>> line longer than 1000 octets.
>>
>>> Security considerations: This media type carries a legacy ESN during 
>>> an emergency call.
>>>
>>> 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.
>>>
>>> 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 
>>> 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.
>>>
>>> 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 
>>> 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).
>>>
>>> 8.1 JSON Scheme Description for the Legacy ESN Additional Data Block
>>>
>>> {
>>>   "$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
>>>
>>> {
>>>   "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.
>>>
>>> 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 
>>> 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:[email-masked]> 
>>> <mailto:sip:[email-masked]>;tag=9fxced76sl
>>> Call-ID: [email-masked] 
>>> <mailto:[email-masked]>
>>> Geolocation: <cid:[email-masked]> <cid:[email-masked]>
>>> Geolocation-Routing: no
>>> Call-Info: <cid:[email-masked]> 
>>>           purpose=EmergencyCallData.LegacyESN
>>> Accept: application/sdp, application/pidf+xml,
>>>         application/EmergencyCallData.LegacyESN+json
>>>        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: <[email-masked]> 
>>> <mailto:[email-masked]>
>>> Content-Disposition: by-reference;handling=optional
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <presence
>>> <http://www.opengis.net/gml>
>>> <http://www.opengis.net/pidflo/1.0>
>>>    entity="sip:[email-masked]" 
>>> <mailto:sip:[email-masked]>>
>>>    <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:Dynamic>
>>>            </gp:location-info>
>>>            <gp:usage-rules/>
>>>        <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
>>>    </dm:device>
>>> </presence>
>>>
>>> --boundary1
>>> Content-Type: application/EmergencyCallData.LegacyESN+json
>>> Content-ID: <[email-masked]> 
>>> <mailto:[email-masked]>
>>> Content-Disposition: by-reference;handling=optional
>>>
>>> {
>>> "esn": "555",
>>> "locality": "Belcher's Corners, Arachnid County, Maryland"
>>> }
>>>
>>> --boundary1--
>>> Thank you.
>>>
>>> --Randall
>>>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://www.ietf.org/mailman/listinfo/media-types>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 5 Jul 2021 15:28:22 +0100

Hi Brian,

> 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

>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Randy,
>>
>>> *Security considerations:* This media type carries a legacy ESN 
>>> during an emergency call.
>>>
>>> *Persons and email addresses for further information:* Randall 
>>> Gellens [email-masked] 
>>> <mailto:[email-masked]>
>>> *Author:* This specification is a work item of the National 
>>> Emergency Number Association (NENA) 911 Core Services Committee, i3 
>>> encoded as a string. The ‘locality’ string helps in identifying the 
>>> ESN’s context (since ESNs are local rather than national in scope).
>>>
>>> digit string.", "examples": [ "555" ], "minLength": 3, "maxLength": 
>>> 5, "type": "string", "pattern": "^[0-9]{3,5}$" }, "locality": { 
>>> *8.3 Security and Privacy Considerations for the Legacy ESN 
>>> Additional Data Block*
>>>
>>> Local regulations may impose additional privacy protection requirements.
>>>
>>> by-reference;handling=optional <?xml version="1.0" 
>>> encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" 
>>> <dm:deviceID>1M8GDM9A_KP042788</dm:deviceID> </dm:device> 
>>> </presence> --boundary1 Content-Type: 
>>> application/EmergencyCallData.LegacyESN+json Content-ID: 
>>> <[email-masked]> Content-Disposition: 
>>> by-reference;handling=optional { "esn": "555", "locality": 
>>> "Belcher's Corners, Arachnid County, Maryland" } --boundary1-- |

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 5 Jul 2021 15:29:46 +0100

On 05/07/2021 15:28, Randall Gellens wrote:

> "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 :-).
>>>     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).
>>>
>>     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.
>>
>>     I think this means "binary", as this can be serialized into 1
>>     long line longer than 1000 octets.
>>
>>>     disclosure to third parties, and eavesdropping of this
>>>     information. Please refer to Section 9 and Section 10 of RFC7852
>>>     [13] for more information.
>>>
>>>     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).
>>>
>>>     Emergency Number Association (NENA) 911 Core Services Committee,
>>>     i3 Architecture Working Group.
>>>     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
>>>     "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" ] } |
>>>
>>>     |{ "esn": "555", "locality": "Belcher's Corners, Arachnid
>>>     County, Maryland" } |
>>>
>>>     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.
>>>
>>>     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:

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 05 Jul 2021 08:01:23 -0700

Thanks for reviewing it, Alexey.

--Randall

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

>>>> "title":

---

From: Brian Rosen <[email-masked]>
Date: Mon, 5 Jul 2021 10:07:26 -0400

Brian

> On Jul 5, 2021, at 9:58 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Randy,
> 
>> 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).
>> 
> 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"
> 
>> 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.
> 
>> 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.
>> 
>> 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.
>> 
>> Persons and email addresses for further information: Randall Gellens [email-masked] <mailto:[email-masked]>
>> 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:
>> 
>> 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.
>> 
>>   "$schema":     "http://json-schema.org/draft-07/schema#" <http://json-schema.org/draft-07/schema#>,
>>   "$id":         "urn:nena:schema:json:EmergencyCallData:LegacyESN:1.0",
>>         "description": "A legacy Emergency Service Number as a 3-5 digit string.",
>>         "examples":    [ "555" ],
>>         "minLength":   3,
>>         "maxLength":   5,
>>         "type":        "string",
>>         "description": "The source, locality, or area of significance of the ESN.",
>>         "type":        "string"
>>      }
>> 
>>   },
>> 
>> 
>>   "required": [ "esn" ]
>> 
>> }
>> 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.
>> 
>> The following is an example INVITE containing a Legacy ESN Additional Data Block:
>> 
>> From: <sip:[email-masked]> <mailto:sip:[email-masked]>;tag=9fxced76sl
>> Call-ID: [email-masked] <mailto:[email-masked]>
>> Call-Info: <cid:[email-masked]> <cid:[email-masked]>;
>> Content-ID: <[email-masked]> <mailto:[email-masked]>
>>    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:[email-masked]" <mailto:sip:[email-masked]>>
>>    <dm:device id="123">
>>        <gp:geopriv>
>>            <gp:location-info>
>> Content-ID: <[email-masked]> <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/media-types <https://www.ietf.org/mailman/listinfo/media-types>