针对人们在参与互联网标准制定中存在的一些问题和误区，日前，ietf的资深研究人员nick发了一份邮件。
邮件是发给一个名叫khaled的人。khaled之前提交了自己的一个新的协议方案草案，自我感觉非常好。但该方案在ietf并没有得到采纳，他感到很生气。这一过程持续了两年，他一直说自己的方案非常好，但自己不是程序员，无法编程验证。最近他又换了一个工作组，重新提出他的草案，并发出关于ietf不够重视其提议的公开邮件。针对此，nick提出四点建议，这些建议提到的一些问题对于想在ietf提交草案并期望能够成为rfc标准的研究人员同样具有参考价值，邮件内容如下：
khaled：
过去几年中，有很多人看过你提议，他们通过几百封邮件的讨论交流后一致得出相同的结论：你的提议行不通。实际上，这也意味着，你是在要求ietf工作组处理一个他们觉得行不通的提议。
如果你想让ietf慎重考虑你的想法，那么你首先需要证明这些提议是可以实现的。那你就需要从倾听和处理意见开始，尤其是那些被多次提出着重讨论的问题。
关于此，我有几个建议：
1. 写一份你所提出的提议是如何工作的原理实现。或者是讲清楚，你所提出的技术是如何与ipv4或者ipv6网络建立连接的？
2. 更新其他协议的规范文件以支持你的提议，如路由协议：bgp、mpls、ospfv2、ospfv3、isis等。仅针对这些协议就至少有500个rfc，所以为什么不选择一小部分进行更新，使其能够支持你的想法？如果你能编写出一个有效的实现文档，应该会更好。
3. 为主机应用程序编写一个api规范以解决双重寻址问题。
4. 写一份你所提议的“路由协议”的实现细则，它应允许一个网络与另一个网络交换路由信息。专业提示：确保它能在你提议的技术上工作。
说你不是程序员以及让别人为你的想法编写代码必然是不可取的。现在的问题是，许多研究人员已经明确表示你的想法不可行，如果你希望你的想法被认真、慎重对待，那么你有责任去证明他们的想法是错误的。
一直争辩别人应该认真对待你的想法，这件事也是没有用的。除非你能证明它们是可以工作的，是确实有效的，否则人们不会认真对待它们。
当你写出代码证明你的想法确实可行，然后再回到ietf，也许那时人们会更认真地对待你的想法。
nick