That's very helpful guidance, Alex. Thank you.
It's probably not in scope currently for me to take on championing such an effort, but I'll keep it in mind as an option for the future.
David
On Tue, Jun 13, 2017 at 2:43 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 06/13/2017 02:41 PM, David Kewley wrote:
> I will proceed assuming that squid will never support the sort of
> spoofing I was hoping for (since it would probably simplify things
> greatly for us), even though I believe in our design that spoofing would
> have been safe.
If you have a legitimate use case, Squid may address it. You just need
to convince developers that your use case does not violate basic
internet principles (more than the existing code does) and is generally
useful (i.e., many folks may find the new feature useful).
In such discussions, claims of RFC or BCP violations are often made.
Sometimes, those claims are correct. Sometimes, they are smoke and
mirrors. Sometimes, Squid already violates those documents. The onus of
distinguishing these cases while defending your use case is on you.
If you believe that your feature does not violate an RFC that is being
thrown against it, then you have to convince others that it does not.
You may request that others cite specific MUST-level requirements that
the feature would violate and then build a logical argument proving that
those MUSTs will not be violated or that those MUSTs are already
violated by other Squid features.
Please do not misinterpret the above as veiled support for the feature
you are requesting. I am just clarifying the rules of the game because
your current assumptions about feature request triage may not match the
reality. I do not know whether your feature violates any important RFCs
(more than other features do) or is generally useful.
HTH,
Alex.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
