- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Wed, 13 Jun 2018 09:52:45 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 06/13/2018 05:04 AM, Julian Reschke wrote: > On 2018-06-13 12:16, Mark Nottingham wrote: >>> On 13 Jun 2018, at 8:12 pm, Julian Reschke <julian.reschke@gmx.de> >>> I would say that the incentives are exactly the same for the two >>> variants. If the spec makes a mandatory requirement on the recipient >>> that is easy to implement, why would implementations choose to follow >>> it for SH but not for JFV? >> Because the option of deploying a JSON implementation *without* those >> constraints is extremely easy. > I don't buy that argument. That argument is valid IMO. If I am writing a simple piece of code that needs to deal with a structured header, I am going to use an existing parsing/packing library. * In JFV case, the probability of choosing a JSON library without restrictions is non-negligible (because there are lots of such libraries, many are popular/built-in, and I may be using one of them already). * The probability of choosing an SH library without restrictions is about zero (because such libraries will not exist). Alex.
Received on Wednesday, 13 June 2018 15:53:10 UTC