1. Introduction

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, many protocols,
   including but not limited to MIME [RFC2045], are capable of carrying
   arbitrary labeled content.  A mechanism is needed to label such
   content and a registration process is needed for these labels, to
   ensure that the set of such values is developed in an orderly, well-
   specified, and public manner.

   This document defines media type specification and registration
   procedures that use the Internet Assigned Numbers Authority (IANA) as
   a central registry.

   Historical Note

      The media type registration process was initially defined for
      registering media types for use in the context of the asynchronous
      Internet mail environment.  In this mail environment there is a
      need to limit the number of possible media types, to increase the
      likelihood of interoperability when the capabilities of the remote
      mail system are not known.  As media types are used in new
      environments in which the proliferation of media types is not a
      hindrance to interoperability, the original procedure proved
      excessively restrictive and had to be generalized.  This was
      initially done in [RFC2048], but the procedure defined there was
      still part of the MIME document set.  The media type specification
      and registration procedure has now been moved to this separate
      document, to make it clear that it is independent of MIME.

      It may be desirable to restrict the use of media types to specific
      environments or to prohibit their use in other environments.  This
      revision attempts for the first time to incorporate such
      restrictions into media type registrations in a systematic way.
      See Section 4.9 for additional discussion.

1.1. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This specification makes use of the Augmented Backus-Naur Form (ABNF)
   [RFC4234] notation, including the core rules defined in Appendix A of
   that document.