- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 13 Jun 2019 19:09:25 +1000
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: Tommy Pauly <tpauly@apple.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
> On 13 Jun 2019, at 7:06 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 13.06.2019 10:46, Mark Nottingham wrote: >> Again, I hope we're not voting. > > No, we are not. > >> My argument: given that the whole point of SH is to have strongly interoperable, crisply defined data models, and that anything beyond "it's a string" is a minefield regarding URIs, the prudent thing to do here is to punt on this until we're more confident. It's entirely possible to do this in a future revision / extension, and we really need to ship this spec. > > I'm not convinced that adding things later will work well. Can you explain why? > I also note > that if we really need to ship this spec, we should try harder to finish > it (this thread started four weeks ago). I've been ready to close these issues for all of that time. > Finally, I still think that allowing to map complex fields like "Link" > to this syntax would be good in that it would encourage people to (a) > include the generic SH parser and (b) actually use if for "Link". That could be said for many headers, it's not clear why Link is special here (and it's the only existing header that would *potentially* be compatible with this; it's not at all clear that the error handling around Link would allow its use). -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 13 June 2019 09:09:57 UTC