[media-types] Re: [IANA #1443731] application/vnd.cm mf-efd+xml registration request

Alexey Melnikov <[email protected]> Wed, 8 Apr 2026 09:56:28 +0100
Newsgroups gmane.ietf.types
Message-ID <[email protected]>
Hi Amanda,

Sorry for dropping ball on this.

This seems fine to register, other than one question below:

On 18/03/2026 10:10, Amanda Baber via RT wrote:
> Hi Alexey,
>
> Sending a reminder for #2 of 3 from February 10th.
>
> thanks,
> Amanda
>
> On Tue Feb 10 18:41:26 2026, amanda.baber wrote:
>> Hi Alexey,
>>
>> This is #2 of 3 from ETSI.
>>
>> thanks,
>> Amanda
>>
>> =====
>>
>> Email:[email protected]
>>
>> Media type name: application
>>
>> Media subtype name: vnd.cmmf-efd+xml
>>
>> Required parameters: None
>>
>> Optional parameters: None
>>
>> Encoding considerations: binary
>>
>> UTF-8
>>
>> Security considerations: The EFD contains references to other
>> resources. It is coded in XML, and there are risks that deliberately
>> malformed XML can cause security issues. In addition, an EFD can be
>> authored that causes receiving clients to access other resources; if
>> widely distributed, this can be used to cause a denial of service
>> attack.
>> The EFD format does not incorporate any active or executable content.
>> However, other forms of material from outside sources can be
>> referenced by an EFD, and this material can contain active or
>> executable content. Such material is expected to be identified by its
>> own MIME type, and the security considerations of that format should
>> be taken into account.
>>
>> If operating in an insecure environment and required by the
>> content/service provider, elements and attributes of EFD may be
>> encrypted to protect their confidentiality by using the syntax and
>> processing rules specified in the W3C Recommendation "XML Encryption
>> Syntax and Processing".
>> If operating in an insecure environment and required by the
>> content/service provider, the digital signing and verification
>> procedures specified in the W3C Recommendation "XML Signature Syntax
>> and Processing" may be used to protect data origin authenticity and
>> integrity of the EFD
>>
>> Interoperability considerations: The present document defines a
>> platform-independent expression of a document, and it is intended that
>> wide interoperability can be achieved
>>
>> Published specification: ETSI TS 103 973
>>
>> Applications which use this media: Various
I need to see some examples of use (existing or planned), it doesn't 
have to be exhaustive. This field can help implementers to decide 
whether or not they might be interested in adding support for this media 
type.
>> Fragment identifier considerations: None
>>
>> Restrictions on usage: None
>>
>> Provisional registration? (standards tree only): No
>>
>> Additional information:
>>
>> 1. Deprecated alias names for this type: N/A
>> 2. Magic number(s): N/A
>> 3. File extension(s): efd
>> 4. Macintosh file type code: N/A
>> 5. Object Identifiers: N/A
>>
>> General Comments: None
>>
>> Person to contact for further information:
>>
>> 1. Name: Jason Cloud
>> 2. Email:[email protected]
>>
>> Intended usage: COMMON
>>
>> Author/Change controller: ETSI

Best Regards,

Alexey

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]