Re: Editorial styling inconsistencies when referring to Structured Fields

Hi Lucas,


Il gio 17 feb 2022, 16:00 Lucas Pardue <lucaspardue.24.7@gmail.com> ha
scritto:

>
>> An "exercise" in SF could be to express Accept-Encoding
>>
>> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.12.5.3
>> accordingly to https://github.com/httpwg/http-extensions/issues/1974
>> without using abnf:  which would be the result?
>>
>
> Retrofit headers classes these as an SF List [1]. If we wanted to be more
> expansive about a definition, my first suggestion would be
>
> "The Accept-Encoding header field is an SF List. Members are SF Token
> where the value is a name from the HTTP Content Coding Registry. The SF
> Parameter "q" is defined, the value is SF Decimal representing a quality
> weighting."
>
> ... where there is commonality between fields, ... a Structured Fields
> typedef that can act as syntactic sugar.
>

I think that's something useful, and that we should work out.

In other words:
>
> ""SF Content Coding" is an SF Token when the value is a name from the HTTP
> Content Coding Registry"
>

Side note: the prose would be longer, since "identity" and "*" token are
allowed value outside the content coding registry.
With abnf you get it at first sight, and that "first sight" feature is
probably something we should provide with SF even if we want to get rid of
abnf.

My2c,
R

snip
> "The Accept-Encoding header field is an SF List; members are SF Content
> Coding."
> snip
> "The Content-Encoding header field is an SF Item of type SF Content
> Coding."
>
> I'm sure there are many other ways to do this, some more open to
> interpretation than not.
>
> Cheers,
> Lucas
>
> [1]
> https://mnot.github.io/I-D/draft-nottingham-http-structure-retrofit.html#name-compatible-fields
>
>
>>
>> Have a nice day,
>> R.
>>
>