Re: Editorial styling inconsistencies when referring to Structured Fields

Hey,

On Thu, Feb 17, 2022 at 2:28 PM Roberto Polli <robipolli@gmail.com> wrote:

> Hi Mark & al.
>
> Il giorno mer 16 feb 2022 alle ore 23:49 Mark Nottingham
> <mnot@mnot.net> ha scritto:
> > Yeah, that seems like a good idea. I've opened:
> >   https://github.com/httpwg/http-extensions/issues/1974
>
> SF achieves the goal of associating types to each field part, but it relies
> on prose - which is subject to interpretation - to describe relations
> between all those parts.
>
> ABNF is limited to syntax, but it's formal and can be used to
> label single field parts and compose them... maybe we should identify
> some conventions to express those relations with SF too.
>

SF makes it possible to avoid needing to do that, which I see as a positive
outcome a lot of the time. Rather than needing to invent custom terms for a
custom header's list members, I just point at SF List member. However, it's
not always simple


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

This seems concise and self contained. The one downside is where there is
commonality between fields, such as `content-coding` or `qvalue` (that we
discussed in relation to digest). Here what you might want to do is invent
a Structured Fields typedef that can act as syntactic sugar. In other words:

""SF Content Coding" is an SF Token when the value is a name from the HTTP
Content Coding Registry"
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.
>