Subject: Re: Structured Headers: URI type (#782)

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Jun 2019 18:46:01 +1000

Again, I hope we're not voting.

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.

Cheers,

> On 15 May 2019, at 3:54 am, Tommy Pauly <[email-masked]> wrote:
> 
> Hello all,
> 
> As with #781 on SH, we've had some discussion back and forth on this one, without clearly concluding the discussion.
> 
> We'd like to get a sense of the group's consensus so we can move forward with the document. Please reply with which option you think will be be best option to be able to ship the document:
> 
> A. Leave the document as-is, without specifying a URI type for SH; note that URI types can be added in a future revision
> B. Specify a URI type for SH as a String
> 
> Thanks,
> Tommy (chair hat on)
> 
>> On May 1, 2019, at 10:15 PM, Mark Nottingham <[email-masked]> wrote:
>> 
>> (Editor hat on)
>> 
>> <https://github.com/httpwg/http-extensions/issues/782>
>> 
>> PHK and I have discussed this, and I think we agree that this issue should be closed without any change to the specification. 
>> 
>> Any further discussion? We'd like to get this spec shipped.
>> 
>> Thanks,
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
> 
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jun 2019 11:06:31 +0200

> 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 thi…

I'm not convinced that adding things later will work well. 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).

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".

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Jun 2019 19:09:25 +1000

> On 13 Jun 2019, at 7:06 pm, Julian Reschke <[email-masked]> wrote:
> 
> I'm not convinced that adding things later will work well.

Can you explain why?

> I also note

I've been ready to close these issues for all of that time.

> 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).

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jun 2019 11:16:16 +0200

>> I'm not convinced that adding things later will work well.

My impression is that we'd see exactly the same pusback for an extension
spec (or a revision).

> 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 erro…

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Jun 2019 19:18:50 +1000

> On 13 Jun 2019, at 7:16 pm, Julian Reschke <[email-masked]> wrote:
> 

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?

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