Re: signatures vs sf-date

On 23.01.2023 16:23, Lucas Pardue wrote:
> Hey,
>
> On Mon, Jan 23, 2023 at 10:05 AM Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>     On 23.01.2023 07:56, Mark Nottingham wrote:
>      >
>      >
>      >> On 19 Dec 2022, at 9:28 pm, Julian Reschke
>     <julian.reschke@gmx.de <mailto: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.
>
> 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

Received on Monday, 23 January 2023 16:09:52 UTC