sfbis: Allow parameters values to also be bare array of Items

[CxRes]

Since I have already started to irk folks on the current sfbis-05 draft, I thought I might as well take the opportunity to do a proper job of it.

I would very much like to see the parameter value not just be restricted to "bare Items", but allow "bare items or bare array of Items". That is, the array is itself not parameterized, just like items, but its contents still would be. This would allow one to indefinitely nest parameters.

I have tried to follow the discussion in the issue tracker (and even commented recently at one place), but with all the historical anachronism being discussed in the threads, I cannot ascertain if this was even considered, or considered and rejected. AFAICT, the fields will still be uniquely parsable by virtue of each =( needing to be closed by a corresponding ).

I have an immediate use case for this in PREP, where I repurpose existing HTTP fields as parameters of the protocol, with the same semantics as the headers, to negotiate the content of notifications. This saves me from having to define new parameters for the protocol or even new fields, leading to a simpler specification.

To illustrate this, consider the following header that would be made possible:

Accept-Events: "prep"; accept=(application/ld+json text/turtle;q=0.9)

In another case (to be released very soon), I need to literally serialize an array:

Accept-Events: "solid"; channel-type="WebSockets2023"; features=(rate endAt)

My reading of the spec tells me that such parameterization is not possible to achieve right now (correct me if I am wrong!). I could hack my way using strings, but apart from being non-standard, that will still limit the nesting.

[mnot]

This would be a breaking change, and so is out of scope for a bis.

[CxRes]

Excuse my ignorance, but I do not understand how this is a breaking change? Even with this feature, all existing fields that parse successfully will continue to parse exactly as before. Only a subset of fields that failed to parse earlier will now also parse successfully. It should not affect anyone who is using RFC8941 any more than, say, display strings!

[mnot]

You're correct - it might conceivably be introduced in a new specification without breaking existing fields. However, I don't believe we should do so now, and I'll try to explain why.

We purposefully kept the bar for adding new features to Structured Fields high, to balance their functionality with simplicity (both for implementation and use). Note that Dates and non-ASCII strings were not even included in the first RFC.

So, to add a feature like this, we'd need to establish agreement that it's a good direction to go in -- that people would actually use it, and it's "worth" the added complexity (keeping in mind that SF purposefully limits nesting of data structures to address that).

Additionally, since we're changing the allowable values in Parameters, we'd need to define how that works in terms of extensibility and evolution, in a manner similar to what we did for Display Strings and Dates. As part of that, we'd likely need to discuss whether the correct approach would be to change the semantics of Parameters, or to add a new data type.

That's all a lot to do when something has already finished IETF Last Call. It's not that specs can't return to the WG if there's good reason, but that reason needs to be pretty significant (e.g., an interoperability or security issue).

Putting all of that aside, consider whether a syntactic change in SF is actually necessary to acheive your goals. For example, this Dictionary would allow the same semantics to be conveyed:

Accept-Events: prep=(application/ld+json text/turtle;q=0.9)

Or, if you needed more flexibility, you could use two fields:

Accept-Events: "prep";attrs=foo
Accept-Attrs: foo=(application/ld+json text/turtle;q=0.9)

[CxRes]

I am happy for this to be considered in the next round of updates. My concern was that the proposal was being dismissed offhand, without a reasonable evaluation, and for the wrong reason. Those concerns you have addressed!

As for your suggestion, I had distilled my requirement down to the simplest example possible. I expect real world examples to be more complex. Consider the header that when using Solid Quick Notifications Protocol (currently a PR) requesting notifications for multiple topics in multiple formats:

Accept-Events: "solid"; type="WebSocketChannel2023"; topic=("https://example.org/guinan/profile" "https://example.org/guinan/webid"); accept=(application/ld+json text/turtle;q=0.9),
  "solid"; type=""EventSourceChannel2023"; topic=("https://example.org/guinan/profile" "https://example.org/guinan/webid"); q=0.75,

or, a request that combines PREP's default rfc822 message with a delta in notifications.

Accept-Events: "prep"; accept=(message/rfc822;delta=(text/n3 application/ld+json;q=0.9));

where, delta is a property associated with the notification content-type message/rfc822. Unfortunately, there is no way around such nesting. In the most general case one must negotiate the content-type of the representation (obviously), the notification message and the delta (of the representation) between triggering events to be included with the next notification.

It is not that there are workarounds to solve this problem (such as, by introducing new headers or specifying custom parsing for inner fields), it is that such workarounds are, let say for sake of politeness, inelegant!

[CxRes]

I tried various hacks to include the information I want in the PREP Accept-Events header in an attempt to conform to the current draft, and just gave up as none of them were satisfactory!

I then patched Evert Pot's rather well written JavaScript implementation of structured fields (npm:structured-headers) to add support for bare array of Items as parameters. And, I was somewhat surprised to see that it passes the current test suite (later realizing that you are not really checking types). I have further added a couple of tests for this nesting case.

Code | Modified Test Suite

[mnot]

Closing as not being addressed in this update.

[CxRes]

Would you please consider reopening this issue now that RFC9651 has been published?