Appendix B. Changes since RFC 4288

Suffixes to indicate the use of a particular structured syntax are now fully specified and a suffix registration process has been defined.
Registration of widely deployed unregistered unfaceted type names in the vendor or personal trees is now allowed, subject to approval by the media types reviewer and the IESG.
The standards-tree registration process has been revised to include Expert Review and generalized to address cases like media types in non-IETF stream documents.
A field for fragment identifiers has been added to the registration template and brief directions for specifying fragment identifiers have been added.
The specification requirements for personal-tree registrations have been changed to be the same as those for the vendor tree. The text has been changed to encourage (but not require) specification availability.
The process for defining additional trees has been clarified to state that an IETF Standards Action is required.
Widely deployed types with "x-" names can now be registered as an exception in the vendor tree.
The requirements on changes to registrations have been loosened so minor changes are easier to make.
The registration process has been completely restructured so that with the exception of IETF-generated types in the standards tree, all requests are processed by IANA and not the IESG.
A provisional registration process has been added for early assignment of types in the standards tree.
The "Restrictions on Usage" field in the registration template has been changed to "optional".
It is now encouraged but not required to specify recommendations for interoperating with certain constraints. (In RFC 4288, it was encouraged but not required to specify a set of encodings which must be supported, but this was viewed as too prescriptive.)
New charset parameter requirements have been added for text media types.
The name of the personal tree has been changed to the "personal or vanity" tree to better reflect its intended use.