Re: Structured Headers: URI type (#782)

[Julian Reschke <[e-mail]>]

On 13.06.2019 11:09, Mark Nottingham wrote:
>
>
>> On 13 Jun 2019, at 7:06 pm, Julian Reschke <[e-mail]> 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