2. 动机 (Motivation)

2. 动机 (Motivation)

有关端口注册表分配程序的信息过去分散在三个位置: IANA 网站上用于请求端口号分配的表单 [SYSFORM] [USRFORM], 列出端口号分配本身的文件 (称为端口号注册表) [PORTREG] 中的一段介绍性文字, 以及 IANA 分配指南 [RFC2780] 中两个简短章节.

类似地, 围绕服务名称的程序在历史上也不清晰. 服务名称最初作为端口号的助记标识符而创建, 除了 IANA 网站 [SYSFORM] [USRFORM] 上提到的 14 字符限制之外, 并没有明确定义的语法. 即使这一长度限制也没有被一致应用, 一些已分配的服务名称长度为 15 个字符. 当通过 DNS SRV 资源记录 (Resource Records, RRs) 进行服务识别的机制被引入 [RFC2782] 后, 单独分配服务名称开始变得有用. 由于 IANA 没有在不关联端口号的情况下分配服务名称的程序, 这导致在 IANA 控制之外创建了一个非正式的临时服务名称注册表, 该注册表现在包含约 500 个服务名称 [SRVREG].

本文档将这些分散信息汇总为单一参考, 对服务名称和端口号的管理程序进行协调并作出清晰定义. 相比现有文档, 它为服务名称和端口的潜在请求方提供更详细的指导, 并精简 IANA 管理注册表的程序, 以便及时完成请求.

本文档定义了在不关联端口号的情况下分配服务名称的规则, 以支持 DNS SRV 记录 [RFC2782] 等用途, 这是先前 IANA 程序无法做到的. 本文档还将来自非 IANA 临时注册表 [SRVREG] 和 IANA Protocol and Service Names 注册表 [PROTSERVREG] 的服务名称分配合并到 IANA Service Name and Transport Protocol Port Number 注册表 [PORTREG] 中, 后者自此成为服务名称和端口号的唯一权威注册表.

本文档的另一个目的, 是描述指导 IETF 和 IANA 作为服务名称与端口号注册表长期共同管理者所遵循的原则. 过去几十年中, TCP 和 UDP 取得了显著成功. 数以千计的应用和应用层协议已经获得服务名称和端口号用于自身用途, 并且完全有理由相信这一趋势会在未来持续. 因此, 注册表管理遵循能够确保其作为共享资源长期有用的原则至关重要. 第 7 节详细讨论这些原则.