Relationship to other HTTP Header encoding proposals

[pes10k]

This issue is a result of the PING review requested here: w3cping/privacy-request#94

This is not a privacy-sensitive issue, but a question (and request) that came up during the review. It would be helpful and clarifying for the reader to understand the relationship between this proposal and other recent proposals for encoding similar information in HTTP headers (most relevantly, structured HTTP headers).

Does the use case / proposal intend to introduce another format for encoding keys and values in HTTP headers? If not, the could the spec just reference the format its adopting (and inlining)? If so, it would be helpful to the reader to understand why another format is needed, even if as a non-normative note.

[yurishkuro]

fwiw rfc8941 "structured headers" came up many time, and iirc the primary reason we went with an explicit definition of encoding is to make it simpler. rfc8941 spec is way more complex than the use cases needed for baggage. If we were to adopt rfc8941 as the format for baggage it would require substantially more complexity in the baggage implementations, with little to no benefits to the use case.

[martinthomson]

I don't think that this is a good argument in favour of a novel specification. Novel encodings are always more complex than one that can reuse existing, well-defined, well-tested software. So this amounts to NIH.

[yurishkuro]

When one has a hammer, everything looks like a nail. Baggage's format/spec is 10% the complexity of rfc8941 format/spec. Delimited k=v list is hardly a novel format (e.g. cookies, even HTTP headers themselves when merged).

[pes10k]

FWIW, i agree with @martinthomson, that having an indepedent definition of doing a very similar thing is net-complexity-increasing for the platform, and so would be good to avoid if possible.

@yurishkuro have ya'll considered defining the functionality your spec needs as a subset of structured HTTP headers (or similar)? Then an implementation could pull from existing code w/o needing to start from scratch, and we'd avoid another one-off standard encoding things in the platform

[basti1302]

My 2 cents:

I agree with Yury that using structured headers instead of the current format would in fact make the specification more complicated, not easier to use. The closest to the current format are dictionaries, but they allow a couple of features that baggage does not use (boolean members without values, inner lists, etc.) I would be possible to restrict the allowed types of dictionary members, but what is the benefit of such an indirect specification.

Then an implementation could pull from existing code w/o needing to start from scratch, and we'd avoid another one-off standard encoding things in the platform

This assumes that the service that wants to use baggage has a full fledged module for parsing structured headers, which might not be the case.

[kalyanaj]

Thanks @pes10k for filing this feedback and thanks all for the great discussion above. We also discussed this in the working group. Based on the above discussion and the discussion within the working group, I have created a PR (linked above) for adding a non-normative note to explain the rationale behind our approach. Can you please review it and let me know if that addresses this issue? Thanks for your time!

[pes10k]

Hi @kalyanaj , thank you for the discussion and PR. Like mentioned above, i think this direction is not ideal or best for the Web platform, but its also not a privacy concern, so im happy to let the issue go.

[kalyanaj]

Thanks @pes10k.