From 4e63281c2ec8b4b67b7033c3211b49aebdd3276f Mon Sep 17 00:00:00 2001 From: "A.J. Stein" Date: Mon, 6 Jan 2025 06:53:13 -0500 Subject: [PATCH] [skip ci] Touch up ADR13 final para for #1061 --- documents/adr/0013-handling-attachments.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/documents/adr/0013-handling-attachments.md b/documents/adr/0013-handling-attachments.md index ca6414923..6552fa689 100644 --- a/documents/adr/0013-handling-attachments.md +++ b/documents/adr/0013-handling-attachments.md @@ -24,7 +24,7 @@ There are a variety of use cases for managing and cross-referencing OSCAL and no Plan of Actions and Milestones (POAM) - + ``` @@ -38,7 +38,7 @@ The first approach would have FedRAMP developers and community implementers impo Plan of Actions and Milestones (POAM) - + ``` @@ -56,7 +56,7 @@ The second approach, to avoid the closed enumeration default with the first appr Plan of Actions and Milestones (POAM) - + ``` @@ -68,7 +68,7 @@ The second approach, to avoid the closed enumeration default with the first appr Plan of Actions and Milestones (POAM) - + ``` @@ -82,21 +82,21 @@ This approach uses a `@class` to the prop to identify FedRAMP use cases at the r Plan of Actions and Milestones (POAM) - + ``` ### Approach 4 -This approach uses media type parameters for each encoding or data format representation of an attachment. This feature of media types is optional, as specified in IETF [RFC 6838](https://datatracker.ietf.org/doc/html/rfc6838#section-4.3). Although conceptually different and more expressive than flags, the key-value structure of media type parameters requires a balance between too generic (e.g `; oscal-use-case=foo`) and too specific (e.g. `; fedramp-use-case=poam`). Additionally, there may be some redundancy with respect to OSCAL data if FedRAMP developers do or do not explicitly use the unregistered media type sub-type (e.g. `media-type="=application/oscal+json; oscal-model=poam"`). FedRAMP developers must take care given the wide number of use cases and "parameter squatting" (with regards to generic ones such as `; oscal-use-case=...`) or how to equitably share use of use-case-specific ones. +This approach uses media type parameters for each encoding or data format representation of an attachment. This feature of media types is optional, as specified in IETF [RFC 6838](https://datatracker.ietf.org/doc/html/rfc6838#section-4.3). Although conceptually different and more expressive than flags, the key-value structure of media type parameters requires a balance between too generic (e.g `; oscal-use-case=foo`) and too specific (e.g. `; fedramp-use-case=poam`). Additionally, there may be some redundancy with respect to OSCAL data if FedRAMP developers do or do not explicitly use the unregistered media type sub-type (e.g. `media-type="application/oscal+json; oscal-model=poam"`). FedRAMP developers must take care given the wide number of use cases and "parameter squatting" (with regards to generic ones such as `; oscal-use-case=...`) or how to equitably share use of use-case-specific ones. ```xml Plan of Actions and Milestones (POAM) - + ``` @@ -186,4 +186,4 @@ In the long-term, given community feedback and overlapping needs between FedRAMP ## Consequences -Without this change, it is impractical for FedRAMP developers and community of adopters to identify attachments, OSCAL or non-OSCAL, when multiple options exist with FedRAMP-specific use cases with their own business logic. For Approach 4 and others, community developers will need to invest effort in adding or changing the implementation. Identifying attachment data format and use case consistently for each attachment gives the most precision with limited overhead and an onramp to generalizing this approach without "namespace squatting" in the interim. +Without this change, it is impractical for FedRAMP developers and community adopters to identify attachments, OSCAL or non-OSCAL, when multiple options exist with FedRAMP-specific use cases with their own business logic. For Approach 4 and others, community developers will need to invest effort in adding or changing the implementation. Identifying attachment data format and use case consistently for each attachment gives the most precision with limited overhead. It also provides an onramp to generalize this approach without "namespace squatting" in the interim.