Profile resolution spec has unusual rlink constraint

[GaryGapinski]

Question

Why does the following statement appear in the Internal References section?

When a rlink is encountered and is to be resolved, it MUST be resolved by using a HTTP request to retrieve a byte stream.

• Resolution is not the same as retrieval. An "HTTP request" might not be a GET; it might even choose to use HTTP/2 or HTTP/3. RFC 9110 is worth a read.
• The existence of a "byte stream" seems to be at a higher abstract level not related to retrieval of a resource (and questionably related to OSCAL). Can, e.g., a "byte stream" be partial with a promise to deliver later chunks?
• Unicode encoding is pertinent to a "byte stream". JSON requires UTF-8; XML does not.
• What action should be taken if the stated (but optional) media-type is not honored by the presumed "HTTP" correspondent (or not provided by the requestor)?
• rlink's href attribute is a URI, and there are many URI schemes.
• One of the schemes is file which casts doubt on the "MUST be resolved by using a HTTP request" imperative.
• A document with a relative reference (one without scheme) would not warrant an "HTTP request". The OSCAL schema does not require a scheme in rlink URIs.
• The http scheme (i.e., http without TLS) is considered poor form.
• Note that there are two schemes: http and https. There is only one http media-type: application/http.
• There are many choices for the media-type attribute. Some might be found to be at odds with the URI scheme.
• "octet"is a more precise term than "byte"
• The attention to "stream" is puzzling when considering OSCAL instance documents.

The subsequent statement

When a base64 is encountered and is to be resolved, it MUST be considered a Byte Stream.

uses the term "Byte Stream" (rather than "byte stream") without adding distinction or clarification.

The subsequent statement

Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in Section 4 RFC 4648

is puzzling.

[aj-stein-nist]

@GaryGapinski, thank you for the feedback. Moreso than questions, what we have understood from your questions here is: there is room for improvement in the profile resolution spec, can you address these things?

Can you tell us if this is urgent and/or you need this clarification to advance work impeded by the ambiguities you cited? Let us know and we may shift this into an issue with work items and prioritize accordingly, thanks!

[GaryGapinski]

This is not urgent (though while it exists, correct interpretation of profile resolution can be harmed). I suspect no one has read these. I think the "byte stream" concept is spurious and can be ignored and be made to disappear. The "Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in Section 4 RFC 4648" should be deleted.

References from one document to another should be defined once for OSCAL (not just in profile resolution).

[aj-stein-nist]

This is not urgent (though while it exists, correct interpretation of profile resolution can be harmed). I suspect no one has read these. I think the "byte stream" concept is spurious and can be ignored and be made to disappear. The "Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in Section 4 RFC 4648" should be deleted.

OK, thanks for your reply. We just wanted to check as we work on prioritizing on the questions here after we convert it into an issue. We will not define it as urgent, but still important and worth doing.

References from one document to another should be defined once for OSCAL (not just in profile resolution).

Thanks for the feedback, there will be a consideration of this item in future work. :-)