Structured Fields: forward compatibility for future field types

Hi folks,

I've been thinking about how SF handles forward compatibility with respect
to field types that haven't been defined yet.

> Both Items and Inner Lists allow parameters as an extensibility
>   mechanism; this means that values can later be extended to
>   accommodate more information, if need be.  To preserve forward
>   compatibility, field specifications are discouraged from defining the
>   presence of an unrecognized parameter as an error condition.

The text clearly expresses the intent to allow extensibility, but only
allows that for field types available when the field specification was
created.

SFbis [1] adds the sf-date type. That means a header containing a sf-date
would fail to parse when using RFC 8941, but would succeed with sfbis. So
if you were to consider adding an optional sf-date parameter to a
structured header, you have to either create a new field that explicitly
requires sf-date support, require that everyone using the field has an SF
implementation that implements sf-date or be okay with with some
implementations failing to parse the header because it contains a sf-date
which they don't understand.

I think the situation is not critical at the moment, but if we add more
header field types in the future and ossification sets in, then it could
become difficult to determine which types are supported by which
implementations and whether that matters.

I don't know if anyone has discussed adding an "unknown" type for
future-proofing reasons.
For example, if we were to define it as "#" *chr "#" any implementation
that understands sf-unknown would successfully parse the field. Future
types would then need to be defined using the same pattern. For example,
sf-date could have been defined as "#" "@" ["-"] 1*15DIGIT "#".
Specifications that define a field as sf-date would still fail if that
field isn't sf-date, but they wouldn't fail just because they were defined
before sf-date.

Is this something worth considering?

[1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/
-- 
Valentin