refactor: enforced 150 chars line limit on md sources

- distributed sentences across lines when reaching the 150 char limit
- added a single space between block qupte char (>) and quoted text in one structural element
- did NOT fix a reeated 'a a' ;-)
- rationale for line length limit and where spotted at lease one
  line per sentence policy is twofold: (1) avoid horizontal scrolls
  (2) more semantic diffs in the editorial phase
- the examples are in unqualified code blocks (triple backtick fenced))
  we should consider specializing as json those that after patching
  (filling in ellipsis cut markers with valid JSON elements).
  simeple content examples of field values may best remain untyped
- sync'ed the user facing delivery item in share

Signed-off-by: Stefan Hagen <[email protected]>

.editorconfig

@@ -38,6 +38,7 @@ indent_size = 2
 trim_trailing_whitespace = false
 indent_style = space
 indent_size = 2
+max_line_length = 150
 
 # JavaScript-specific settings
 [*.{js,ts}]

csaf_2.1/prose/edit/src/additional-conventions.md

@@ -11,9 +11,12 @@ The following rules MUST be applied to determine the filename for the CSAF docum
    * Lower case ASCII letters (0x61 - 0x7A)
    * digits (0x30 - 0x39)
    * special characters: `+` (0x2B), `-` (0x2D)
-   > The regex `[^+\-a-z0-9]+` can be used to find a character sequence which has to be replaced by an underscore. However, it SHALL NOT be applied before completing the first step.
+   > The regex `[^+\-a-z0-9]+` can be used to find a character sequence which has to be replaced by an underscore.
+   > However, it SHALL NOT be applied before completing the first step.
    >
-   > Even though the underscore `_` (0x5F) is a valid character in the filename it is replaced to avoid situations where the conversion rule might lead to multiple consecutive underscores. As a result, a `/document/tracking/id` with the value `2022_#01-A` is converted into `2022_01-a` instead of `2022__01-a`.
+   > Even though the underscore `_` (0x5F) is a valid character in the filename it is replaced to avoid situations
+   > where the conversion rule might lead to multiple consecutive underscores.
+   > As a result, a `/document/tracking/id` with the value `2022_#01-A` is converted into `2022_01-a` instead of `2022__01-a`.
 3. The file extension `.json` MUST be appended.
 
 *Examples 47:*
