[media-types] [IANA #1443731] application/vnd.cmmf-efd +xml registration request

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? 

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]