Section 8. IANA Considerations

IANA maintains three registries in support of this specification, all
   of which were created for RFC 2821 or earlier.  This document expands
   the third one as specified below.  The registry references listed are
   as of the time of publication; IANA does not guarantee the locations
   associated with the URLs.  The registries are as follows:
   o  The first, "Simple Mail Transfer Protocol (SMTP) Service
      Extensions" [46], consists of SMTP service extensions with the
      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 in an "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.
   o  The second registry, "Address Literal Tags" [47], consists of
      "tags" that identify forms of domain literals other than those for
      IPv4 addresses (specified in RFC 821 and in this document).  The
      initial entry in that registry is for IPv6 addresses (specified in
      this document).  Additional literal types require standardization
      before being used; none are anticipated at this time.
   o  The third, "Mail Transmission Types" [46], established by RFC 821
      and renewed by this specification, is a registry of link and
      protocol identifiers to be used with the "via" and "with"
      subclauses of the time stamp ("Received:" header field) described
      in Section 4.4.  Link and protocol identifiers in addition to
      those specified in this document may be registered only by
      standardization or by way of an RFC-documented, IESG-approved,
      Experimental protocol extension.  This name space is for
      identification and not limited in size: the IESG is encouraged to
      approve on the basis of clear documentation and a distinct method
      rather than preferences about the properties of the method itself.
      An additional subsection has been added to the "VIA link types"
      and "WITH protocol types" subsections of this registry to contain
      registrations of "Additional-registered-clauses" as described
      above.  The registry will contain clause names, a description, a
      summary of the syntax of the associated String, and a reference.
      As new clauses are defined, they may, in principle, specify
      creation of their own registries if the Strings consist of
      reserved terms or keywords rather than less restricted strings.
      As with link and protocol identifiers, additional clauses may be
      registered only by standardization or by way of an RFC-documented,
      IESG-approved, Experimental protocol extension.  The additional
      clause name space is for identification and is not limited in
      size: the IESG is encouraged to approve on the basis of clear
      documentation, actual use or strong signs that the clause will be
      used, and a distinct requirement rather than preferences about the
      properties of the clause itself.
   In addition, 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 established by BCP 90 (RFC 3864) [11]
   for use with RFC 5322 [4].