Internet DRAFT - draft-jennings-xcon-cscp
draft-jennings-xcon-cscp
XCON O. Novo
Internet-Draft Ericsson
Expires: June 12, 2006 C. Jennings
Cisco Systems
A. Roach
Estacado Systems
G. Camarillo
Ericsson
December 9, 2005
Conference State Change Protocol (CSCP)
draft-jennings-xcon-cscp-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Conference State Control Protocol (CSCP) is a means to modify the
state in a conference service. It extends the Binary Floor Control
Protocol and adds commands to get, set, add, and delete fields in the
Novo, et al. Expires June 12, 2006 [Page 1]
Internet-Draft Conference State Change Protocol December 2005
conference state.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Primitives . . . . . . . . . . . . . . . . . . . . . . . . 3
4. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. ELEMENT-ID . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Retrieving Attribute Values . . . . . . . . . . . . . . . 6
5.2. Setting Attribute Values . . . . . . . . . . . . . . . . . 7
5.3. Adding Elements . . . . . . . . . . . . . . . . . . . . . 8
5.4. Deleting an Element . . . . . . . . . . . . . . . . . . . 9
5.5. Deleting an Attribute . . . . . . . . . . . . . . . . . . 9
5.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 11
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. To Do Items . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Attribute Registration . . . . . . . . . . . . . . . . . . 13
9.2. Primitive Registration . . . . . . . . . . . . . . . . . . 13
9.3. Error Code Registration . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Novo, et al. Expires June 12, 2006 [Page 2]
Internet-Draft Conference State Change Protocol December 2005
1. Conventions
This document extends the Binary Floor Control Protocol (BFCP) [1]
and makes no sense if you have not read that document. This document
uses the terminology from the conference framework[4].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
2. Overview
CSCP is a client server protocol used to change the state of a
conference object. Note that the CSCP is just a protocol to
manipulate the conference object. It is not a general XML protocol
manipulation mechanism.
A client sends the server a request representing a sequence of
commands. Each command can set, get, add, or delete a single field
in the conference object. Changes to the conference object are
performed on a hierarchal set of elements and unique attributes
within those elements. A series of changes can be pipelined in a
single BFCP message [1]. The server executes each action in series.
If one of them fails, the server returns an error for the action that
failed and does not execute any of the actions after that. Each
individual action is atomic but the pipelined series is not.
The item that a command applies to is specified by a unique ID and,
where appropriate, attribute name. The ID is an unsigned 32 bit
integer called the ELEMENT-ID. How the server discovers the
ELEMENT-ID of a given element is outside of CSCP. Typically this is
done by using the conferencing framework notification service [5].
Each field in the data received in the notification contains a unique
field ID attribute that can be used in BFCP requests.
The values for fields are transferred as UTF-8 [3] encoded strings.
3. New Primitives
This document updates Table 1 in BFCP [1] with the following
primitives:
Novo, et al. Expires June 12, 2006 [Page 3]
Internet-Draft Conference State Change Protocol December 2005
+-------+--------------------+------------------+
| Value | Primitive | Direction |
+-------+--------------------+------------------+
| 14 | GetRequest | P -> S ; Ch -> S |
| 15 | GetInfo | P <- S ; Ch <- S |
| 16 | SetRequest | P -> S ; Ch -> S |
| 17 | SetAck | P <- S ; Ch <- S |
| 18 | AddElementRequest | P -> S ; Ch -> S |
| 19 | AddElementInfo | P <- S ; Ch <- S |
| 20 | DelElementRequest | P -> S ; Ch -> S |
| 21 | DelElementAck | P <- S ; Ch <- S |
| 22 | DelAttributeRequest| P -> S ; Ch -> S |
| 23 | DelAttributeAck | P <- S ; Ch <- S |
+-------+--------------------+------------------+
S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
Table 1: CSCP primitives
4. New Attributes
This document updates Table 2 in BFCP [1] and Table 1 in [6] with the
following new attributes:
+------+-----------------+---------------+
| Type | Attribute | Format |
+------+-----------------+---------------+
| 19 | ELEMENT-ID | Unsigned32 |
| 20 | NAME | OctetString |
| 21 | VALUE | OctetString |
+------+-----------------+---------------+
Table 2: CSCP attributes
4.1. ELEMENT-ID
The following is the format of a ELEMENT-ID attribute:
Novo, et al. Expires June 12, 2006 [Page 4]
Internet-Draft Conference State Change Protocol December 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 1|M|0 0 0 1 1 0 0 0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved field MUST be set to 0 by the sender, and MUST be
ignored by the receiver.
ID: This field contains a 32-bit value that uniquely identifies an
element within a conference. The ID values 0 and 0xFFFFFFFF are
reserved and MUST NOT be used.
4.2. NAME
The following is the format of a NAME attribute:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Text: this field contains UTF-8 [3] encoded text.
Padding: one, two, or three bytes of padding added so that the size
of the VALUE attribute is 32-bit aligned. The Padding bits SHOULD be
set to zero by the sender and MUST be ignored by the receiver. If
the attribute is already 32-bit aligned, no padding is included.
4.3. VALUE
The following is the format of a VALUE attribute:
Novo, et al. Expires June 12, 2006 [Page 5]
Internet-Draft Conference State Change Protocol December 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Text: this field contains the string encoding of the value. For
fields that are an integer, this is a base 10 encoded ASCII integer.
For binary values it is sent as the ASCII characters 0 and 1.
[Open Issue: should it be a binary type?)]
[Open Issue: Is attribute retrieval actually necessary or even
useful? This protocol is predicated on the client having access to
the conference state via some other mechanism and is intended
primarily for manipulation of such state.]
Padding: one, two, or three bytes of padding added so that the size
of the VALUE attribute is 32-bit aligned. The Padding bits SHOULD be
set to zero by the sender and MUST be ignored by the receiver. If
the attribute is already 32-bit aligned, no padding is included.
5. Behavior
5.1. Retrieving Attribute Values
Clients request the values of various attribute fields by sending the
GetRequest message to the server. A single GetRequest MUST NOT
contain the same {ELEMENT-ID,NAME} combination more than once;
otherwise, it is not possible to tell which of the multiple
operations has caused an error. If the request is not well-formed,
the server sends the Error message code 3 (Unknown Primitive), as
described in [1].
If the client inserts more than one ELEMENT-ID, the server will treat
the request as an atomic package. That is, it will either send all
the attributes information the client wishes to retrieve or sends an
error message.
If the NAME field is omitted for a given ELEMENT-ID, then the request
applies to the CDATA associated with the indicated element. The
following is the format of the message.
Novo, et al. Expires June 12, 2006 [Page 6]
Internet-Draft Conference State Change Protocol December 2005
GetRequest = (COMMON-HEADER)
1*( (ELEMENT-ID)
[NAME])
The request contains all the ELEMENT-ID and NAME elements for the
fields the client wishes to retrieve. The values of the requested
fields are returned in a GetInfo message.
If the client is not authorized to perform the operation being
requested, the Error message code 5 (Unauthorized Operation), as
described in [1] is sent. If the client requests some attributes
unknown from the server, the server sends the Error message 16
(Attribute could not be deleted).
GetInfo = (COMMON-HEADER)
1*( (ELEMENT-ID)
(NAME)
(VALUE))
5.2. Setting Attribute Values
The SetRequest asks for the values of one or more fields to be
changed. A single SetRequest MUST NOT contain the same combination
of {ELEMENT-ID,NAME} more than once. If the request is not well-
formed, the server sends the Error message code 3 (Unknown
Primitive), as described in [1].
If the NAME field is omitted for a given ELEMENT-ID, then the request
applies to the CDATA associated with the indicated element.
If the client inserts more than one ELEMENT-ID, the server will treat
the request as an atomic package. That is, it will either send all
the attributes information the client wishes to retrieve or sends an
error message.
If the SetRequest refers to an attribute which does not yet exist in
the indicated element, then that attribute is added and set to the
indicated value.
SetRequest = (COMMON-HEADER)
1*( (ELEMENT-ID)
[NAME]
(VALUE))
Novo, et al. Expires June 12, 2006 [Page 7]
Internet-Draft Conference State Change Protocol December 2005
If a SetRequest is successful, the server responds with a SetAck.
This SetAck contains the ELEMENT-ID and NAME fields for all fields
which were successfully set. If any of the fields cannot be
successfully set, an Error Code 13 (One or more attributes could not
be succesfully set) returns the value of the first ELEMENT-ID that
failed. If the client is not authorized to perform the operation
being requested, the Error message code 5 (Unauthorized Operation),
as described in [1] is sent.
SetAck = (COMMON-HEADER)
1*( (ELEMENT-ID)
(NAME))
5.3. Adding Elements
The AddElementRequest message contains a pair of ELEMENT-ID/NAME
attributes. The ELEMENT-ID field refers to an existing element; the
new element will be created as a child to the indicated element. The
NAME field indicates the name of the element that is to be added. If
the client is not authorized to perform the operation being
requested, the Error message code 5 (Unauthorized Operation), as
described in [1] is sent.
AddElementRequest = (COMMON-HEADER)
(ELEMENT-ID)
(NAME)
The server sends an AddElementInfo containing the newly created
ELEMENT-ID. It is not possible to add multiple elements of the same
name in a single request because there is no way to correlate errors
with the addition that caused the error.
AddElementInfo = (COMMON-HEADER)
(ELEMENT-ID)
AddElementInfo returns the new ELEMENT-ID for any elements that were
created. Otherwise, if there is an error in creating the field, an
Error message with code 13 (Element can not be created) is returned;
Novo, et al. Expires June 12, 2006 [Page 8]
Internet-Draft Conference State Change Protocol December 2005
5.4. Deleting an Element
DelElementRequest requests that the server delete the specified
element and all of its attributes and children.
DelElementRequest = (COMMON-HEADER)
1*(ELEMENT-ID)
If the DelElementRequest is successful, the server responds with a
DelElementAck, which includes the list of deleted elements. If the
client is not authorized to perform the operation being requested,
the Error message code 5 (Unauthorized Operation), as described in
[1] is sent.
DelElementAck = (COMMON-HEADER)
1*(ELEMENT-ID)
DelElementAck returns the ELEMENT-ID for any elements that were
deleted. Otherwise, if there is an error deleting any fields, an
Error message with code 15 (Element can not be deleted) with the
ELEMENT-ID of the first field that could not be deleted is returned.
The server will treat the request as an atomic package. That is, it
will either sends all the attributes information the client wishes to
retrieve or sends an error message.
5.5. Deleting an Attribute
DelAttributeRequest requests that the server delete the specified
attribute. Upon success, the server responds with a DelAttributeAck
with the list of deleted fields.
DelAttributeRequest = (COMMON-HEADER)
1*( (ELEMENT-ID)
[NAME])
If the client is not authorized to perform the operation being
requested, the Error message code 5 (Unauthorized Operation), as
described in [1] is sent.
If the NAME field is omitted for a given ELEMENT-ID, then the request
applies to the CDATA associated with the indicated element.
Novo, et al. Expires June 12, 2006 [Page 9]
Internet-Draft Conference State Change Protocol December 2005
DelAttributeAck = (COMMON-HEADER)
1*( (ELEMENT-ID)
(NAME))
DelAttributeAck returns the ELEMENT-ID for any elements that were
deleted. Otherwise, if there is an error deleting any fields, an
Error message with code 16 (Attribute can not be deleted) with the
ELEMENT-ID and NAME of the first field that could not be deleted is
returned. The server will treat the request as an atomic package.
That is, it will either sends all the attributes information the
client wishes to retrieve or sends an error message.
5.6. Errors
The format of the Error messages defined in [1] is also modified to
have optional ELEMENT-ID and NAME attributes. When these attributes
are present in an Error, it indicates the element (and, where
appropriate, attribute) in the request that caused the error.
Note that we use new ELEMENT-ID and NAME attributes in the Error
messages instead of defining a Error Specific Details for this error
codes.
Error = (COMMON-HEADER)
(ERROR-CODE)
[ERROR-INFO]
[ELEMENT-ID]
[NAME]
*[EXTENSION-ATTRIBUTE]
The following is the definition of Error code meaning:
+-------+----------------------------------------------------+
| Value | Meaning |
+-------+----------------------------------------------------+
| 13 | One or more attributes could not be succesfully set|
| 14 | Element could not be created |
| 15 | Element could not be deleted |
| 16 | Attribute could not be deleted |
| 17 | Unknown Attribute |
+-------+----------------------------------------------------+
Table 3: Error Code meaning
Novo, et al. Expires June 12, 2006 [Page 10]
Internet-Draft Conference State Change Protocol December 2005
6. Server Behaviour
A conference server sending a notification to a client using the SIP
event package [5] MUST included the ELEMENT-ID in every element of
the XML document. The ELEMENT-ID values 0 and 0xFFFFFFFF are
reserved and MUST NOT be used. It is RECOMMENDED that once an
ELEMENT-ID value is used in an element within a conference, the same
ELEMENT-ID value is not used in the same conference again in a
different element.
7. Example
The following is an example of a partial conference information
document extracted from the SIP event package [5]. Each element in
this example has a new attribute "index" that contains the value to
be used in the ELEMENT-ID attribute of a CSCP message acting on that
element.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info index="1"
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description index="2">
<subject index="3">Agenda: This month's goals</subject>
<service-uris index="4">
<entry index="5">
<uri index="6">http://sharepoint/salesgroup/</uri>
<purpose index="7">web-page</purpose>
</entry>
</service-uris>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state index="8">
<user-count index="9">33</user-count>
</conference-state>
<!--
USERS
-->
<users index="10">
<user index="11" entity="sip:bob@example.com" state="full">
Novo, et al. Expires June 12, 2006 [Page 11]
Internet-Draft Conference State Change Protocol December 2005
<display-text index="12">Bob Hoskins</display-text>
<!--
ENDPOINTS
-->
<endpoint index="13"entity="sip:bob@pc33.example.com">
<display-text index="14">Bob's Laptop</display-text>
<status index="15">disconnected</status>
<disconnection-method index="16">departed</disconnection-method>
<disconnection-info index="17">
<when index="18">2005-03-04T20:00:00Z</when>
<reason index="19">bad voice quality</reason>
<by index="20">sip:mike@example.com</by>
</disconnection-info>
<!--
MEDIA
-->
<media index="21" id="1">
<display-text index="22">main audio</display-text>
<type index="23">audio</type>
<label index="24">34567</label>
<src-id index="25">432424</src-id>
<status index="26">sendrecv</status>
</media>
</endpoint>
</user>
<!--
USER
-->
<user index="27" entity="sip:alice@example.com" state="full">
<display-text index="28">Alice</display-text>
<!--
ENDPOINTS
-->
<endpoint index="29" entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
<status index="30">connected</status>
<joining-method index="31">dialed-out</joining-method>
<joining-info index="32">
<when index="33">2005-03-04T20:00:00Z</when>
<by index="34">sip:mike@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media index="35" id="1">
<display-text index="36">main audio</display-text>
<type index="37">audio</type>
<label index="38">34567</label>
<src-id index="39">534232</src-id>
Novo, et al. Expires June 12, 2006 [Page 12]
Internet-Draft Conference State Change Protocol December 2005
<status index="40">sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
So, changing the entity attribute of the <user> element from
"sip:bob@pc33.example.com" to "Cullen.Fluffy@example.com" would be
requested by sending a SetRequest with ELEMENT-ID = 13, NAME =
"entity", and VALUE = "Cullen.Fluffy@example.com".
8. To Do Items
This needs to be lined up so that it can be correlated with the "SIP
Event Package for Conference State" [5].
9. IANA Considerations
The following sections instruct the IANA to perform a set of actions.
9.1. Attribute Registration
The IANA is instructed to register the following new values under the
Attribute subregistry under the BFCP Parameters registry.
+------+-----------------+-------------+
| Type | Attribute | Reference |
+------+-----------------+-------------+
| 19 | ELEMENT-ID | [RFC XXXX] |
| 20 | NAME | [RFC XXXX] |
| 21 | VALUE | [RFC XXXX] |
+------+-----------------+-------------+
Table 4: New values of the BFCP Attribute subregistry
9.2. Primitive Registration
The IANA is instructed to register the following new values under the
Primitive subregistry under the BFCP Parameters registry.
Novo, et al. Expires June 12, 2006 [Page 13]
Internet-Draft Conference State Change Protocol December 2005
+-------+--------------------+------------+
| Value | Primitive | Reference |
+-------+--------------------+------------+
| 14 | GetRequest | [RFC XXXX] |
| 15 | GetInfo | [RFC XXXX] |
| 16 | SetRequest | [RFC XXXX] |
| 17 | SetAck | [RFC XXXX] |
| 18 | AddElementRequest | [RFC XXXX] |
| 19 | AddElementInfo | [RFC XXXX] |
| 20 | DelElementRequest | [RFC XXXX] |
| 21 | DelElementAck | [RFC XXXX] |
| 22 | DelAttributeRequest| [RFC XXXX] |
| 23 | DelAttributeAck | [RFC XXXX] |
+-------+--------------------+------------+
Table 5: New values of the BFCP Primitives subregistry
9.3. Error Code Registration
The IANA is instructed to register the following new values under the
Error Code subregistry under the BFCP Parameters registry.
+-------+----------------------------------------------------+-----------+
| Value | Meaning | Reference |
+-------+----------------------------------------------------+-----------+
| 13 | One or more attributes could not be succesfully set|[RFC XXXX] |
| 14 | Element could not be created |[RFC XXXX] |
| 15 | Element could not be deleted |[RFC XXXX] |
| 16 | Attribute could not be deleted |[RFC XXXX] |
| 17 | Unknown Attribute |[RFC XXXX] |
+-------+----------------------------------------------------+-----------+
Table 6: New Values of the Error Code subregistry
10. Security Considerations
The security considerations of [1] and [6] apply. This memo does not
introduce any known additional security risk.
11. Acknowledgments
Novo, et al. Expires June 12, 2006 [Page 14]
Internet-Draft Conference State Change Protocol December 2005
Thanks to Roni Even for his comments.
12. References
12.1. Normative References
[1] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
12.2. Informative References
[4] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02 (work
in progress), February 2005.
[5] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[6] Camarillo, G., "Connection Establishment in the Binary Floor
Control Protocol (BFCP)", draft-ietf-xcon-bfcp-connection-00
(work in progress).
Novo, et al. Expires June 12, 2006 [Page 15]
Internet-Draft Conference State Change Protocol December 2005
Authors' Addresses
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Oscar.Novo@ericsson.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421 9990
Email: fluffy@cisco.com
Adam Roach
Estacado Systems
Dallas, TX
US
Email: adam@estacado.net
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Novo, et al. Expires June 12, 2006 [Page 16]
Internet-Draft Conference State Change Protocol December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Novo, et al. Expires June 12, 2006 [Page 17]
