[media-types] Re: [IANA #1450117] application/spdx3+js on registration request

Alexey Melnikov <[email protected]> Fri, 5 Jun 2026 17:27:47 +0100
Newsgroups gmane.ietf.types
Message-ID <[email protected]>
Hi Amanda,

On 02/06/2026 06:11, Amanda Baber via RT wrote:
> Hi Alexey,
>
> Resending this revision from May 25th.

After reading replies to my comments, this version is fine to register.


Thank you,

Alexey

> 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]