Section 27 IANA Considerations

All method names, header field names, status codes, and option tags
   used in SIP applications are registered with IANA through
   instructions in an IANA Considerations section in an RFC.
   The specification instructs the IANA to create four new sub-
   registries under http://www.iana.org/assignments/sip-parameters:
   Option Tags, Warning Codes (warn-codes), Methods and Response Codes,
   added to the sub-registry of Header Fields that is already present
   there.
27.1 Option Tags
   This specification establishes the Option Tags sub-registry under
   http://www.iana.org/assignments/sip-parameters.
   Option tags are used in header fields such as Require, Supported,
   Proxy-Require, and Unsupported in support of SIP compatibility
   mechanisms for extensions (Section 19.2).  The option tag itself is a
   string that is associated with a particular SIP option (that is, an
   extension).  It identifies the option to SIP endpoints.
   Option tags are registered by the IANA when they are published in
   standards track RFCs.  The IANA Considerations section of the RFC
   must include the following information, which appears in the IANA
   registry along with the RFC number of the publication.
      o  Name of the option tag.  The name MAY be of any length, but
         SHOULD be no more than twenty characters long.  The name MUST
         consist of alphanum (Section 25) characters only.
      o  Descriptive text that describes the extension.
27.2 Warn-Codes
   This specification establishes the Warn-codes sub-registry under
   http://www.iana.org/assignments/sip-parameters and initiates its
   population with the warn-codes listed in Section 20.43.  Additional
   warn-codes are registered by RFC publication.
   The descriptive text for the table of warn-codes is:
   Warning codes provide information supplemental to the status code in
   SIP response messages when the failure of the transaction results
   from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.
   The "warn-code" consists of three digits.  A first digit of "3"
   indicates warnings specific to SIP.  Until a future specification
   describes uses of warn-codes other than 3xx, only 3xx warn-codes may
   be registered.
   Warnings 300 through 329 are reserved for indicating problems with
   keywords in the session description, 330 through 339 are warnings
   related to basic network services requested in the session
   description, 370 through 379 are warnings related to quantitative QoS
   parameters requested in the session description, and 390 through 399
   are miscellaneous warnings that do not fall into one of the above
   categories.
27.3 Header Field Names
   This obsoletes the IANA instructions about the header sub-registry
   under http://www.iana.org/assignments/sip-parameters.
   The following information needs to be provided in an RFC publication
   in order to register a new header field name:
      o  The RFC number in which the header is registered;
      o  the name of the header field being registered;
      o  a compact form version for that header field, if one is
         defined;
   Some common and widely used header fields MAY be assigned one-letter
   compact forms (Section 7.3.3).  Compact forms can only be assigned
   after SIP working group review, followed by RFC publication.
27.4 Method and Response Codes
   This specification establishes the Method and Response-Code sub-
   registries under http://www.iana.org/assignments/sip-parameters and
   initiates their population as follows.  The initial Methods table is:
         INVITE                   [RFC3261]
         ACK                      [RFC3261]
         BYE                      [RFC3261]
         CANCEL                   [RFC3261]
         REGISTER                 [RFC3261]
         OPTIONS                  [RFC3261]
         INFO                     [RFC2976]
   The response code table is initially populated from Section 21, the
   portions labeled Informational, Success, Redirection, Client-Error,
   Server-Error, and Global-Failure.  The table has the following
   format:
      Type (e.g., Informational)
            Number    Default Reason Phrase         [RFC3261]
   The following information needs to be provided in an RFC publication
   in order to register a new response code or method:
      o  The RFC number in which the method or response code is
         registered;
      o  the number of the response code or name of the method being
         registered;
      o  the default reason phrase for that response code, if
         applicable;
27.5 The "message/sip" MIME type.
   This document registers the "message/sip" MIME media type in order to
   allow SIP messages to be tunneled as bodies within SIP, primarily for
   end-to-end security purposes.  This media type is defined by the
   following information:
      Media type name: message
      Media subtype name: sip
      Required parameters: none
      Optional parameters: version
         version: The SIP-Version number of the enclosed message (e.g.,
         "2.0").  If not present, the version defaults to "2.0".
      Encoding scheme: SIP messages consist of an 8-bit header
         optionally followed by a binary MIME data object.  As such, SIP
         messages must be treated as binary.  Under normal circumstances
         SIP messages are transported over binary-capable transports, no
         special encodings are needed.
      Security considerations: see below
         Motivation and examples of this usage as a security mechanism
         in concert with S/MIME are given in 23.4.
27.6 New Content-Disposition Parameter Registrations
   This document also registers four new Content-Disposition header
   "disposition-types": alert, icon, session and render.  The authors
   request that these values be recorded in the IANA registry for
   Content-Dispositions.
   Descriptions of these "disposition-types", including motivation and
   examples, are given in Section 20.11.
   Short descriptions suitable for the IANA registry are:
      alert     the body is a custom ring tone to alert the user
      icon      the body is displayed as an icon to the user
      render    the body should be displayed to the user
      session   the body describes a communications session, for
                example, as RFC 2327 SDP body