Re: Editorial styling inconsistencies when referring to Structured Fields

Hey

On Thu, 17 Feb 2022, 22:16 Roberto Polli, <robipolli@gmail.com> wrote:

> 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.
>

Right. I omitted them becauase I was being lazy but it would be simple
enough to say "Members are SF Token where the value is a name from the HTTP
Content Coding Registry, or "identity", or "*"."

Having a common way to express constraints can make the work of an
implementer, who has to translate the spec into code, a bit more rigmarole.
In this case, boring is good. In my experience, having ABNF wouldn't help
me much because I consume it all as text anyway. I wouldn't do a hard sell
on my suggestions of terminology, I'm sure the other HTTP and RFC gurus
that have a better suggestion.

Cheers
Lucas