Re: Abbreviation form for HTTP JSON Header Field Values?

Hi Kazuho,

sorry for not making any progress on this for so long.

I'm still not convinced that your proposal is the right way to do this. 
My main concern being that the code that does the conversion needs to 
understand the JSON data model for the particular header field.

In 
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-jfv-01.html#example.accept-encoding>, 
I added my own take about how a JSON variant of Accept-Encoding could be 
simplified (accept-encoding was one of your examples):


> 6.4.  Accept-Encoding
>
>    The Accept-Encoding header field value is defined in Section 5.3.4 of
>    [RFC7231] as a list of codings, each of which allowing a weight
>    parameter 'q':
>
>       Accept-Encoding = #( codings [ weight ] )
>       codings         = content-coding / "identity" / "*"
>       weight          = OWS ";" OWS "q=" qvalue
>       qvalue          = ( "0" [ "." 0*3DIGIT ] )
>                       / ( "1" [ "." 0*3("0") ] )
>
>    An example for a complex header field value given in the definition
>    of the header field is:
>
>      gzip;q=1.0, identity; q=0.5, *;q=0
>
>    Due to the defaulting rules for the quality value ([RFC7231], Section
>    5.3.1), this could also be written as:
>
>      gzip, identity; q=0.5, *; q=0
>
>    A JSON representation could be:
>
>      [
>        {
>          "gzip" : {
>          }
>        },
>        {
>          "identity" : {
>            "q": 0.5
>          }
>        },
>        {
>          "*" : {
>            "q": 0
>          }
>        }
>      ]
>
>    ...which would translate to a header field value of:
>
>      {"gzip": {}}, {"identity": {"q": 0.5}}, {"*": {"q": 0}}
>
>    In this example, the part about "gzip" appears unnecessarily verbose,
>    as the value is just an empty object.  A simpler notation would
>    collapse members like these to string literals:
>
>      "gzip", {"identity": {"q": 0.5}}, {"*": {"q": 0}}
>
>    If this is desirable, the header field definition could allow both
>    string literals and objects, and define that a mere string literal
>    would be mapped to a member whose name is given by the string
>    literal, and the value is an empty object.
>
>    For what it's worth, one of the most common cases for 'Accept-
>    Encoding' would become:
>
>      "gzip", "deflate"
>
>    which would be only a small overhead over the original format.

Please let me know what you think.


Best regards, Julian

Received on Friday, 8 July 2016 17:19:33 UTC