[media-types] [IANA #1450117] application/spdx3+json reg istration request

Hi Alexey,

Resending this revision from May 25th.

thanks,
Amanda

On Mon May 25 18:30:31 2026, amanda.baber wrote:
> Hi Alexey,
> 
> Can you review this revised request? They've included inline responses
> to your review after the template.
> 
> thanks,
> Amanda
> 
> =====
> 
> REVISION:
> 
> Name: Arthit Suriyawongkul
> 
> Email: [email protected]
> 
> Media type name: application
> 
> Media subtype name: spdx3+json
> 
> Required parameters: N/A
> 
> Optional parameters: version
> 
> The version parameter refers to the SPDX specification version in use.
> It follows a MAJOR.MINOR.PATCH structure, where the MINOR and PATCH
> fields
> are optional.
> 
> version = 1*DIGIT [ "." 1*DIGIT [ "." 1*DIGIT ] ]
> 
> Encoding considerations: binary
> 
> This media type has all of the same encoding considerations of
> application/json as described in [RFC8259] Section 8.1.
> 
> Security considerations: The format supports the ExternalRef and
> ExternalIdentifier classes, which provide links to external databases
> such as the National Vulnerability Database (NVD) and various security
> advisories. Users should be aware that following these links involves
> interacting with external systems.
> 
> SPDX 3 JSON documents do not allow embedding executable content.
> 
> Additionally, this media inherits the interoperability security
> considerations of application/json as described in [RFC8259] Section
> 12.
> 
> Interoperability considerations: The application/spdx3+json media type
> can
> be distributed free of external systems or processors. Internet
> text-processing applications will likely consume these documents.
> 
> This media type is not compatible with SPDX JSON, which uses a
> different
> data model and a different media type (application/spdx+json).
> 
> The application/spdx3+json media type is a strict subset of JSON-LD
> 1.1
> (https://www.w3.org/TR/json-ld11/).
> 
> Additionally, this media type inherits the interoperability
> considerations
> of application/json as described in [RFC8259].
> 
> Published specification: Current versions of the specification are
> available
> at https://spdx.github.io/spdx-spec/.
> 
> SPDX 3 JSON schema and serialization details can be found at
> https://spdx.github.io/spdx-spec/latest/serializations/.
> 
> Applications which use this media:
> 
> This media is intended to represent supply chain transparency data and
> system metadata. This includes, but is not limited to, software bills
> of
> materials (SBOMs), hardware bills of materials (HBOMs), vulnerability
> and
> security risk communications, and AI transparency and compliance
> documentation. It will be used by tools that produce, consume, or
> analyze
> these artifacts to facilitate trust, security, and compliance across
> the
> supply chain.
> 
> Fragment identifier considerations: N/A
> 
> Restrictions on usage: N/A
> 
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> Deprecated alias names for this type: N/A
> 
> Magic number(s): N/A
> 
> File extension(s): .spdx3.json
> 
> Macintosh file type code: N/A
> 
> Object Identifiers: N/A
> 
> Person to contact for further information:
> 
> Name: Arthit Suriyawongkul
> 
> Email: [email protected]
> 
> Intended usage: COMMON
> 
> SPDX is an open standard. It is intended to be used to enable
> companies and
> organizations to share human-readable and machine-processable system
> package
> metadata to facilitate secure and compliant supply chain processes. An
> SPDX 3 JSON media type will be associated with a particular system
> package
> or set of packages and will contain information about it in the SPDX 3
> JSON format.
> 
> Author: Arthit Suriyawongkul <[email protected]>
> 
> Change controller: The Linux Foundation (contact: Kate Stewart
> <[email protected]>)
> 
> =====
> 
> RESPONSES:
> 
> > > This is similar to the two existing SPDX media types
> > > and aligned with SPDX principles to be vendor-neutral.
> > >
> > > Btw, we are aware of the possibility of using a "version" parameter
> > > to
> > > extend the existing "application/spdx+json" to accommodate multiple
> > > SPDX versions.
> > >
> > > At the same time, we see quite a big differences between the JSON
> > > formats of SPDX 3 and prior SPDX versions.
> >
> > Ok. It looks like SPDX 3 and SPDX 2 are not compatible (i.e. they use
> > different data models), so in this case a different media type is
> > fine.
> 
> Correct. They use different data models.
> 
> > > We are also aware of the implications of putting a version number
> > > inside the media type string itself (spdx3+json) and question if
> > > this
> > > means we will have to register another media type in the future
> > > when
> > > SPDX version 4 is released.
> >
> > It would depend on whether or not SPDX 4 is backward compatible with
> > SPDX 3. If it is, then application/spdx3+json can be used for SPDX 4.
> > If
> > not, then a new media type might be needed.
> >
> > The "Interoperability Considerations" section is specifically
> > designed
> > for discussing interoperability issues.
> 
> Thank you. It's good to know that registering a new media type isn't
> necessary,
> if the new version is backward compatible.
> (Although the mismatch between the media type string and the actual
> format
> version might cause confusion).
> 
> > > If IANA can further share its best practices and advice with us, it
> > > would be greatly appreciated.
> > >
> > > We track the application/spdx3+json media type registration here:
> > > https://github.com/spdx/spdx-spec/issues/1359
> > >
> > > Thank you again for your help, we are much appreciated.
> > >
> > > =====
> > >
> > > Name: Arthit Suriyawongkul
> > >
> > > Email: [email protected]
> > >
> > > Media type name: application
> > >
> > > Media subtype name: spdx3+json
> > >
> > > Required parameters: N/A
> > >
> > > Optional parameters: version
> > >
> > > The version parameter refers to the SPDX specification version
> > > in use.
> > >
> > > version = 1*DIGIT "." 1*DIGIT ["." 1*DIGIT]
> >
> > It is unclear to me why version is needed, unless there is a desire
> > to
> > possibly reuse the same media type for SPDX 3, 4, 5, etc.
> 
> Within SPDX 3, we have minor versions (3.0, 3.1, ...) as well.
> 3.1 extends 3.0 (containing more metadata fields) and maintains
> backward compatibility with 3.0, and so on.
> 
> 3rd-party tools, like protobom, use version parameter to help assist
> the version detection and decide how to process further.
> 
> (Note that protobom currently uses the wrong media type string, but
> its string matching method still allows it to work.
> See https://github.com/protobom/protobom/issues/409)
> 
> Without information from the version parameter, the SPDX 3 processor
> needs to start parsing the file first to get the version from the
> `specVersion` field.
> See the specVersion inside an SPDX 3 JSON file
> https://github.com/spdx/spdx-
> examples/blob/af7e2804a115b716335b4ead887e67fe9018fd60/software/example1/spdx3.0/example1.json#L6
> 
> (There is also a request for us to amend application/spdx+json (SPDX
> 2) to support an optional version parameter,
> as it will make their API use case easier.
> https://github.com/spdx/spdx-spec/issues/642
> -- we will work on that separately.)

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