"Structured field value" isn't well defined

[jyasskin]

https://fetch.spec.whatwg.org/#concept-header-list-set-structured-header takes a "structured field value" as an argument, but RFC8941 never defines that term. In particular, it's not clear that the argument needs to specify which of the Structured Data Types is being passed. This will often be guessable from the context, but Integers and Decimals might get mixed up in some cases, as could Strings, Tokens, and Byte Sequences.

[annevk]

It defines it just before the example at the end of https://httpwg.org/specs/rfc8941.html#rfc.section.2.

Perhaps Fetch should have a section though with some kind of mapping between those and Infra types.

@domenic might have some thoughts about this given his work around this in HTML.

[jyasskin]

Ok, there is a definition, but "Specifications ... can refer its field value as a "structured header value", "structured trailer value", or "structured field value" as necessary." doesn't give enough information to know what to pass to "set a structured field value". E.g. is the field value the ascii serialization or the parsed value? If you think hard or read the algorithm, it's clear it has to be the parsed value, with its type, but novice spec authors shouldn't have to (and don't) think hard when they want to call this.

It would help some to infer types from:

Lists

list

Dictionaries

ordered maps

Integers

long long (but the range is less than long long, and folks might pass other integral types)

Decimals

double (but the range is less than double, and floats also work)

Strings

ASCII string

Tokens

ASCII string ??

Byte Sequences

byte sequences

Booleans

boolean

But this leaves out Parameters entirely, and I think it would be better to just be explicit that the argument needs to be in the Structured Data Type system.

[mnot]

Parameters do complicate things. Also, it'd be good to distinguish between Token and String if it's going to be (re-)serialised. And don't forget we're adding Date and perhaps a separate Display String that takes non-ASCII content.

@annevk if you remember we talked about this some at the last HTTP Workshop; the data model we eventually ended up looked something like:

{
  "@type": "string",
  "@val": "foo",
  "a": 1,
  "b": 2
}

... where a and b are Parameters. @type could be optional if the datatype is natively clear (as per many of the examples above).

You could also have convenience methods for various things here, of course, but in this approach you'd have to make sure their names didn't confict with potential parameters. The other way would be to put parameters into a separate namespace; e.g.,

{
  "type": "string",
  "val": "foo",
  "params": {
    "a": 1,
    "b": 2
  }
}

[annevk]

Yeah, though note that this is for the "internal" API between specifications.

[mnot]

Ah.

[mnot]

Note that the revision is adding Dates and Display Strings (i.e., unicode).