- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 13 Jun 2019 18:43:15 +1000
- To: Tommy Pauly <tpauly@apple.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
Hello all, > On 15 May 2019, at 3:46 am, Tommy Pauly <tpauly@apple.com> wrote: > > 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. I'm not sure the results here are helping, and I'd hate for people to think that we're *voting* :) After thinking about this a bit more, I think this issue is backwards; it's asking why we don't support a specific syntax, rather than a specific data model. If people just want to make sure we can express an empty list in SH, that's pretty easy; we can say that the absence of a list-based SH field is equivalent to an empty list. However, if people want to map a *specific* syntax to an empty list (namely, a header field name with an empty or whitespace-only value), I'd like to understand why. There's only been one example given, and there isn't any deployment of the specified semantics AFAIK -- reinforcing the notion that doing so is bad practice. And, as a reminder (sorry for sounding like a broken record), the whole point of SH is that we're not mapping every conceivable field value into the data model; just the conventions that are useful (in other words, paving the cowpaths). Which bucket are the people who are clamouring for this in? Cheers, > > Best, > Tommy (chair hat on) > >> On May 1, 2019, at 10:15 PM, Mark Nottingham <mnot@mnot.net> 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/ >> >> > > -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 13 June 2019 08:43:46 UTC