lticast will be dis- cussed in Section 3.10. Multicast is slowly becoming a part of the public Inter- net as service providers begin supporting it. 1.9 ABNF Representation The meta-language Augmented Backus-Naur Format [17] is used throughout RFC 3261 [1] to describe the syntax of SIP, as well as other Internet protocols. An example construct used to describe a SIP message is as follows: SIP-message = Request / Response This is read: A SIP message is either a request or a response. SIP- message on the left side of the "equals" sign represents what is being defined. The right side of the "equals" sign contains the definition. The "/" is used to mean logical OR (note: older versions of ABNF used "I" in place of "/" in gram- mars). Next, Request and Response are defined in a similar manner using ABNF: Request = Request-Line * ( message-header ) CRLF [ message-body ] Request - Line will be defined in another ABNF statement. Elements enclosed in () are treated as a single element. The "*" means the element may be SIP: Understanding the Session Initiation Protocol repeated, separated by at least one space. The minimum and maximum num- bers can be represented as x*y, which means a minimum of X and maximum of y. Since the default values are 0 and infinity, a solitary "*" (as in this example) indicates any number is allowed, including none. CRLF is defined as a carriage return line feed, or the ASCII characters that are written in Internet hexadecimal notation as 0x10 and 0x13. Other common ABNF representations include SP for space (ASCII 0x32). A message body is optional in a Request, and is enclosed in square brackets [ ] to indicate this. Comments in the ABNF begin with a semicolon ";" and continue to the end of the line. Lines continue the same ABNF definition when they are indented. Tokens are defined in ABNF as any set of characters besides control characters and separators. Display names and other components of a SIP header that are not used by the protocol are consid- ered tokens; they are simply parsed and ignore