Change line lenght to 80

Author: vpetersson

.dprint.json

@@ -1,8 +1,8 @@
 {
-  "lineWidth": 120,
+  "lineWidth": 80,
   "markdown": {
     "textWrap": "always",
-    "lineWidth": 120
+    "lineWidth": 80
   },
   "includes": ["**/*.md"],
   "excludes": [
@@ -13,4 +13,4 @@
   "plugins": [
     "https://plugins.dprint.dev/markdown-0.16.3.wasm"
   ]
-}
+}

README.md

@@ -8,89 +8,106 @@
 
 # CycloneDX Transparency Exchange API Standard
 
-The Transparency Exchange API is being worked on within the CycloneDX community with the goal to standardise the API in
-ECMA. A working group within ECMA TC54 has been formed - TC54 TG1. The working group has a slack channel in the
+The Transparency Exchange API is being worked on within the CycloneDX community
+with the goal to standardise the API in ECMA. A working group within ECMA TC54
+has been formed - TC54 TG1. The working group has a slack channel in the
 CycloneDX slack space.
 
 ![](images/tealogo.png)
 
 ## Introduction
 
-This specification defines a standard, format agnostic, API for the exchange of product related artefacts, like BOMs,
-between systems. The work includes:
+This specification defines a standard, format agnostic, API for the exchange of
+product related artefacts, like BOMs, between systems. The work includes:
 
-- [Discovery of servers](/discovery/readme.md): Describes discovery using the Transparency Exchange Identifier (TEI)
+- [Discovery of servers](/discovery/readme.md): Describes discovery using the
+  Transparency Exchange Identifier (TEI)
 - Retrieval of artefacts
 - Publication of artefacts
 - Authentication and authorization
 - Querying
 
-System and tooling implementors are encouraged to adopt this API standard for sending/receiving transparency artefacts
-between systems. This will enable more widespread "out of the box" integration support in the BOM ecosystem.
+System and tooling implementors are encouraged to adopt this API standard for
+sending/receiving transparency artefacts between systems. This will enable more
+widespread "out of the box" integration support in the BOM ecosystem.
 
 ## Use cases and requirements
 
-The working group has produced a list of use cases and requirements for the protocol.
+The working group has produced a list of use cases and requirements for the
+protocol.
 
 - [TEA requirements](doc/tea-requirements.md)
 - [TEA use cases](doc/tea-usecases.md)
 
 ## Data model
 
-- [TEA Product index](tea-index/tea-index.md): This is the starting point. A "product" is something for sale. The
-  [Transparency Exchange Identifier, TEI](/discovery/readme.md) points to a single product.
-- [TEA Leaf index](tea-leaf/tea-leaf.md): A leaf is a version entry. The leaf index has one entry per version of the
-  product.
-- [TEA Collection](tea-collection/tea-collection.md): The collection is a list of artefacts for a specific version. The
-  collection can be dynamic or static, depending on the implemenation.
+- [TEA Product index](tea-index/tea-index.md): This is the starting point. A
+  "product" is something for sale. The
+  [Transparency Exchange Identifier, TEI](/discovery/readme.md) points to a
+  single product.
+- [TEA Leaf index](tea-leaf/tea-leaf.md): A leaf is a version entry. The leaf
+  index has one entry per version of the product.
+- [TEA Collection](tea-collection/tea-collection.md): The collection is a list
+  of artefacts for a specific version. The collection can be dynamic or static,
+  depending on the implemenation.
 
 ## Artefacts available of the API
 
-The Transparency Exchange API (TEA) supports publication and retrieval of a set of transparency exchange artefacts. The
-API itself should not be restricting the types of the artefacts. A few examples:
+The Transparency Exchange API (TEA) supports publication and retrieval of a set
+of transparency exchange artefacts. The API itself should not be restricting the
+types of the artefacts. A few examples:
 
 ### xBOM
 
