官方的方法是编写一个RFC - 请求评论。人们会对此做出回应（这就是为什么它是RFC），并可能尝试实现您的协议。
只要存在两个完全支持该协议的独立实现，它就是一个新的标准。
当然，人们不会无聊地为某个人实现一个新协议。因此，您应该先找到一个有兴趣听取您意见的团体。也许已经有一个协议可以满足您的需求（或可以轻松扩展）。
但您可能不想发明一个新标准。标准需要大量工作，并且对某些人来说被高估了。
因此，您应该描述其工作原理并创建一个可以读写该协议的库，以便开发人员可以使用它，即使它不是官方标准。
你正在混淆协议标准和实现。
这两者没有关联。
协议是以高层次描述的，但具有足够的信息让某人理解应该如何实现它。
其想法是，阅读文档的人可以理解如何/在任何首选语言中实现什么。
举个例子：RFC中的SIP协议描述了各种流程，并且还有各种消息以及它们应该如何被处理，即语义定义良好。
您可以使用C++或Java实现SIP UA或服务器。这与SIP协议无关。
对此，您不需要提供任何源代码（如果您认为它有助于澄清描述中的某些模糊点，则可以提供）。
最重要的部分是，您的协议实际上是由利益相关者(期望它解决他们的问题)审查的。
这部分不仅因为它可以解决您的协议中的问题而最重要，而且因为他们实际上可以验证该概念是否牢固，即可以在技术上实现。
唯一的情况是可以指定某些具体内容或暗示某些内容，例如协议描述了某些具体约束条件（例如硬实时约束），这可以作为“提示”，告知应避免使用哪种实现/语言。
此外，如果我编写一个协议，并且标准组没有将其正式制定，人们 / 客户端仍然可以实现它吗？
奇怪的问题。你的意思是什么？其他人如何知道你的协议存在？
如果它是正式的，他可以从标准组获得并实施它。
否则，显然你有某种“专有”协议（这是很常见的，例如公司可以拥有自己软件的内部协议），人们必须从你那里获取规范。
由于您对保罗·格雷厄姆（Paul Graham）文章中的替换电子邮件部分感兴趣，因此我认为您需要开发协议定义并提供示例实现。协议定义不需要作为互联网协议标准发布才能有用。
您需要一个实现来测试、改进和完善这些想法。协议第一次尝试很难就能成功，您需要一些东西来支持最初的用户。
如果您希望其他人与您合作并采用改进后的电子邮件，则不需要协议定义，但是如果非常依赖于您的“商业模式”，则需要一个协议定义。我强烈建议您从一开始就拥有协议定义，即使只是为了在尝试生成第二个实现时保持理智。
我建议您查看一些关于协议和实现的巧妙方法的示例。我最喜欢的是在Viewpoints Research 2008 Progress report中描述的超紧凑的TCP/IP方法。
他们没有按照传统方法来开发协议的实现（协议栈）。相反，他们编写了一些代码来解析可读性强的TCP/IP协议规范，并从该协议文档生成了TCP/IP协议栈的代码。通常的TCP/IP协议栈大约有40,000行代码或更多。他们的程序只有160行代码，读取协议规范并自动产生TCP/IP协议栈的代码。他们使用非常强大的程序工具。
如果你也采用这种方法，那么你就可以使协议实现与规范同步，并且潜在地使其他人采用你的协议变得简单易行。
希望对你有所帮助。
