Re: Structured Headers: URI type (#782)

[Mark Nottingham <[e-mail]>]

> On 13 Jun 2019, at 7:16 pm, Julian Reschke <[e-mail]> wrote:
> 
> 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).

If it's not well-defined, and likely to cause interop problems (as is the case now), yes. 

If we figure out a good way to do it, why would there be?

> 
>>> 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?

SH has defined, draconian error handling; Link has none, so we'd have to see what deployed parsers do.



--
Mark Nottingham   https://www.mnot.net/