[httpapi] Structured Fields for HTTP APIs

[Darrel Miller <[e-mail]>]

A recent issue in the rfc7807bis GitHub https://github.com/ietf-wg-httpapi/rfc7807bis/issues/67 has brought us back to a conversation about the use of Structured Fields.

It appears that the differing opinions on how we incorporate SF into new specifications is causing delays on nearly every document in this working group.  It might be helpful if we can isolate this issue and get clarity on it so we don't have to continually relitigate.

I will try and summarize the two camps as:

Camp A: SF are cool, but the world isn't quite ready for them, so where there is minimal impact, let's start using them, but not necessarily everywhere.
Camp B: SF are our best way out of having bespoke parsers for every header, the sooner we suck it up and use them for everything, the quicker we will be out of the pain.

Erik's quote from the above thread does a good job getting to the heart of the Camp A viewpoint:

"it's a good idea, but we also have to get used to the idea that there's tooling out there that for the next few years (at the very least) won't be able to cope with it. reality is annoyingly complex if we step away from the views of large players."

However, Mark has made the point in the past that there are a decent set of implementations for SF, so the friction to adopting new SF headers should be low.  Despite this, the issue of existing players not being able to handle the parsing of SF headers keeps coming up.  It would be helpful to understand what the challenges are for these players.

What I see most commonly in HTTP tooling is HTTP headers being treated as a key/value map of strings.  Where specific headers need to be evaluated, corresponding parsers are used extract semantic meaning.  The fact that implementations treat headers as simple strings until a decision is made to parse a specific header suggests that no implementation is going to break because it encounters a SF formatted header.

This leaves us with the case where deployed infrastructure wants to parse a new header that is formatted with SF syntax, but it doesn't yet have SF support.  My question is this: Why is it harder for existing infrastructure without native SF support, to parse a new SF header than it is to parse a custom ABNF defined header?  If headers with unknown syntax are a problem for existing tooling, how has that tooling survived the introduction of any new header over the past decade?  Is there something about SF headers that make them particularly difficult to parse without pulling in a library dependency?

The two contentious issues we have seen so far are:

  1.  Representing non-ascii characters.
  2.  Date values

As I understand it, the SF position is that we are going to ask developers to use a library, so let's use a format that is easy for machines.  e.g. bytesequence for non-ascii and Unix time stamp for dates.  In the HTTP API world there is proven value in human consumable message content, so this decision feels uncomfortable for us.

Are there other data elements in SF that have been contentious that I have missed?
Do most programing languages have primatives for dealing with these raw values?  Or are we going to see a rash of badly implemented bytesequence generators/parsers?

Getting consensus on this would definitely unblock us on a variety of issues.  Please share your thoughts.

Darrel