Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis

[Mark Nottingham <[e-mail]>]

PHK,

> On 26 May 2023, at 4:50 pm, Poul-Henning Kamp <[e-mail]> wrote:
> 
> --------
> Mark Nottingham writes:
> 
>> PHK, you could make this argument for *any* of the types already in SF
>> -- we don't need Integers when you can just stuff them in binary, after
>> all.
> 
> Mark, that is a disingenious argument, and you know it better than any.

That's a strong claim about my intent, and I don't appreciate it. Please back it up or retract it.

> I designed SF, and later you helped,

... and that's quite a distortion of the spec's history, but let's not get distracted from the point here.

> make SF the largest possible
> union of current HTTP header definitions, while still trying to
> impose some kind of order.
> 
> I did not encounter a single RFC which defined a field where integers
> were transmitted as anything but a sequence of ASCII digits.
> 
> The information in HTTP fields is almost exclusively for machine-machine
> communication, and SF is an attempt to make that safer, saner and
> more resource efficient.
> 
> There are a few occational "Show this to the human" bits of information
> at the HTTP field level, and there, and /only/ there, it makes
> sense to allow UniCode.

Yes, that's what we're designing for.

> But those fields have no semantic meaning at the HTTP level, they
> are not interpreted at the HTTP level, and therefore they should
> be transferred as opaque data, and the validation of them left to
> the upper layers of application software.

I interpret what you call "at the HTTP level" to mean use by generic HTTP software such as caches, gateways, proxies, etc., as well as perhaps the generic machinery at the endpoints that need to utilise it.

There has never been a requirement for Structured Fields types (or the entirety of Structured Fields) to be only useful "at the HTTP level." The benefits that we've stated (reuse of parsing/serialisation code, ease of specification, avoidance of errors / mismatches in implementation, potential efficiency benefits down the road with different serialisations, etc.) are certainly seen by them, but are not exclusive to them. Furthermore, making the data model appealing to developers matters, because it reduces barriers to adoption. It also gives us surface area for potential future improvements (e.g., in alternative serialisation) if we know more about the data being transferred.

If that isn't what you meant, could you please clarify?

Cheers,

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