[media-types] Re: [IANA #1443847] text/cmcd registrati on request

Thank you for sharing the specification for CMCD.

>From RFC 6838

>  The "text" top-level type is intended for sending material that is  principally textual in form.

It is a categorizion, like audio and video, that defines the kind of content, and is not a judgement on how readable the content is.

application/xml and application/json can produce content that is perfectly readable and not require an application to process the content.

It is my opinion that the format presented here is not naturally understood text.  Even after explaining that bl is buffer lenth, it is not likely an average developer would understand the meaning of "lb=(523;v 64;a)" because that is not natural language.
I am not aware of any actual benefit that would come from registering this media type as "text/cmcd" instead of "application/cmcd".

If the requester is convinced that text/cmcd will somehow produce a better experience, then they should be aware of the fact that text sub-types are required to use CRLF to indicate line breaks.  That will require updating the existing CMCD specification.


   The canonical form of any MIME "text" subtype MUST always represent a
   line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
   MIME "text" MUST represent a line break.  Use of CR and LF outside of
   line break sequences is also forbidden.

https://www.rfc-editor.org/rfc/rfc2046#section-4.1.1

Regards,

Darrel

________________________________
From: Amanda Baber via RT <[email protected]>
Sent: Monday, February 23, 2026 6:30 PM
Cc: [email protected] <[email protected]>; Darrel Miller <[email protected]>
Subject: [IANA #1443847] text/cmcd registration request

Hi Darrel,

The requester sent this message from the group chair:

===

The reviewer is working from an old v1 version of the spec. In v2, we have removed the JSON response. The mime-type “text/cmcd” is describing the new event data, which is a single string comprised of sets of human readable key-value pairs, separated by the newline character, as the body of a POST request. An example looks like this:

POST body:

bl=(6000),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),msd=812,mtp=(87000;v 49000;a),pb=(4200;v 256;a),pt=29188,sf=d,sid="session-id-123",sn=2,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752430000,v=2

This is designed to be human readable for quick debugging. Each key has a human readable abbreviation. For example ‘bl’ - buffer length, ‘br’ - bitrate, ‘cid’ - content ID etc. Engineers observing the CMCDv2 data in console and debug logs can instantly read it without having to run any sort of application parser.

We believe text/cmcd is the correct form for the following reasons:

V2 has shifted to a "newline-separated” format string format. Each line follows the same syntax as the v1 headers (e.g., br=2000,bl=5000), but they are stacked vertically. This is fundamentally text-based, not a JSON structure.
The text/ prefix informs the server and middleboxes that the payload is human-readable text. The /cmcd subtype specifically informs the log aggregator or CDN that this isn't just a random "note"—it is a structured CMCD report that needs to be parsed into its respective keys.

We would appreciate a re-review in light of the above information.

https://cta-wave.github.io/Resources/common-media-client-data--cta-5004-a.html

===

Does this work? If it's OK, is the submission OK to approve as-is?

thanks,
Amanda

On Sat Feb 21 20:31:54 2026, [email protected] wrote:
> Why is this a text/* media type?  It sounds a lot like structured
> content rather than text.  I can't tell because the specification
> isn't publicly available, but based on examples in the GitHub repo it
> doesn't look like text for human consumption to me.
>
> E.g.
> CMCDRequest:bl=21300,dl=18500,mtp=48100,nor="..%2F300kbps%2Ftrack.m4v",nrr="12323-
> 48763",su
> CMCD-Object:br=3200,d=4004,ot=v,tb=6000
> CMCD-Status:bs,rtp=12000
> CMCD-Session:cid="faec5fc2-ac30-11ea-bb37-
> 0242ac130002",pr=1.08,sf=d,sid="6e2fb550-c457-11e9-bb97-
> 0800200c9a66",st=v
>
> https://github.com/cta-wave/common-media-client-
> data/issues/185#issuecomment-3385947158
>
> This should just be registered as application/cmcd and the JSON
> variant can be application/cmcd+json.
>
> Darrel
>
> ________________________________
> From: Amanda Baber via RT <[email protected]>
> Sent: Wednesday, February 18, 2026 2:43 PM
> Cc: [email protected] <[email protected]>; Darrel Miller
> <[email protected]>
> Subject: [IANA #1443847] text/cmcd registration request
>
> Hi Darrel,
>
> Sending a reminder for this request from February 11th.
>
> thanks,
> Amanda
>
> On Wed Feb 11 19:11:38 2026, amanda.baber wrote:
> > Hi Darrel,
> >
> > Could you review this registration request for us by February 25th?
> >
> > The CTA has already been approved for standards-tree media type
> > registration.
> >
> > thanks,
> > Amanda
> >
> > =====
> >
> > Name: Alexandra Blasgen
> >
> > Email: [email protected]
> >
> > Media type name: text
> >
> > Media subtype name: cmcd
> >
> > Required parameters: N/A
> >
> > Optional parameters: N/A
> >
> > Encoding considerations: 8bit
> >
> > UTF-8 coded strings
> >
> > Security considerations: The privacy and security concerns are
> > discussed in sec. 7 of the CMCDv2 specification.
> >
> > Interoperability considerations: The MIME type describes a
> > standardized "snapshot" of media player state and conditions, and is
> > intended to enable interoperable analysis and monitoring solutions
> > for
> > media distribution.
> >
> > Published specification: This MIME type corresponds to the batch
> > format of the Common Media Client Data specification, CTA-5004.
> > The second version of this specification contains the batch
> > functionality. The final published version of the spec is available
> > at
> > https://www.cta.tech/standards/cta-5004.
> >
> > Applications which use this media: Requests with this MIME type are
> > emitted by media players. The receiving service would typically use
> > these for purposes such as, monitoring and fault analysis.
> >
> > Fragment identifier considerations: N/A
> >
> > Restrictions on usage: N/A
> >
> > 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): cmcd
> > 4. Macintosh file type code: N/A
> > 5. Object Identifiers: N/A
> >
> > General Comments:
> >
> > Person to contact for further information:
> >
> > 1. Name: Alexandra Blasgen
> > 2. Email: [email protected]
> >
> > Intended usage: COMMON
> >
> > Author/Change controller: Consumer Technology Association (CTA)

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