\section{Summary of Augmented BNF}
\label{sec:abnf}

All of the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur Form (BNF) similar to that used by
RFC 822 \cite{rfc822} and RFC 2234 \cite{rfc2234}.  Implementors will
need to be familiar with the notation in order to understand this
specification.  The augmented BNF includes the following constructs:

\begin{syntax}
name & = & definition \\
\end{syntax}

The name of a rule is simply the name itself (without any enclosing
``$<$'' and ``$>$'') and is separated from its definition by the equal
``='' character.  White space is only significant in that indentation of
continuation lines is used to indicate a rule definition that spans more
than one line.  Certain basic rules are in uppercase, such as SP, LWS,
HT, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used within definitions
whenever their presence will facilitate discerning the use of rule
names.

\begin{verbatim}
"literal"
\end{verbatim}
Quotation marks surround literal text.  Unless stated otherwise, the
text is case-insensitive.

\begin{verbatim}
rule1 | rule2
\end{verbatim}
Elements separated by a bar ("$|$") are alternatives, e.g., ``yes $|$ no''
will accept yes or no.

\begin{verbatim}
(rule1 rule2)
\end{verbatim}
Elements enclosed in parentheses are treated as a single element.  Thus,
``(elem (foo $|$ bar) elem)'' allows the token sequences ``elem foo
elem'' and ``elem bar elem''.

\begin{verbatim}
*rule
\end{verbatim}
The character "*" preceding an element indicates repetition.  The full
form is "$<n>$*$<m>$element" indicating at least $<n>$ and at most $<m>$
occurrences of element.  Default values are 0 and infinity so that
"*(element)" allows any number, including zero; "1*element" requires at
least one; and "1*2element" allows one or two.

\begin{verbatim}
[rule]
\end{verbatim}
Square brackets enclose optional elements; "[foo bar]" is equivalent to
"*1(foo bar)".

\begin{verbatim}
N rule
\end{verbatim}
Specific repetition:  ``$<$n$>$(element)'' is equivalent to
``$<$n$>$*$<$n$>$(element)"; that is, exactly $<$n$>$ occurrences of
(element).  Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of
three alphabetic characters.

