Re: Revising Structured Fields: scope

[Willy Tarreau <[e-mail]>]

On Thu, Oct 13, 2022 at 09:56:37AM +1100, Mark Nottingham wrote:
> Discussion so far seems to indicate folks have a preference for defining a new Date type in a revision of the Structured Fields specification, rather than in a separate document or as part of the Retrofit draft.
> 
> If we're going to 'open up' the Structured Fields specification, we should have a defined scope of work, to help assure we don't unintentionally take on a bigger task than we're willing to. 
> 
> I'm proposing that the scope be limited to:
> 
> - Adding a Date type (using the current text in the Retrofit draft[1] as a starting point)
> - Removing ABNF from the specification (as discussed, it's confusing and current editorial style is NOT to use it[2])
> - Addressing technical issues that are or could qualify as errata (e.g., minor algorithm clarifications)
> - Minor and purely editorial work (e.g., improving wording, explanations, correcting typos if found)
> 
> If we limit it in this way, I'm reasonably confident we can ship the spec to the IESG in a reasonable timeframe -- conceivably before the end of the year.
> 
> Thoughts?

I think that this is reasonable, however, and unless I'm missing something,
it seems to me that it's still not possible to encode an empty value, and
for me this remains a showstopper for generalizing adoption as we do know
that a few header fields have a different semantic between empty and absent
(Accept, Host, HTTP2-Settings and probably a few other ones). I would really
like it if we would remove that limitation so that we could hope to more
easily retrofit other fields there, and it doesn't seem like too complicated
change to me to simply add "sf-empty" to the bare-item definition, which
would likely solve this.

Regards,
Willy