\section{IANA Considerations}
\label{sec:iana}

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.

\subsection{Option Tags}
\label{sec:iana:option}

Option tags are used in header fields such as \header{Require},
\header{Supported}, \header{Proxy-Require}, and \header{Unsupported} in
support of SIP compatibility mechanisms for extensions
(Section~\ref{sec:option_tags}).  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.

\begin{itemize}
\item Name and description of option.  The name {\MAY} be of any length,
but {\SHOULD} be no more than twenty characters long.  The name {\MUST}
consist of \header{alphanum} (Section~\ref{sec:abnf}) characters
only.

\item An option tag token.

\item A short descriptive line about the option.

\end{itemize}

\subsection{Warn-Codes}
\label{sec:iana:warn}

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~\citenorm{rfc2327}).  New
``\header{warn-code}'' values can be registered with IANA as they arise.

The ``\header{warn-code}'' consists of three digits.  A first digit of
``3'' indicates warnings specific to SIP.

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.

\motivation{1xx and 2xx have been taken by HTTP/1.1.}

\subsection{Header Field Names}
\label{sec:iana:header}

The following information needs to be provided to IANA in order to
register a new header field name:

\begin{itemize}
\item The name and email address of the individual performing the
registration;
\item the name of the header field being registered;
\item a compact form version for that header field, if one is defined;
\item the name of the draft or RFC where the header field is defined;
\item a copy of the draft or RFC where the header field is defined.
\end{itemize}

Some common and widely used header fields {\MAY} be assigned
one-letter compact forms (Section~\ref{sec:message-compact}). Compact
forms can only be assigned after SIP working group review.  In the
absence of this working group, a designated expert reviews the request.

\subsection{Method and Response Codes}
\label{sec:iana:response}

The following information needs to be provided to IANA in order to
register a new response code or method:

\begin{itemize}
\item The name and email address of the individual performing the
registration;
\item the number of the response code or name of the method being
registered;
\item the default reason phrase for that status code, if applicable;
\item the name of the draft or RFC where the method or status code is
defined;
\item a copy of the draft or RFC where the method or status code is
defined.
\end{itemize}

\subsection{The ``message/sip'' MIME type.}
\label{sec:iana:appsip}

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:

\begin{verbatim}
   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: 8-bit or binary, and see below.
   Security considerations: see below
\end{verbatim}

SIP uses the UTF-8 charset over 8-bit text encoding for headers. While 
most header field names and values will lie in the 7-bit ASCII 
compatible range, header field values and SIP bodies may contain 8-bit values, 
and moreover some body parts may in turn contain binary data.  
The overall encoding of a 
``message/sip'' body therefore depends on any nested MIME body it 
contains. If the nested MIME body requires binary encoding, the entire 
``message/sip'' body {\MUST} use binary encoding. Otherwise, the 
``message/sip'' body {\MUST} use 8-bit encoding.

Motivation and examples of this usage as a security mechanism in 
concert with S/MIME are given in~\ref{sec:security:tunnel}. 

\subsection{New Content-Disposition Parameter Registrations}
\label{sec:iana:content-disps}

This document also registers four new \header{Content-Disposition}
header ``\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 ``\header{disposition-types}'', including 
motivation and examples, are given in Section~\ref{sec:Content-Disposition}.

Short descriptions suitable for the IANA registry are:

\begin{verbatim}
 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 is an RFC2327 SDP body
\end{verbatim}
