Re: Structured Headers: URI type (#782)

[Mark Nottingham <[e-mail]>]

On 2 May 2019, at 3:58 pm, Julian Reschke <[e-mail]> wrote:
> 
> On 02.05.2019 07:45, Mark Nottingham wrote:
>> Could you explain why it's compelling?
>> 
>> It's already possible to map a link header to the existing data structures (there are a couple of ways you'd do it).  It's true that the syntax wouldn't be identical to a Link header, but that hasn't been a goal for other parts of SH; in this sort of situation, we've assumed that some mapping function would be necessary (e.g., negotiating to send the new header as SH-Link, or some other mechanism).
> 
> I understand it was not a goal, but that doesn't mean it wouldn't be
> nice to get to that as closely as possible...

True. It just seems like a poor tradeoff for just one header field.


>> I'd be much more supportive of doing a URI type if we could get agreement for *and* implementation of a common data model for URIs in SH. However, it appears that there's disagreement about that; browser folks want to reuse the WHATWG URI specification (which is sensible, from their viewpoint), whereas others don't like that spec. Exposing it as just a string doesn't seem to add much at all.
> 
> It indeed just adds a new syntax (no processing model is needed, true).
> For URIs, it's kind of nice as it uses a delimiter that can't be used in
> URIs anyway.
> 
>> We could talk about this a lot more, but I suspect it would take at least a few months to conclude the discussion. I'd rather ship the spec; if we can agree on a new type down the road, we can always add it with an update.
> 
> That is true, but then updating both spec and implementations is always
> more work then including things from the start. It's a trade-off.

Of course. To me we're at diminishing returns here, and the friction against adding a new type later is pretty low (based upon the experience of building this set of types so far, in the spec, implementation, and tests).


> From a practical point of view, would you expect the spec to be
> replaced by a new one, or should there be an extension point/hook so a
> delta spec can be written?

I'd think it'd just be a matter of writing a spec that updates this RFC, defining an abstract type along with its textual parsing and serialisation algorithms. The biggest concern would be making sure that the first character of the textual serialisation identified the type (not a hard requirement, but it's the convention we've been using so far, so it'd need to be a good reason to break it, I think). In this case, that's pretty clearly "<".

Cheers,


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