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

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]