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: Tue, 24 Jan 2023 01:27:06 +0000
Message-ID: <CALGR9obds85hyv-mUbOUqShOesbLWcm=SwT=ax_+hFEXhbDqUg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, ietf-http-wg@w3.org
On Tue, Jan 24, 2023 at 12:01 AM Mark Nottingham <mnot@mnot.net> wrote:

> > On 24 Jan 2023, at 3:09 am, Julian Reschke <julian.reschke@gmx.de>
> wrote:
> >
> > 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".
> If you are parsing a field that uses Date, its specification will refer to
> sf-bis, not RFC8941. Therefore, you will need to use an implementation that
> claims conformance to sf-bis. What's the problem?
I think the problem is that you can't extend any existing field to use a
parameter of Date type. You can't expect the receiver to know about the
extension nor have the parser robustly skip the Data parameter that it
doesn't care about. Constraining the Date type to new fields, or OOB
feature negotiation, seems like a reasonable constraint TBH. Some text to
call out the potential issues might be nice.

Received on Tuesday, 24 January 2023 01:27:30 UTC

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