0 [...] Refer-To: <sips s:lucy@psychic.org;method=REFER?Refer-to=sips: hypnotic-talks\% 40circles.com> Furthermore, the refer-to URI argument is not limited to SIP, but may point to any valid Internet resource. In referring to non-SIP resource URIs, user agent clients are entitled to exchange input to collateral applications, e.g., as part of collaborative tasks or environments. 6.2.2.4 INVITE-Contained URI Lists All mechanisms for ad-hoc conference management described SO far define incremental operations for adding or joining single users into a multi-party ses- sion. This procedure may be time-consuming for larger conferences and delay conference establishment in an alienating fashion. Current work proposes an extension of SIP operations to include URI lists [25] treated like e-mail, where individual delivery can be handled in parallel according to address lists. These lists are encoded in XML, denoted by a "recipient-list-invite" SIP option-tag, and appended to the regular conference invitation messages. A user agent client in a typical scenario sends an INVITE including a recipient list to a conference server, which then will simultaneously invite all the list members. Note that the conference server does not process the initial INVITE as a nested transaction, but will acknowledge positively, whenever the conference was created. To inquire about actual members, the client needs to actively search user lists provided by the conference state event package described in the following section. 6.2.2.5 Conferencing Event States An established conference incorporates a potentially large number of member- dependent states, exceeding those of a regular dialog. To support notification for tightly coupled conferences, an event package for conference states [26] has been defined. Its focus lies in providing membership information, but notifica- tions about additional conference components are foreseen as well. Typically, these data are provided by the conference focus, which may learn states while performing its regular