- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Thu, 17 Feb 2022 22:50:20 +0000
- To: Roberto Polli <robipolli@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CALGR9oYf7-T1iGZ-_phq+VYC5MzndW-1mcesBNOT97bhN-iwFA@mail.gmail.com>
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
Received on Thursday, 17 February 2022 22:50:45 UTC