Subject: Re: [httpwg/http-extensions] Strings, Identifiers and Items (#505)

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Mar 2018 23:47:45 +0000 (UTC)

I'm not sure I understand the problem ?

You need to know the specification for the header to produce it correctly, and that will tell you if you are supposed to produce an identifier or a string ?

-- 
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/505#issuecomment-370608863

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Mar 2018 16:01:29 -0800

Imagine that you're creating a generic API for serialising structured headers, say from JS or Python.

We've accepted that it's necessary for the calling code to identify the top-level type, so the function might be `generateStructuredItem(data)` or similar. 

However, what you pass in `data` is ambiguous if it contains a string; is that to be serialised as an identifier, or a string?

One way to fix this would be to pass along extra metadata inside / alongside `data`. However, if we can omit Identifiers from Item, I *think* it becomes unambiguous.

-- 
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/505#issuecomment-370611697

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 13 Mar 2018 02:42:01 +0000 (UTC)

So...

A list-of-identifiers (e.g. `Vary`) becomes a param-list (with the "no parameters" profile)?

A single identifier (e.g. `Content-Encoding`) becomes param-list (with the "only one item", and "no parameters" profiles)??

Amusingly, the one example in the draft for *list* is a list of identifiers, which suggests that that's the most useful type of list.  Which in turn suggests making a new first class "list-of-identifiers" type.

The set of types starts to look a bit .. um.. :

* list of {identifier => identifier} pairs
* list of {identifier => other primitive scalar} pairs
* parameterised list of identifiers *
* list of identifiers
* list of other primitive scalars
* identifier
* other primitive scalar

\* this is actually more complicated, because of `foo;bar=baz` vs `foo;bar="baz"`

I can kind of see how we're getting here, but it seems like maybe you've opened up a tiny little crack which might make the whole thing fall apart.

-- 
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/505#issuecomment-372527752

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 13 Mar 2018 02:58:56 +0000 (UTC)

> While most languages can distinguish floats from integers, as well as **binary content from other content** ...

Wait, can they?  How would my API to know whether to generate `"hello"` or `*aGVsbG8=*`?  What you say only works if those two values are completely interchangeable, which means they're the same data type.  But that's not stated (or even implied) in the current text.

In Ruby there are String and Symbol objects, which means it's actually *easier* for my Ruby API to choose between strings vs identifiers than strings vs binary content.

Maybe the extra metadata is the way to go.  We already have those in every other serialisation library in existence (e.g. [PHP json_decode's `assoc` parameter](https://secure.php.net/manual/en/function.json-decode.php), [Ruby's JSON opts](https://ruby-doc.org/stdlib-2.5.0/libdoc/json/rdoc/JSON.html#method-i-parse), etc.) so it's not something completely foreign to developers.

-- 
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/505#issuecomment-372530530

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 11:53:42 +0000 (UTC)

Hm. In Python3, I have `b"..."` for binary. Ruby has stringio objects. JS has Blob. I *think* binary is pretty well-covered and natural in most languages (even if it requires a wrapper object, that is "the" way it's done in that language).

It's much less clear to me that there's always such a natural mapping for identifiers. It's true that a library could define a wrapper object for them; I just wonder if it would end up being confusing to use (because it's not the natural convention for that language).

E.g., in Python, I don't think there's a natural mapping, so my library would have to define an Identifier object that would need to be consistently used in all data to/from headers. That object would become a dependency for all code that works with that header.

Not sure that's a big deal, just working through it.

-- 
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/505#issuecomment-372995265

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 14:40:05 +0000 (UTC)

Oh, I didn't know Python 3 had separated serialisation from strings and exposed 'bytes' as its own type. 
 That's cool.  In Ruby a String is always a String, even if you access it using StringIO\*;  and a string with `.encoding == Encoding::ASCII_8BIT` isn't special in any way.

But yeah, my big hangup is that `param_id` has `[ "=" item ]` in its definition.  That's the one place, in all the potential header definitions, where I can see a strong argument for allowing mixed strings and identifiers in the same context.  Which means even if you were to carve *identifier* out of *item*, you'd probably have to expand the param_id rule to bring it back in there, which means a generic encoder would still need that extra metadata to know whether to write `="foo"` or `=foo`

(\* *but you can use `bytes`/`each_byte` or `unpack` to get the octet values out*)

-- 
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/505#issuecomment-373044792

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 14:44:18 +0000 (UTC)

Right. In a perfect world, we could map native datatypes 1:1 with header datatypes, but as a stopgap, we can use objects (whether they're provided by the language like `StringIO` or by the header mapping itself). I still think it would be cool if we could minimise that.

So I think the heart of this question is: does the usefulness of using Identifiers in places like parameter and dictionary values outweigh the inconvenience/extra abstraction of using wrapper objects/types?

-- 
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/505#issuecomment-373046363

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 15:09:03 +0000 (UTC)

> So I think the heart of this question is: does the usefulness of using Identifiers in places like parameter and dictionary values outweigh the inconvenience/extra abstraction of using wrapper objec…

How much would it matter if we couldn't reproduce `content-type: text/html;charset=utf-8`?

-- 
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/505#issuecomment-373055681

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 08:10:41 -0700

Yes. If we don't allow identifiers in types, it'd have to be serialised as:

> Content-Type: text/html;charset="utf-8"

... if it was a parameterised list.

-- 
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/505#issuecomment-373056288

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 14 Mar 2018 22:28:35 +0000 (UTC)

Aye, so, given that content-type is never ever going to have a different serialisation, if the eventual goal of this structure isn't to conquer the world (of existing headers) then there's no problem.

Also, it fits nicely with some of my more radical ideology to never use an identifier on the right of an equals sign.

-- 
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/505#issuecomment-373196205

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 06:15:25 +0000 (UTC)

I think I'm going to try to take identifiers out of the next draft and see how that goes. We can always re-add them.

-- 
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/505#issuecomment-376773931

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Mar 2018 23:18:37 -0700

Closed #505 via e01e01e151216234a21d1767ceabf989df7e7d25.

-- 
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/505#event-1544819126