- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 24 Jan 2023 17:36:17 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, ietf-http-wg@w3.org
> On 24 Jan 2023, at 4:52 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 24.01.2023 01:01, Mark Nottingham 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? > > The problem is that a generic library will not lookup the header definition. That’s immaterial; it’s the *use* of the library that’s important. > IMHO an important point of SF is that we can throw fields at the parser > without *any* out of band information. That’s not true; you’ve always needed field specific information (the top level type). This was discussed at length and widely known, so the assertion is a bit surprising. > As we can see, this only works > great until we extend the format. > > Best regards, Julian
Received on Tuesday, 24 January 2023 06:36:43 UTC