Re: Empty lists in Structured Headers (#781)

[Jeffrey Yasskin <[e-mail]>]

I have a conditional vote, and sorry for the complexity.

As a less-experienced person, a large part of the value of SH is that
it points me and my team toward best practices. We can say "X is a
structured header" and then only make the mistakes that are possible
within the guard rails.

If empty headers are something you recommend that new headers treat as
errors, I'd vote for A. If you instead recommend that new headers
allow empty values (and treat them either the same or different from
that header being absent), I'd vote for B. I don't think C is a good
idea, since it removes the advice SH could otherwise provide.

Jeffrey

From: Tommy Pauly <[e-mail]>
Date: Tue, May 14, 2019 at 10:49 AM
To: [e-mail] Group
Cc: Poul-Henning Kamp, Mark Nottingham

> Hello all,
>
> Thanks for the lively discussion we had on this topic! However, it looks like the conversation has petered out. As a working group, we should come to some consensus on the best way forward for this issue.
>
> I'd like to ask everyone to reply with which option they prefer of the of following, so we can get a sense of the group's opinion:
>
> A. Leave the document as is, not defining empty header values for SH (as requested by the editors). As noted on the list, this can allow future revisions to add support.
> B. Define empty header values for SH (as the issue requests).
> C. Do not allow empty header values for SH, but add formal text to the document explaining how to handle empty values.
>
> Please evaluate these based on what you think will help us converge and ship this document, and note that this is deciding how we define formal Structured Headers, not all or previous HTTP headers.
>
> Best,
> Tommy (chair hat on)
>
> > On May 1, 2019, at 10:15 PM, Mark Nottingham <[e-mail]> wrote:
> >
> > (Editor hat on)
> >
> > <https://github.com/httpwg/http-extensions/issues/781>
> >
> > PHK and I have discussed this, and I think we agree that this issue should be closed without any change to the specification.
> >
> > Any further discussion? We'd like to get this spec shipped.
> >
> > Thanks,
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
>