\begin{verbatim}
#rule
\end{verbatim}
A construct ``\header{\#}'' is defined, similar to ``\header{*}'', for
defining lists of elements.  The full form is ``\header{$<n>$\#$<m>$
element}'' indicating at least $<n>$ and at most $<m>$ elements, each
separated by one or more commas (``\header{,}'') and {\OPTIONAL} linear
white space (LWS).  This makes the usual form of lists very easy; a rule
such as

\begin{syntax}
&&  ( *LWS element *( *LWS "," *LWS element )) \\
\end{syntax}

can be shown as \header{1\# element}.  Wherever this construct is used,
null elements are allowed, but do not contribute to the count of
elements present.  That is, ``\header{(element), , (element)}'' is
permitted, but counts as only two elements.  Therefore, where at least
one element is required, at least one non-null element {\MUST} be
present.  Default values are 0 and infinity so that
``\header{\#element}'' allows any number, including zero;
``\header{1\#element}'' requires at least one; and
``\header{1\#2element}'' allows one or two.

\begin{verbatim}
; comment
\end{verbatim}
A semi-colon, set off some distance to the right of rule text, starts a
comment that continues to the end of line.  This is a simple way of
including useful notes in parallel with the specifications.

\begin{verbatim}
implied *LWS
\end{verbatim}
The grammar described by this specification is word-based.  Except where
noted otherwise, linear white space (LWS) can be included between any
two adjacent words (\header{token} or \header{quoted-string}), and
between adjacent tokens and separators, without changing the
interpretation of a field.  At least one delimiter (LWS and/or
separators) {\MUST} exist between any two tokens (for the definition of
``token'' below), since they would otherwise be interpreted as a single
token.  Note that URLs do \textbf{NOT} contain LWS.

\subsection{Basic Rules}

The following rules are used throughout this specification to describe
basic parsing constructs.  The US-ASCII coded character set is defined
by ANSI X3.4-1986.

\begin{syntax}
OCTET   & = & \%x00-ff ; \textrm{any 8-bit sequence of data}\\
CHAR    & = & \%x00-7f ; \textrm{any US-ASCII character (octets 0 - 127)}\\
upalpha     & = & "A" $|$ "B" $|$ "C" $|$ "D" $|$ "E" $|$ "F" $|$ "G" $|$ "H" $|$ "I" $|$\\
            &   & "J" $|$ "K" $|$ "L" $|$ "M" $|$ "N" $|$ "O" $|$ "P" $|$ "Q" $|$ "R" $|$\\
            &   & "S" $|$ "T" $|$ "U" $|$ "V" $|$ "W" $|$ "X" $|$ "Y" $|$ "Z"\\

lowalpha    & = & "a" $|$ "b" $|$ "c" $|$ "d" $|$ "e" $|$ "f" $|$ "g" $|$ "h" $|$ "i" $|$\\
            &   & "j" $|$ "k" $|$ "l" $|$ "m" $|$ "n" $|$ "o" $|$ "p" $|$ "q" $|$ "r" $|$\\
            &   & "s" $|$ "t" $|$ "u" $|$ "v" $|$ "w" $|$ "x" $|$ "y" $|$ "z"\\
alpha       & = & lowalpha $|$ upalpha\\
DIGIT       & = & "0" $|$ "1" $|$ "2" $|$ "3" $|$ "4" $|$ "5" $|$ "6" $|$ "7" $|$\\
            &   & "8" $|$ "9" \\
alphanum    & = & alpha $|$ DIGIT\\
CTL     & = & \%x00-1f $|$ \%x7f ; \textrm{(octets 0 -- 31) and} DEL \textrm{(127)}\\
CR      & = & \%d13  ; \textrm{US-ASCII CR, carriage return character}\\
LF      & = & \%d10  ; \textrm{US-ASCII LF, line feed character}\\
SP      & = & \%d32  ; \textrm{US-ASCII SP, space character}\\
HT      & = & \%d09  ; \textrm{US-ASCII HT, horizontal tab character}\\
CRLF    & = & CR LF  ; \textrm{typically the end of a line}\\
\end{syntax}

The following are defined in RFC 2396 \cite{rfc2396} for the SIP URI:
\begin{syntax}
unreserved  & = & alphanum $|$ mark\\
mark        & = & "-" $|$ "\_" $|$ "." $|$ "!" $|$ "\~{}" $|$ "*" $|$ "'"\\
            &$|$& "(" $|$ ")"\\
escaped     & = & "\%" hex hex\\
\end{syntax}

SIP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab.  All linear
white space, including folding, has the same semantics as SP.  A
recipient {\MAY} replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.

\begin{syntax}
LWS   & = & *( SP $|$ HT ) [CRLF] 1*( SP $|$ HT ) ; \textrm{linear whitespace}\\
\end{syntax}

The \header{TEXT-UTF8} rule is only used for descriptive field contents
and values that are not intended to be interpreted by the message
parser.  Words of \header{*TEXT-UTF8} contain characters from the UTF-8
character set (RFC 2279 \cite{rfc2279}).  The \header{TEXT-UTF8-TRIM}
rule is used for descriptive field contents that are {\em not} quoted
strings, where leading and trailing LWS is not meaningful.  In this
regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.

\begin{syntax}
TEXT-UTF8      & =   & *(TEXT-UTF8char $|$ LWS)\\
TEXT-UTF8-TRIM & =   & *TEXT-UTF8char *(*LWS TEXT-UTF8char)\\
TEXT-UTF8char  & =   & \%x21-7e\\
               & $|$ & UTF8-NONASCII\\
UTF8-NONASCII  & =   & \%xc0-df 1UTF8-CONT\\
               & $|$ & \%xe0-ef 2UTF8-CONT\\
               & $|$ & \%xf0-f7 3UTF8-CONT\\
               & $|$ & \%xf8-fb 4UTF8-CONT\\
               & $|$ & \%xfc-fd 5UTF8-CONT\\
UTF8-CONT      & =   & \%x80-bf\\
\end{syntax}

A CRLF is allowed in the definition of \header{TEXT-UTF8} only as part
of a header field continuation.  It is expected that the folding
\header{LWS} will be replaced with a single \header{SP} before
interpretation of the \header{TEXT-UTF8} value.

Hexadecimal numeric characters are used in several protocol elements.

\begin{syntax}
hex & = & "A" $|$ "B" $|$ "C" $|$ "D" $|$ "E" $|$ "F" \\
    &   & $|$ "a" $|$ "b" $|$ "c" $|$ "d" $|$ "e" $|$ "f" $|$ DIGIT \\
\end{syntax}

Many SIP header field values consist of words separated by LWS or
special characters.  Unless otherwise stated, tokens are
case-insensitive.  These special characters {\MUST} be in a quoted
string to be used within a parameter value.

\begin{syntax}
token       & = & 1*(alphanum $|$ "-" $|$ "." $|$ "!" $|$ "\%" $|$ "*"
$|$ "\_" $|$ "+" $|$ "`" $|$ "'" $|$ "\~{}" )\\
separators  & = & "(" $|$ ")" $|$ "$<$" $|$ "$>$" $|$ "@" $|$ \\
            &   & "," $|$ ";" $|$ ":" $|$ "$\backslash$" $|$ $<$"$>$ $|$ \\
            &   & "/" $|$ "[" $|$ "]" $|$ "?" $|$ "=" $|$ \\
            &   & "\{" $|$ "\}" $|$ SP $|$ HT \\
\end{syntax}

Comments can be included in some SIP header fields by surrounding the
comment text with parentheses.  Comments are only allowed in fields
containing ``comment'' as part of their field value definition.  In all
other fields, parentheses are considered part of the field value.

\begin{syntax}
comment     & = & ``(`` *(ctext $|$ quoted-pair $|$ comment) ``)'' \\
ctext       & = & $<${\rm any} TEXT-UTF8 {\rm excluding} ``(`` {\rm and} ``)''$>$\\ 
\end{syntax}

A string of text is parsed as a single word if it is quoted using
double-quote marks.  In quoted strings, quotation marks (") and
backslashes ($\backslash$) need to be escaped.

\begin{syntax}
quoted-string  & =   & ( $<$"$>$ *(qdtext $|$ quoted-pair ) $<$"$>$ )\\
qdtext         & =   & LWS $|$ \%x21 $|$ \%x23-5b $|$ \%x5d-7e\\
               & $|$ & UTF8-NONASCII\\
\end{syntax}

The backslash character ("$\backslash$") {\MAY} be used as a
single-character quoting mechanism only within quoted-string and comment
constructs.  Unlike HTTP/1.1, the characters CR and LF cannot be escaped
by this mechanism to avoid conflict with line folding and header
separation.

\begin{syntax}
quoted-pair & = & "$\backslash$" (\%x00 - \%x09 $|$ \%x0b $|$ \%x0c $|$ \%x0e - \%x7f)
\end{syntax}
