8. IANA Considerations
IANA maintains three registries in support of this specification, all of which were created for RFC 2821 or earlier versions. This document extends the third registry as described below. The registry references listed are those as of the date of publication; IANA does not guarantee the stability of URLs associated with locations.
8.1. SMTP Service Extensions Registry
The first registry, "Simple Mail Transfer Protocol (SMTP) Service Extensions", consists of SMTP service extensions with associated keywords and, as needed, parameters and verbs. As specified in Section 2.2.2, no entry may be made in this registry that starts with "X". Entries may be made only for service extensions (and associated keywords, parameters, or verbs) that are defined in standards-track or experimental RFCs specifically approved by the IESG for this purpose.
8.2. Address Literal Tags Registry
The second registry, "Address Literal Tags", consists of "tags" that identify forms of domain literals other than those for IPv4 addresses (specified in RFC 821 and this document). The initial entry in this registry is for IPv6 addresses (specified in this document). Additional literal types require standardization before use; no additional types are currently anticipated.
8.3. Mail Transmission Types Registry
The third registry, "Mail Transmission Types", established by RFC 821 and updated by this specification, is a registry of link and protocol identifiers to be used with the "via" and "with" clauses of the timestamp ("Received:" header field) described in Section 4.4. In addition to the link and protocol identifiers specified in this document, entries may be made only by standardization or by experimental protocol extensions documented in RFCs and approved by the IESG. This name space is used for identification, and its size is not limited: the IESG is encouraged to approve entries based on clear documentation and a unique approach, rather than preferences about the properties of the approach itself.
An additional subsection has been added to both the "VIA link types" and "WITH protocol types" subsections of that registry to accommodate registrations of "Additional-registered-clauses" as described above. The registry will contain the clause name, a description, a summary of the syntax of the associated String, and a reference. In principle, as new clauses are defined, registries could be specified to create their own registries if the String consists of reserved terms or keywords rather than a less-restricted string. As with link and protocol identifiers, additional clauses may be registered only by standardization or by experimental protocol extensions documented in RFCs and approved by the IESG. The additional-clause name space is used for identification, and its size is not limited: the IESG is encouraged to approve entries based on clear documentation, actual use or strong indication that a clause will be used, and unique requirements, rather than preferences about the properties of the clause itself.
Additionally, if additional trace header fields (i.e., in addition to Return-path and Received) are ever created, those trace fields MUST be added to the IANA registry for RFC 5322 established by BCP 90 (RFC 3864).