- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 13 Jun 2019 11:03:20 +0200
- To: Mark Nottingham <mnot@mnot.net>, Tommy Pauly <tpauly@apple.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
On 13.06.2019 10:43, Mark Nottingham wrote: > ... > 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. That would mean that there is no distinction between an absent value (header field not present at all) and an empty list (header field present but empty). I don't claim that it's a good idea to tie any semantics to this, but on the other hand not allowing an empty field value seems to make things more complicated than needed. > 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? In between, I'd say :-) Best regards, Julian
Received on Thursday, 13 June 2019 09:03:50 UTC