[media-types] Re: [IANA #1451401] application/ cloudevents-batch+json registration request

Hi Amanda,

On 09/05/2026 03:21, Amanda Baber via RT wrote:
> Hi Alexey,
>
> We have a response from the requester:
>
> ===
>
> application/cloudevents+json is used when the HTTP body of a message contains exactly one CloudEvent. For example:
>
> {
> "specversion" : "1.0",
> "type" : "com.example.someevent",
> "source" : "/mycontext/4",
> "id" : "B234-1234-1234",
> "time" : "2018-04-05T17:31:00Z",
> "comexampleextension1" : "value",
> "comexampleothervalue" : 5,
> "datacontenttype" : "application/vnd.apache.thrift.binary",
> "data_base64" : "... base64 encoded string ..."
> }
>
> application/cloudevents-batch+json is used when the HTTP body of a message is setup to contain any number of CloudEvents. And in that case it’s a JSON array of individual CloudEvents. For example:
> [
> {
> "specversion" : "1.0",
> "type" : "com.example.someevent",
> "source" : "/mycontext/4",
> "id" : "B234-1234-1234",
> "time" : "2018-04-05T17:31:00Z",
> "comexampleextension1" : "value",
> "comexampleothervalue" : 5,
> "datacontenttype" : "application/vnd.apache.thrift.binary",
> "data_base64" : "... base64 encoded string ..."
> },
> {
> "specversion" : "1.0",
> "type" : "com.example.someotherevent",
> "source" : "/mycontext/9",
> "id" : "C234-1234-1234",
> "time" : "2018-04-05T17:31:05Z",
> "comexampleextension1" : "value",
> "comexampleothervalue" : 5,
> "datacontenttype" : "application/json",
> "data" : {
> "appinfoA" : "abc",
> "appinfoB" : 123,
> "appinfoC" : true
> }
> }
> ]
> Is a batch of two (2) CloudEvents.
>
> That’s really all there is to it… one vs multiple (batch) CloudEvents.
>
> ===
>
> How should we update the section for these two registrations? Should it be something like this?
>
> OLD: Applications which use this media: HTTP based application
>
> NEW: Applications which use this media: HTTP-based application. application/cloudevents+json is used when the HTTP body of a message contains exactly one CloudEvent. application/cloudevents-batch+json is used when the HTTP body of a message is setup to contain any number of CloudEvents. And in that case it’s a JSON array of individual CloudEvents.
>
> Or should each type's application section only mention itself?

The proposed text is fine and including it in both registrations is Ok.

> And should it include the JSON example(s) above?

I don't mind either way. If this is clear from the referenced 
specification, no need to include examples in registrations.


Best Regards,

Alexey

>
> thanks,
> Amanda
>
> On Fri May 08 13:01:01 2026, [email protected] wrote:
>> Hi Amanda,
>>
>> On 05/05/2026 03:04, Amanda Baber via RT wrote:
>>> Hi Alexey,
>>>
>>> A note: the "vnd." prefix in the request below was a mistake. They
>>> decided to remove that.
>> Can you please ask the requester to clarify the difference between
>> application/cloudevents-batch+json and application/cloudevents+json in
>> "Applications which use this media" field. Otherwise this would be
>> fine
>> to approve.
>>
>> Thank you,
>>
>> Alexey
>>
>>> thanks,
>>> Amanda
>>>
>>> On Tue May 05 02:03:51 2026, amanda.baber wrote:
>>>> Hi Alexey,
>>>>
>>>> This is the first of two requests from a Linux Foundation project
>>>> (the
>>>> ADs confirmed that these could be submitted as standards-tree
>>>> requests). Would you be able to review these by May 18th?
>>>>
>>>> thanks,
>>>> Amanda
>>>>
>>>> =====
>>>>
>>>> Name: Doug Davis
>>>>
>>>> Email:[email protected]
>>>>
>>>> Media type name: application
>>>>
>>>> Media subtype name: vnd.cloudevents-batch+json
>>>>
>>>> Required parameters: N/A
>>>>
>>>> Optional parameters: N/A
>>>>
>>>> Encoding considerations: binary
>>>>
>>>> as per application/json
>>>>
>>>> Security considerations: The CloudEvents specification and format
>>>> does
>>>> not directly deal with security with respect to on-the-wire
>>>> protections. Since the CloudEvents format is really about
>>>> standardizing how data appear within a message, not what the data
>>>> is,
>>>> it is assumed that existing transport security mechanisms will be
>>>> used. In this respect, CloudEvents is meant to be additive to
>>>> existing
>>>> transport flows.
>>>>
>>>> Specifically, to the points mentioned in the instructions:
>>>> - A CloudEvent is not meant to contain active or executable content
>>>> -
>>>> at least not as part of the CloudEvents definition itself. It's just
>>>> text/binary data to CloudEvents.
>>>> - CloudEvents itself doesn't need privacy or integrity services. If
>>>> needed by the application, they can layer that on top of the
>>>> CloudEvent structure, but it is out of scope for CloudEvents.
>>>>
>>>> Interoperability considerations: As this is a usage/variant of
>>>> application/json, this media type does not introduce any new
>>>> interoperability concerns.
>>>>
>>>> Published specification:
>>>> https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-
>>>> format.md
>>>>
>>>> Applications which use this media: HTTP based application
>>>>
>>>> Fragment identifier considerations: None but see:
>>>> https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-
>>>> format.md
>>>>
>>>> Restrictions on usage: None
>>>>
>>>> Provisional registration? (standards tree only): No
>>>>
>>>> Additional information:
>>>>
>>>> 1. Deprecated alias names for this type: None
>>>> 2. Magic number(s): None
>>>> 3. File extension(s): json
>>>> 4. Macintosh file type code: TEXT
>>>> 5. Object Identifiers: None
>>>>
>>>> General Comments: None
>>>>
>>>> Person to contact for further information:
>>>>
>>>> 1. Name: Doug Davis
>>>> 2. Email:[email protected]
>>>>
>>>> Intended usage: COMMON
>>>>
>>>> Author/Change controller: CloudEvents project in the Linux
>>>> Foundation
>>>> (Cloud Native Computing Foundation)
> _______________________________________________
> media-types mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

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