2. 动机 (Motivation)

有关端口注册表分配程序的信息存在于三个位置：IANA 网站上用于请求端口号分配的表单 [SYSFORM] [USRFORM]、列出端口号分配本身的文件中的介绍性文本部分（称为端口号注册表）[PORTREG]，以及 IANA 分配指南 [RFC2780] 的两个简短部分。

同样，围绕服务名称的程序历史上一直不明确。服务名称最初被创建为端口号的助记标识符，没有明确定义的语法，除了 IANA 网站上提到的 14 个字符限制 [SYSFORM] [USRFORM]。即使这个长度限制也没有得到一致应用，一些分配的服务名称长度为 15 个字符。

当通过 DNS SRV 资源记录 (RRs) 引入服务识别 [RFC2782] 时，开始仅分配服务名称变得有用，由于 IANA 没有在不关联端口号的情况下分配服务名称的程序，这导致在 IANA 控制之外创建了一个非正式的临时服务名称注册表，该注册表现在包含大约 500 个服务名称 [SRVREG]。

本文档将所有这些分散的信息汇总到一个单一的参考文献中，该参考文献协调并明确定义了服务名称和端口号的管理程序。它为服务名称和端口的潜在请求者提供了比现有文档更详细的指导，并简化了 IANA 管理注册表的程序，以便及时完成请求。

本文档定义了在没有关联端口号的情况下分配服务名称的规则，用于诸如 DNS SRV 记录 [RFC2782] 之类的用途，这在以前的 IANA 程序下是不可能的。

该文档还将来自非 IANA 临时注册表 [SRVREG] 和 IANA 协议和服务名称注册表 [PROTSERVREG] 的服务名称分配合并到 IANA 服务名称和传输协议端口号注册表 [PORTREG] 中，从此以后这是服务名称和端口号的唯一权威注册表。

本文档的另一个目的是描述指导 IETF 和 IANA 作为服务名称和端口号注册表长期联合管理者的原则。TCP 和 UDP 在过去几十年中取得了显著的成功。数千个应用程序和应用层协议已经为其使用分配了服务名称和端口号，并且有充分的理由相信这一趋势将持续到未来。因此，注册表的管理遵循确保其作为共享资源长期有用性的原则是极其重要的。第 7 节详细讨论了这些原则。