RE: Message signatures, structured fields and ABNF

The abnf has its places and uses. The part of signatures that you linked is keeping the abnf because it's putting serialization constraints on the strings being created, not using the data structures alone. Elsewhere in the document we've pulled out the abnf in favor of plain prose and using the terms in the latest published draft.

-Justin

________________________________________
From: Mark Nottingham [mnot@mnot.net]
Sent: Thursday, May 26, 2022 8:46 PM
To: Roberto Polli
Cc: HTTP Working Group
Subject: Re: Message signatures, structured fields and ABNF

Hi Roberto,

> On 27 May 2022, at 9:13 am, Roberto Polli <robipolli@gmail.com> wrote:
>
> Dear all,
>
> after reading the HTTP Style guide
> https://httpwg.org/admin/editors/style-guide#self-references
> I was trying to refactor RateLimit
> https://github.com/ietf-wg-httpapi/ratelimit-headers/blob/main/draft-ietf-httpapi-ratelimit-headers.md
> to remove ABNF and I am finding the document less readable than before.
>
> Looking at https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-message-signatures.md#creating-the-signature-base-create-sig-input
> I think that removing ABNF from there is even more complicated.
>
> Which is a suitable replacement for ABNF to be used in cases such as
> Message Signatures?
> While Structured Fields is capable of disassembling the structure of  a field,
> it can't formally describe the specific content/format of a string.

The point of Structured Fields is that they're not strings, conceptually -- they're data structures. Eventually, we might come up with a simple schema language for them, but for now prose should be adequate.

Taking a quick look at the document - personally, I don't think the ABNF adds much, and indeed in some cases makes it more confusing (e.g., saying something is a sf-item doesn't convey anything about the constraints on that item).

Cheers,




--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 29 May 2022 18:17:00 UTC