W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2019

Re: Structured Headers: URI type (#782)

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>
Message-ID: <f8069ff4-2d32-79ce-534b-c39ad19a50fe@gmx.de>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC