- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 13 Jun 2019 11:16:16 +0200
- To: Mark Nottingham <mnot@mnot.net>
- 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.06.2019 11:09, Mark Nottingham wrote: > > >> 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? My impression is that we'd see exactly the same pusback for an extension spec (or a revision). >> 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). Link isn't special; it just happens to be a header field with relatively complex syntax. You mention error handling: do you have something specific in mind? Best regards, Julian
Received on Thursday, 13 June 2019 09:16:48 UTC