Subject: Re: [httpwg/http-extensions] Identifying top-level data types (#476)

From: HTTP issue updates <[email-masked]>
Date: Thu, 01 Feb 2018 15:28:50 -0800

Personally, I'm leaning towards (2). Someone using a parser for a given header is going to need more information about its structure and semantics to use it anyway. 

I _think_ the only reason we'd want to do (1) is if we have a strong use case for being able to parse the header without any such context. I suppose one could write a linter or debugger that wants to check structured headers for correctness (e.g., <https://redbot.org/>), but I don't know that it's worth the discontinuity with "traditional" HTTP header syntax (which so far we've largely maintained).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-362436557

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 04 Feb 2018 02:45:54 +0000 (UTC)

I wrote a very quick Ruby script the other day to try out the algorithms, and I went with the extra top-level metadata. For a header value to get fed into this parser, either: something already knows it's a common structure header value, so there's no reason it wouldn't know _which_ structure; or: it's throwing things at the wall to see what sticks, in which case it can already deal with backtracking/trying other types/etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-362875813

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 04 Feb 2018 11:40:41 +0000 (UTC)

Incidentally:

> Items' types can be identified by inspecting their first character

A bare lowercase word is either a parameterised label or an item (label), so it's not just list/dict.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-362900455

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 17 Feb 2018 12:38:00 -0800

One argument against 2 is that it robs future HPACK-oids of a clue to what they're being asked to compress.

One argument against 1 is that not having a type-marker reduces the chance of somebody defining a header as "Either a list or a dict".

I don't think I could personally make the call without a coin.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-366469659

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 17 Feb 2018 21:08:58 +0000 (UTC)

Another argument against 1:

Yes, "items" can be spotted by looking at the first char.

But you cannot tell integer from float until you run into a '.' or something else later.

Similarly label/plabel cannot be told apart until you run into a ';' or something else later.

So the real question seems to me to be if we want to be able to tell all the types apart from the first char ?

Given how simple our parsing rules are, I tend to say no, and thus no prefix-char on list/dict.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-366471535

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 18 Feb 2018 22:42:24 +0000 (UTC)

@bsdphk I don't understand the argument against 1; how does that prevent someone from saying "list or dict"? (not that I think that's going to be common, or even desirable).

As @phluid61 mentioned elsewhere, label/plabel is the "special" one, and something we need to fix. Otherwise, it's not *necessarily* the first character, but it does need to be deterministic (e.g., you can't reliably identify a structure if doing so relies on an optional part of the structure, which is currently the case with plabel).

Same with list/dict; e.g., currently, I can't examine a header without external information and tell whether something is an item or a single-member list. 

That matters if the consumer is expecting a particular structure.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-366554821

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 19 Feb 2018 09:38:41 +0000 (UTC)

"list or dict":  If your parser insist you tell you which up front, 'or' is not possible. (Well, retries etc, but)

And yes, a parser can tell if it is a dict or list as is, just not from the first non-OWS char, but we can't tell integer and float apart either that way, so I don't think that matters.

single-item list vs item:  Keep it simple:  Remove the text about headers being an item and force people to use either dict or list and note explicitly that lists can be restricted to length==1 ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-366635083

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 19 Feb 2018 23:04:04 +0000 (UTC)

That's attractive, but it shifts the burden to those specifying single-item header fields; they now need to say what to do when the field value doesn't have exactly one member, whereas before saying it's an item (of whatever sort) took care of that.

For me, *the* major goal of this spec is to leave as few traps for the unwary as possible.

To be clear, I think that having parsers expose multiple functions is fine, and I don't think we need to prefix lists or dicts; IMO we can close this issue with no action. The real issue to fix that we're bleeding into is #443.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-366823054

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 22 Feb 2018 08:14:43 +0000 (UTC)

WFM

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#issuecomment-367600091

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 22 Feb 2018 08:21:03 +0000 (UTC)

Closed #476.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/476#event-1486397894