@@ -24,7 +27,8 @@ The following rules MUST be applied to determine the filename for the CSAF docum
   rhba-2019_0024.json
 ```
 
-> It is currently considered best practice to indicate that a CSAF document is invalid by inserting `_invalid` into the filename in front of the file extension.
+> It is currently considered best practice to indicate that a CSAF document is invalid by
+> inserting `_invalid` into the filename in front of the file extension.
 
 *Examples 48:*
 
@@ -36,7 +40,8 @@ The following rules MUST be applied to determine the filename for the CSAF docum
 
 ## Separation in Data Stream
 
-If multiple CSAF documents are transported via a data stream in a sequence without requests inbetween, they MUST be separated by the Record Separator in accordance with [cite](#RFC7464).
+If multiple CSAF documents are transported via a data stream in a sequence without requests inbetween,
+they MUST be separated by the Record Separator in accordance with [cite](#RFC7464).
 
 ## Sorting{#additional-conventions--sorting}
 

csaf_2.1/prose/edit/src/design-considerations-00.md

@@ -2,12 +2,24 @@
 
 The Common Security Advisory Framework (CSAF) is a language to exchange Security Advisories formulated in JSON.
 
-The term Security Advisory as used in this document describes any notification of security issues in products of and by providers. Anyone providing a product is considered in this document as a vendor, i.e. developers or maintainers of information system products or services. This includes all authoritative product vendors, Product Security Incident Response Teams (PSIRTs), and product resellers and distributors, including authoritative vendor partners.
-A security issue is not necessarily constrained to a problem statement, the focus of the term is on the security aspect impacting (or not impacting) specific product-platform-version combinations. Information on presence or absence of workarounds is also considered part of the security issue.
-This document is the definitive reference for the language elements of CSAF version 2.0. The encompassing JSON schema file noted in the Additional Artifacts section of the title page SHALL be taken as normative in the case a gap or an inconsistency in this explanatory document becomes evident.
-The following presentation in this section is grouped by topical area, and is not simply derivative documentation from the schema document itself. The information contained aims to be more descriptive and complete. Where applicable, common conventions are stated and known common issues in usage are pointed out informatively to support implementers of document producers and consumers alike.
+The term Security Advisory as used in this document describes any notification of security issues in products of and by providers.
+Anyone providing a product is considered in this document as a vendor, i.e. developers or maintainers of information system products or services.
+This includes all authoritative product vendors, Product Security Incident Response Teams (PSIRTs), and product resellers and distributors,
+including authoritative vendor partners.
+A security issue is not necessarily constrained to a problem statement, the focus of the term is on the security aspect impacting
+(or not impacting) specific product-platform-version combinations.
+Information on presence or absence of workarounds is also considered part of the security issue.
+This document is the definitive reference for the language elements of CSAF version 2.0.
+The encompassing JSON schema file noted in the Additional Artifacts section of the title page SHALL be taken as normative in the case
+a gap or an inconsistency in this explanatory document becomes evident.
+The following presentation in this section is grouped by topical area, and is not simply derivative documentation from the schema document itself.
+The information contained aims to be more descriptive and complete.
+Where applicable, common conventions are stated and known common issues in usage are pointed out informatively to support
+implementers of document producers and consumers alike.
 
-This minimal required information set does not provide any useful information on products, vulnerabilities, or security advisories. Thus, any real-world Security Advisory will carry additional information as specified in section 3 Schema elements.
+This minimal required information set does not provide any useful information on products, vulnerabilities, or security advisories.
+Thus, any real-world Security Advisory will carry additional information as specified in section 3 Schema elements.
 
-Care has been taken, to design the containers for product and vulnerability information to support fine-grained mapping of security advisories onto product and vulnerability and minimize data duplication through referencing.
+Care has been taken, to design the containers for product and vulnerability information to support fine-grained mapping of
+security advisories onto product and vulnerability and minimize data duplication through referencing.
 The display of the elements representing Product Tree and Vulnerability information has been placed in the sections named accordingly.

csaf_2.1/prose/edit/src/design-considerations-01-construction-principles.md

@@ -1,22 +1,34 @@
 ## Construction Principles
 
-A Security Advisory defined as a CSAF document is the result of complex orchestration of many players and distinct and partially difficult to play schemas.
+A Security Advisory defined as a CSAF document is the result of complex orchestration of many players and distinct and
+partially difficult to play schemas.
 
-The format chosen is [JSONSchema] which allows validation and delegation to sub schema providers. The latter aligns well with separation of concerns and shares the format family of information interchange utilized by the providers of product and vulnerability information which migrated from XML to JSON since the creation of CSAF CVRF version 1.2, the predecessor of this specification.
+The format chosen is [JSONSchema] which allows validation and delegation to sub schema providers.
+The latter aligns well with separation of concerns and shares the format family of information interchange utilized by
+the providers of product and vulnerability information which migrated from XML to JSON since the creation of CSAF CVRF version 1.2,
+the predecessor of this specification.
 
 The acronym CSAF, “Common Security Advisory Framework”, stands for the target of concerted mitigation and remediation accomplishment.
 
-Technically, the use of JSON schema allows validation and proof of model conformance (through established schema based validation) of the declared information inside CSAF documents.
+Technically, the use of JSON schema allows validation and proof of model conformance (through established schema based validation)
+of the declared information inside CSAF documents.
 
 The CSAF schema structures its derived documents into three main classes of the information conveyed:
 
 1. The frame, aggregation, and reference information of the document
 2. Product information considered relevant by the creator
 3. Vulnerability information and its relation to the products declared in 2.
 
-Wherever possible repetition of data has been replaced by linkage through ID elements. Consistency on the content level thus is in the responsibility of the producer of such documents, to link e.g. vulnerability information to the matching product.
+Wherever possible repetition of data has been replaced by linkage through ID elements.
+Consistency on the content level thus is in the responsibility of the producer of such documents,
+to link e.g. vulnerability information to the matching product.
 
-A dictionary like presentation of all defined schema elements is given in the section 3. Any expected relations to other elements (linkage) is described there. This linking relies on setting attribute values accordingly (mostly guided by industry best practice and conventions) and thus implies, that any deep validation on a semantic level (e.g. does the CWE match the described vulnerability) is to be ensured by the producer and consumer of CSAF documents. It is out of scope for this specification.
+A dictionary like presentation of all defined schema elements is given in the section 3.
+Any expected relations to other elements (linkage) is described there. This linking relies on setting attribute values accordingly
+(mostly guided by industry best practice and conventions) and thus implies,
+that any deep validation on a semantic level (e.g. does the CWE match the described vulnerability)
+is to be ensured by the producer and consumer of CSAF documents.
+It is out of scope for this specification.
 
 Proven and intended usage patterns from practice are given where possible.
 
@@ -38,10 +50,17 @@ Delegation to industry best practices technologies is used in referencing schema
   * Traffic Light Protocol (TLP)
     * Default Definition: https://www.first.org/tlp/
 
-Even though the JSON schema does not prohibit specifically additional properties and custom keywords, it is strongly recommended not to use them. Suggestions for new fields SHOULD be made through issues in the TC's GitHub.
+Even though the JSON schema does not prohibit specifically additional properties and custom keywords,
+it is strongly recommended not to use them. Suggestions for new fields SHOULD be made through issues in the TC's GitHub.
 
-> The standardized fields allow for scalability across different issuing parties and dramatically reduce the human effort and need for dedicated parsers as well as other tools on the side of the consuming parties.
+> The standardized fields allow for scalability across different issuing parties and dramatically reduce the human effort and
+> need for dedicated parsers as well as other tools on the side of the consuming parties.
 
-Section 4 defined profiles that are used to ensure a common understanding of which fields are required in a given use case. Additional conventions are stated in section 5. The tests given in section 6 support CSAF producers and consumers to verify rules from the specification which can not be tested by the schema. Section 7 states how to distribute and where to find CSAF documents. Safety, Security and Data Protection are considered in section 8. Finally, a set of conformance targets describes tools in the ecosystem.
+Section 4 defined profiles that are used to ensure a common understanding of which fields are required in a given use case.
+Additional conventions are stated in section 5.
+The tests given in section 6 support CSAF producers and consumers to verify rules from the specification which can not be tested by the schema.
+Section 7 states how to distribute and where to find CSAF documents.
+Safety, Security and Data Protection are considered in section 8.
+Finally, a set of conformance targets describes tools in the ecosystem.
 
 -------