Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 23.01.2023 16:23, Lucas Pardue wrote:
> Hey,
>
> On Mon, Jan 23, 2023 at 10:05 AM Julian Reschke <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 23.01.2023 07:56, Mark Nottingham wrote:
>      >
>      >
>      >> On 19 Dec 2022, at 9:28 pm, Julian Reschke
>     <[e-mail] <mailto:[e-mail]>> 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.
>
> Cheers,
> Lucas
>
> [1] -
> https://github.com/undef1nd/sfv/blob/master/src/test_parser.rs#L324
> <https://github.com/undef1nd/sfv/blob/master/src/test_parser.rs#L324>

Bare items are simple; there's no optionality involved.

What about a dictionary, where you're only looking for "x" (expected to
be an integer), but the sender adds an extension parameter "y" as sf-date?

A conforming parser (of the current spec) will reject the whole field
value, and the recipient will not be able to see the value for "x".

Best regards, Julian