[media-types] [IANA #1451401] application/cloudevents-ba tch+json registration request

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? And should it include the JSON example(s) above?

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]