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

Hi Sabrina,

> On 9 Apr 2026, at 21:16, Sabrina Tanamal via RT <[email protected]> wrote:
> 
> Hi Alexey,
> 
> We have a response from the applicant:
> 
> Applications which use this media type: The EFD may be used by CMMF Receivers, either stand-alone or embedded within other applications, to provide necessary configuration information to identify, locate, and recover media resources from CMMF bitstreams/Transport Objects.
> 
> ====
> 
> Does this work?

Yes.

Best Regards,
Alexey
> 
> Thanks,
> Sabrina
> 
>> On Wed Apr 08 08:57:13 2026, [email protected] wrote:
>> 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]