<div dir="ltr">That's very helpful guidance, Alex. Thank you.<div><br></div><div>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.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 2:43 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/13/2017 02:41 PM, David Kewley wrote:<br>
<br>
> I will proceed assuming that squid will never support the sort of<br>
> spoofing I was hoping for (since it would probably simplify things<br>
> greatly for us), even though I believe in our design that spoofing would<br>
> have been safe.<br>
<br>
</span>If you have a legitimate use case, Squid may address it. You just need<br>
to convince developers that your use case does not violate basic<br>
internet principles (more than the existing code does) and is generally<br>
useful (i.e., many folks may find the new feature useful).<br>
<br>
In such discussions, claims of RFC or BCP violations are often made.<br>
Sometimes, those claims are correct. Sometimes, they are smoke and<br>
mirrors. Sometimes, Squid already violates those documents. The onus of<br>
distinguishing these cases while defending your use case is on you.<br>
<br>
If you believe that your feature does not violate an RFC that is being<br>
thrown against it, then you have to convince others that it does not.<br>
You may request that others cite specific MUST-level requirements that<br>
the feature would violate and then build a logical argument proving that<br>
those MUSTs will not be violated or that those MUSTs are already<br>
violated by other Squid features.<br>
<br>
<br>
Please do not misinterpret the above as veiled support for the feature<br>
you are requesting. I am just clarifying the rules of the game because<br>
your current assumptions about feature request triage may not match the<br>
reality. I do not know whether your feature violates any important RFCs<br>
(more than other features do) or is generally useful.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
</blockquote></div><br></div>