Re: Call for Adoption: Structured Fields Revision (RFC8941bis)

[Tommy Pauly <[e-mail]>]

My individual preference (not as chair) would be to keep the relaxations in retrofit. My impression is that implementations would have specific workaround rules to say “for this retrofitted field, relax this rule in parsing”. As such, these relaxations make sense only in the context of implementing retrofitted fields; if you’re just coming to structured fields for the purposes of implementing or specifying new fields, you won’t need to worry about the relaxed versions.

I could see the main structured fields document mentioning that some of the rules may be relaxed for parsing legacy fields, but leave the details to the actual retrofit document.

Best,
Tommy

> On Oct 19, 2022, at 5:26 PM, Martin Thomson <[e-mail]> wrote:
> 
> On Thu, Oct 20, 2022, at 11:17, Mark Nottingham wrote:
>>> On 20 Oct 2022, at 10:57 am, Mark Nottingham <[e-mail]> wrote:
>>> 
>>> One thing, just to make sure folks are aware: Retrofit currently defines a few places where SF parsing algorithms are relaxed, to make parsing more successful. See:
>>> https://github.com/httpwg/http-extensions/issues/2235
>>> 
>>> Conceivably, we could move these relaxations into retrofit and put them behind a flag or mode, so that they're integrated into the algorithms, rather than monkey-patching them. We'd need to do it in a way that doesn't affect "normal" SF parsing, though.
>>> 
>>> Thoughts?
>> 
>> I should have been more explicit: what do people think about expanding 
>> the scope of changes we'd consider to include this? I'm fine either 
>> way, just wanted to make sure folks were aware of the issue.
> 
> I'm in two minds on this one myself, though leaning toward the increased scope...
> 
> For:
> 
> These changes would make it so that many more fields could be interpreted as valid structured fields.  If we think that it would be better for retrofit - and the protocol overall - to be a tiny bit more permissive in processing of structured fields, then that work really should happen in the SF spec.
> 
> Against:
> 
> This increases the scope considerably and the likely timelines with it.  There is also a potential view that says that we shouldn't add this sort of permissiveness to SF.  We also have to consider the effect on deployed implementations of SF and what effect this might have on those.  Presumably we would be making parsing more permissive, but construction no less strict, which would help deployment, but we'd have to work through that process.
> 
> I'm definitely interested in hearing other opinions on this one.