<div dir="ltr">Well, there are representatives from all major UA makers. So while I don't expect them to deviate from their business objectives for us, if we have any specific grievances for them, we certainly can.<div><br></div><div>Regarding JSON headers: what I like about it is that while everything you say is true, more or less can be said about the current state of affairs which is more or less free-for-all. At least with json we would have an uniform machine-parseable format.</div><div>It could however very well be that our feedback be that it is not ambitious enough and we would prefer e.g. ASN1+ some schema</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 11:01 AM, Marcus Kool <span dir="ltr"><<a href="mailto:marcus.kool@urlfilterdb.com" target="_blank">marcus.kool@urlfilterdb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 07/12/2016 06:53 AM, Henrik Nordström wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tis 2016-07-12 klockan 18:34 +1200 skrev Amos Jeffries:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm much more in favour of binary formats. The HTTP/2 HPACK design<br>
lends<br>
itself very easily to binary header values (ie sending integers as<br>
interger encoded value). Following PHK's lead on those.<br>
</blockquote>
<br>
json is very ambiguous with no defined schema or type restrictions.<br>
It's up to the receiver to guess type information from format while<br>
parsing, which in itself is a mess from security point of view.<br>
<br>
The beauty of json is that it is trivially extensible with new data,<br>
and have all basic data constructs you need for arbitrary data. (name<br>
tagged, strings, integers, floats, booleans, arrays, dictionaries and<br>
maybe something more). But for the same reason it's also unsuitable for<br>
HTTP header information which should be consise, terse and un-ambiguous<br>
with little room for syntax errors.<br>
<br>
Regards<br>
Henrik<br>
</blockquote>
<br></span>
Extensible json headers seems to lend itself to put a lot of application-specific<br>
stuff in headers instead of in payload. The headers should be used for the<br>
protocol only.<br>
<br>
Squid has had many issues in the past with non-conformity to standards.<br>
The Squid developers obviously want to stick with the standards and are<br>
forced by non-conformant apps and servers to support non-conformity.<br>
Can this workshop be used to address this?<span class="HOEnZb"><font color="#888888"><br>
<br>
Marcus</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">    Francesco</div>
</div>