-Bill of materials for any type of component and service are supported. This includes, but is not limited to, SBOM, HBOM,
-AI/ML-BOM, SaaSBOM, and CBOM. The API provides a BOM format agnostic way of publishing, searching, and retrieval of xBOM
-artifacts.
+Bill of materials for any type of component and service are supported. This
+includes, but is not limited to, SBOM, HBOM, AI/ML-BOM, SaaSBOM, and CBOM. The
+API provides a BOM format agnostic way of publishing, searching, and retrieval
+of xBOM artifacts.
 
 ### CDXA
 
-Standards and requirements along with attestations to those standards and requirements are captured and supported by
-CycloneDX Attestations (CDXA). Much like xBOM, these are supply chain artifacts that are captured allowing for
+Standards and requirements along with attestations to those standards and
+requirements are captured and supported by CycloneDX Attestations (CDXA). Much
+like xBOM, these are supply chain artifacts that are captured allowing for
 consistent publishing, searching, and retrieval.
 
 ### VDR/VEX
 
-Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) are supported artifact types.
-Like the xBOM element, the VDR/VEX support is format agnostic. However, CSAF has its own distribution requirements that
-may not be compatible with APIs. Therefore, the initial focus will be on CycloneDX (VDR and VEX) and OpenVEX.
+Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange
+(VEX) are supported artifact types. Like the xBOM element, the VDR/VEX support
+is format agnostic. However, CSAF has its own distribution requirements that may
+not be compatible with APIs. Therefore, the initial focus will be on CycloneDX
+(VDR and VEX) and OpenVEX.
 
 ### CLE
 
-Product lifecycle events that are captured and communicated through the Common Lifecycle Enumeration will be supported.
-This includes product rebranding, repackaging, mergers and acquisitions, and product milestone events such as
+Product lifecycle events that are captured and communicated through the Common
+Lifecycle Enumeration will be supported. This includes product rebranding,
+repackaging, mergers and acquisitions, and product milestone events such as
 end-of-life and end-of-support.
 
 ### Insights
 
-Much of the focus on Software Transparency from the U.S. Government and others center around the concept of "full
-transparency". Consumers often need to ingest, process, and analyze SBOMs or VEXs just to be able to answer simple
+Much of the focus on Software Transparency from the U.S. Government and others
+center around the concept of "full transparency". Consumers often need to
+ingest, process, and analyze SBOMs or VEXs just to be able to answer simple
 questions such as:
 
 - Do any of my licensed products from Vendor A use Apache Struts?
-- Are any of my licensed products from Vendor A vulnerable to log4shell and is there any action I need to take?
+- Are any of my licensed products from Vendor A vulnerable to log4shell and is
+  there any action I need to take?
 
-Insights allows for "limited transparency" that can be asked and answered using an expression language that can be
-tightly scoped or outcome-driven. Insights also removes the complexities of BOM format conversion away from the
-consumers. An object model derived from CycloneDX will be an integral part of this API, since the objects within
-CycloneDX are self-contained (thus API friendly) and the specification supports all the necessary xBOM types along with
-CDXA.
+Insights allows for "limited transparency" that can be asked and answered using
+an expression language that can be tightly scoped or outcome-driven. Insights
+also removes the complexities of BOM format conversion away from the consumers.
+An object model derived from CycloneDX will be an integral part of this API,
+since the objects within CycloneDX are self-contained (thus API friendly) and
+the specification supports all the necessary xBOM types along with CDXA.
 
 ## Presentations and videos
 
