W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: signatures vs sf-date

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Mon, 23 Jan 2023 15:23:15 +0000
Message-ID: <CALGR9oZMYhB8MXZzJHjb1QM+x7f3w_bENDLDqr39+BR5=t5r3w@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org

On Mon, Jan 23, 2023 at 10:05 AM Julian Reschke <julian.reschke@gmx.de>

> On 23.01.2023 07:56, Mark Nottingham wrote:
> >
> >
> >> On 19 Dec 2022, at 9:28 pm, Julian Reschke <julian.reschke@gmx.de>
> wrote:
> >>
> >> This sort of confirms that we really need to figure out what the
> >> expectations for users of SF (be it implementations or specifications)
> >> are - is support of sf-date an extension you need to opt in somehow?
> >
> > Yes - by emitting or consuming a field that uses it.
> When I invoke an SF parser - how do I signal to the parser that I want
> support for sf-date?

I use the Rust sfv crate, which at the time of writing doesn't support
sf-date. Generally for Item parsing, I pass it a character iterator, and it
returns a Rust enum with associated data that I pattern match on. Some
examples are in the test cases [1]. Say I have a field that is expected to
be a Boolean, I'd call parse_bare_item(<input>) and if the result is not Ok(
BareItem::Boolean(<actual value>)), then something is wrong and there's
various things I could do (log it, ignore it, reject it, etc).

For sf-date support in sfv, I'd expect there to be a new BareItern::Date
enum added to the library. When parsing a field I expect to be a date, I'd
do a similar pattern match in my app. Of course, I'd need to update my apps
dependency to a library version that provided that enum otherwise my
application wouldn't compile.

Should an update to the library include sf-date by default? I'm not sure.
If I no longer get an error when I was expecting it, that might affect
program flow. Its probably easier to reason about in Rust due to compiler
checks. Since this is an additional type, I guess support could be stuck
behind a feature flag, so that the old behaviour could be preserved if it
was really necessary. The flag could be default on, or default off.


[1] - https://github.com/undef1nd/sfv/blob/master/src/test_parser.rs#L324
Received on Monday, 23 January 2023 15:23:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC