make it possible to drop pre-RFC2231 variants in C-T and C-D

[pali]

just my 2c:

• "strict mode" is in other modules used for parsing, not for generating output... so it may be confusing
• "strict mode" is in other modules used for distinguish between "strict" and "loose" mode, where "loose" means RFC-incompatible; but in this module/pullreuqest "strict mode" just controls generation of both foo*0=x and foo=x which is (IIRC) valid according to RFC; this is basically "compatibility mode" for older applications which do not support foo* syntax.

[rjbs]

Yeah, I'm not crazy about the name, I just stuck it on there so I could write the code for downstream testing.

I think your second point is a misreading, but doesn't affect the fact that "strict" isn't a great name. This change doesn't affect the generation of foo*0=x, only foo=x. It ensure that there's only one form. While a quick look at the RFC didn't show me that you can't have both, we're seeing problems with both where 2231-form would work.

[pali]

This change doesn't affect the generation of foo*0=x, only foo=x. It ensure that there's only one form.

I understand it in this way. Just wrote my previous comment slightly misleading.

Anyway, module already has our $STRICT_PARAMS variable, so new our $STRICT could be confusing. But I really do not know better name. Or maybe reusing $STRICT_PARAMS? No idea what is better.

we're seeing problems with both where 2231-form would work.

Yea, I was expecting that this could be an issue, but during my testing years ago I did not hit this issue. For sure it really makes sense to have an option for generating only foo*0=x form.

[rjbs]

@marcbradshaw Behold, the renamed version, which I think is good to go!

[rjbs]

This was actually merged and released, just not via these exact commits.