-- You can find presentations in the repository in the [Presentations](/presentations) directory
+- You can find presentations in the repository in the
+  [Presentations](/presentations) directory
 - Our biweekly meetings are available on
   [YouTube playlist: Project Koala](https://www.youtube.com/playlist?list=PLqjEqUxHjy1XtSzGYL7Dj_WJbiLu_ty58)
 - KoalaCon 2024 - an introduction to the project - can be

api-flow/consumer.md

@@ -1,23 +1,29 @@
 # Transparency Exchange API: Consumer access
 
-The consumer access starts with a TEI, A transparency Exchange Identifier. This is used to find the API server as
-described in the [discovery document](/discovery/readme.md).
+The consumer access starts with a TEI, A transparency Exchange Identifier. This
+is used to find the API server as described in the
+[discovery document](/discovery/readme.md).
 
 ## API usage
 
 The standard TEI points to a product.
 
-- **List of TEA leafs**: Leafs are components of something sold. Each leaf has it's own versioning and it's own set of
-  artefacts. Note that a single artefact can belong to multiple versions of a leaf and multiple leafs.
-- **List of TEA collections**: For each leaf, there is a list of TEA collections as indicated by release date and a
-  version string. The TEA API has no requirements of type of version string (semantic or any other scheme) - it's just
-  an identifier set by the manufacturer. It's sorted by release date as a default.
-- **List of TEA artefacts**: The collection is unique for a version and contains a list of artefacts. This can be SBOM
-  files, VEX, SCITT, IN-TOTO or other documents.
-- **List of artefact formats**: An artefact can be published in multiple formats.
-
-The user has to know product TEI and version of each component (TEA LEAF) to find the list of artefacts for the used
-version.
+- **List of TEA leafs**: Leafs are components of something sold. Each leaf has
+  it's own versioning and it's own set of artefacts. Note that a single artefact
+  can belong to multiple versions of a leaf and multiple leafs.
+- **List of TEA collections**: For each leaf, there is a list of TEA collections
+  as indicated by release date and a version string. The TEA API has no
+  requirements of type of version string (semantic or any other scheme) - it's
+  just an identifier set by the manufacturer. It's sorted by release date as a
+  default.
+- **List of TEA artefacts**: The collection is unique for a version and contains
+  a list of artefacts. This can be SBOM files, VEX, SCITT, IN-TOTO or other
+  documents.
+- **List of artefact formats**: An artefact can be published in multiple
+  formats.
+
+The user has to know product TEI and version of each component (TEA LEAF) to
+find the list of artefacts for the used version.
 
 ## API flow
 

api/bomexchangeapi.md

@@ -1,12 +1,13 @@
 # CycloneDX BOM exchange API
 
-**Note:** this is an older version of the API not being worked on any more. This work will be replaced by the
-Transparency Exchange API.
+**Note:** this is an older version of the API not being worked on any more. This
+work will be replaced by the Transparency Exchange API.
 
 ## Conventions
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
-"OPTIONAL" in this document are to be interpreted as described in [RFC2119](http://www.ietf.org/rfc/rfc2119.txt).
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC2119](http://www.ietf.org/rfc/rfc2119.txt).
 
 ### ABNF Syntax
 
@@ -30,8 +31,9 @@ See also:
 
 ## Specification Compliance
 
-An API server/client can be referred to as compliant if it correctly implements any of the methods described within this
-specification. It is not a requirement to implement all the methods described.
+An API server/client can be referred to as compliant if it correctly implements
+any of the methods described within this specification. It is not a requirement
+to implement all the methods described.
 
 ## BOM Retrieval
 
@@ -49,36 +51,41 @@ bom-identifier       = *( pchar / "/" / "?" )
 
 The HTTP request method MUST be `GET`.
 
-For CycloneDX BOMs the `bom-identifier` MUST be either a CDX URN (https://www.iana.org/assignments/urn-formal/cdx) or a
-BOM serial number UUID URN (https://cyclonedx.org/docs/1.4/json/#serialNumber).
+For CycloneDX BOMs the `bom-identifier` MUST be either a CDX URN
+(https://www.iana.org/assignments/urn-formal/cdx) or a BOM serial number UUID
+URN (https://cyclonedx.org/docs/1.4/json/#serialNumber).
 
 For SPDX documents the `bom-identifier` MUST be the SPDX Document Namespace
 (https://spdx.github.io/spdx-spec/document-creation-information/#65-spdx-document-namespace-field).
 
 ### Server Requirements
 
-Servers MAY require authorization. If authorization is required it MUST use the HTTP `Authorization` header. If a server
-requires authorization, and no `Authorization` request header is supplied by the client, the server MUST respond with a
-401 Unauthorized response.
+Servers MAY require authorization. If authorization is required it MUST use the
+HTTP `Authorization` header. If a server requires authorization, and no
+`Authorization` request header is supplied by the client, the server MUST
+respond with a 401 Unauthorized response.
 
-Servers MUST honour the requested content types in the `Accept` header. If the server does not support any of the
-requested content types a HTTP 406 response MUST be returned. The 406 response body MUST contain a list of server
-supported content types in the below format with `text/plain` content type.
+Servers MUST honour the requested content types in the `Accept` header. If the
+server does not support any of the requested content types a HTTP 406 response
+MUST be returned. The 406 response body MUST contain a list of server supported
+content types in the below format with `text/plain` content type.
 
 ```abnf
 media-type *(", " media-type)
 ```
 
-e.g. `application/vnd.cyclonedx+xml; version=1.4, application/vnd.cyclonedx+xml; version=1.3`
+e.g.
+`application/vnd.cyclonedx+xml; version=1.4, application/vnd.cyclonedx+xml; version=1.3`
 
-API servers MUST provide the correct `Content-Type` HTTP response header. For example:
+API servers MUST provide the correct `Content-Type` HTTP response header. For
+example:
 
 ```http
 Content-Type: application/vnd.cyclonedx+xml; version=1.4
 ```
 
-If a BOM serial number UUID URN is used as the `bom-identifier`, the server MUST respond with the latest available
-version of the BOM.
+If a BOM serial number UUID URN is used as the `bom-identifier`, the server MUST
+respond with the latest available version of the BOM.
 
 ### Client Requirements
 
@@ -103,28 +110,33 @@ The HTTP request method MUST be `POST`.
 
 ### Server Requirements
 
-Servers MAY require authorization. If authorization is required it MUST use the HTTP `Authorization` header. If a server
-requires authorization, and no `Authorization` request header is supplied by the client, the server MUST respond with a
-401 Unauthorized response.
+Servers MAY require authorization. If authorization is required it MUST use the
+HTTP `Authorization` header. If a server requires authorization, and no
+`Authorization` request header is supplied by the client, the server MUST
+respond with a 401 Unauthorized response.
 
-Servers MUST honour the specified content type in the `Content-Type` header. If the server does not support the supplied
-content type a HTTP 415 Unsupported Media Type response MUST be returned. The 415 response body MUST contain a list of
-server supported content types in the below format with `text/plain` content type.
+Servers MUST honour the specified content type in the `Content-Type` header. If
+the server does not support the supplied content type a HTTP 415 Unsupported
+Media Type response MUST be returned. The 415 response body MUST contain a list
+of server supported content types in the below format with `text/plain` content
+type.
 
 ```abnf
 media-type *(", " media-type)
 ```
 
-e.g. `application/vnd.cyclonedx+xml; version=1.4, application/vnd.cyclonedx+xml; version=1.3`
+e.g.
+`application/vnd.cyclonedx+xml; version=1.4, application/vnd.cyclonedx+xml; version=1.3`
 
-If the submitted BOM has been successfully submitted the API server MUST respond with an appropriate 2xx HTTP status
-code.
+If the submitted BOM has been successfully submitted the API server MUST respond
+with an appropriate 2xx HTTP status code.
 
 ### Client Requirements
 
 Clients MUST support an optional `Authorization` header being specified.
 
-Clients MUST provide the correct `Content-Type` HTTP request header. For example:
+Clients MUST provide the correct `Content-Type` HTTP request header. For
+example:
 
 ```http
 Content-Type: application/vnd.cyclonedx+xml; version=1.4