8. IANA 考虑事项 (IANA Considerations)
IANA 维护三个支持本规范的注册表, 它们都为 RFC 2821 或更早版本创建. 本文档按下文所述扩展第三个注册表. 所列注册表引用是发布日期时的引用; IANA 不保证与位置相关的 URL 稳定.
8.1. SMTP 服务扩展注册表 (SMTP Service Extensions Registry)
第一个注册表 "Simple Mail Transfer Protocol (SMTP) Service Extensions" 由 SMTP 服务扩展及其关联关键词组成, 并在需要时包含参数和动词. 如第 2.2.2 节所规定, 不得在此注册表中加入以 "X" 开头的条目. 只有专门为此目的由 IESG 批准的 standards-track 或 experimental RFC 中定义的服务扩展 (以及关联关键词, 参数或动词) 才能加入条目.
8.2. Address Literal Tags 注册表
第二个注册表 "Address Literal Tags" 由 "tags" 组成, 用于标识 IPv4 地址之外的 domain literal 形式 (IPv4 地址在 RFC 821 和本文档中规定). 该注册表的初始条目用于 IPv6 地址 (本文档规定). 其他 literal 类型在使用前需要标准化; 当前不预期有其他类型.
8.3. Mail Transmission Types 注册表
第三个注册表 "Mail Transmission Types" 由 RFC 821 建立并由本规范更新, 是用于第 4.4 节所述时间戳 ("Received:" 头部字段) 的 "via" 和 "with" 子句中的链路和协议标识符注册表. 除本文档中规定的链路和协议标识符外, 只有通过标准化或记录在 RFC 中且由 IESG 批准的实验性协议扩展才能加入条目. 该命名空间用于标识, 大小不受限制: 鼓励 IESG 基于清晰文档和独特方法批准条目, 而不是基于对方法本身属性的偏好.
该注册表的 "VIA link types" 和 "WITH protocol types" 子节中都添加了额外小节, 以容纳上文所述 "Additional-registered-clauses" 的注册. 注册表将包含子句名称, 描述, 关联 String 语法摘要以及引用. 原则上, 当定义新子句时, 如果 String 由保留术语或关键词组成而不是较不受限制的字符串, 可以规定创建自己的注册表. 与链路和协议标识符一样, 额外子句只能通过标准化或记录在 RFC 中且由 IESG 批准的实验性协议扩展注册. 额外子句命名空间用于标识, 大小不受限制: 鼓励 IESG 基于清晰文档, 实际使用或子句将被使用的强烈迹象, 以及独特需求批准条目, 而不是基于对子句本身属性的偏好.
此外, 如果将来创建额外 trace 头部字段 (即除了 Return-path 和 Received 之外), 这些 trace 字段必须加入 BCP 90 (RFC 3864) 建立的 RFC 5322 IANA 注册表.