draft-ietf-xcon-floor-control-req-01.txt   draft-ietf-xcon-floor-control-req-02.txt 
Transport Area P. Koskelainen Transport Area P. Koskelainen
Internet-Draft Nokia Internet-Draft Nokia
Expires: January 17, 2005 J. Ott Expires: April 23, 2005 J. Ott
Uni Bremen TZI Uni Bremen TZI
H. Schulzrinne H. Schulzrinne
X. Wu X. Wu
Columbia University Columbia University
July 19, 2004 October 23, 2004
Requirements for Floor Control Protocol Requirements for Floor Control Protocol
draft-ietf-xcon-floor-control-req-01.txt draft-ietf-xcon-floor-control-req-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005. This Internet-Draft will expire on April 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resource in a (multiparty) conferencing environment. Thereby, shared resource in a (multiparty) conferencing environment. Thereby,
floor control complements other functions -- such as conference and floor control complements other functions -- such as conference and
media session setup, conference policy manipulation, and media media session setup, conference policy manipulation, and media
control -- that are realized by other protocols. This document control -- that are realized by other protocols. This document
defines the requirements for a floor control protocol for multiparty defines the requirements for a floor control protocol for multiparty
conferences in the context of an existing framework. conferences in the context of an existing framework.
skipping to change at page 2, line 27 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7
6. Assumptions about a Conference Policy . . . . . . . . . . . . 8 6. Assumptions about a Conference Policy . . . . . . . . . . . . 8
7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10 7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10
7.1 Communication between Participant and Server . . . . . . . 10 7.1 Communication between Participant and Server . . . . . . . 10
7.2 Communicaton between Chair and Server . . . . . . . . . . 11 7.2 Communicaton between Chair and Server . . . . . . . . . . 11
7.3 General Protocol Requirements . . . . . . . . . . . . . . 12 7.3 General Protocol Requirements . . . . . . . . . . . . . . 12
8. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . . . 14
10.2 Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
1. Introduction 1. Introduction
Conference applications often have shared resources such as the right Conference applications often have shared resources such as the right
to talk, input access to a limited-bandwidth video channel, or a to talk, input access to a limited-bandwidth video channel, or a
pointer or input focus in a shared application. pointer or input focus in a shared application.
In many cases, it is desirable to be able to control who can provide In many cases, it is desirable to be able to control who can provide
input (send/write/control, depending on the application) to the input (send/write/control, depending on the application) to the
shared resource. shared resource.
Floor control enables applications or users to gain safe and mutually Floor control enables applications or users to gain safe and mutually
exclusive or non-exclusive input access to the shared object or exclusive or non-exclusive input access to the shared object or
resource. The floor is an individual temporary access or resource. The floor is an individual temporary access or
manipulation permission for a specific shared resource (or group of manipulation permission for a specific shared resource (or group of
resources) [8]. resources) [7].
Floor control is an optional feature for conferencing applications. Floor control is an optional feature for conferencing applications.
SIP [2] conferencing applications may also decide not to support this SIP [2] conferencing applications may also decide not to support this
feature at all. Two-party applications may use floor control outside feature at all. Two-party applications may use floor control outside
conferencing, although the usefulness of this kind of scenario is conferencing, although the usefulness of this kind of scenario is
limited. Floor control may be used together with conference policy limited. Floor control may be used together with conference policy
control protocol (CPCP) [9], or it may be used as independent control protocol (CPCP) [8], or it may be used as independent
standalone protocol, e.g. with SIP but without CPCP. standalone protocol, e.g. with SIP but without CPCP.
Floor control has been studied extensively over the years, (e.g. Floor control has been studied extensively over the years, (e.g.
[10], [8], [7]) therefore earlier work can be leveraged here. [9], [7], [6]) therefore earlier work can be leveraged here.
The present document describes the requirements for a floor control The present document describes the requirements for a floor control
protocol. As a requirements specification, the document makes no protocol. As a requirements specification, the document makes no
assumptions about the later implementation of the respective assumptions about the later implementation of the respective
requirements as parts of one or more protocols and about the entities requirements as parts of one or more protocols and about the entities
implementing it/them and their roles. implementing it/them and their roles.
This document may be used in conjunction with other documents, such This document may be used in conjunction with other documents, such
as the Conferencing framework document [3]. In particular, when as the Conferencing framework document [3]. In particular, when
speaking about a floor control server, this entity may be identical speaking about a floor control server, this entity may be identical
skipping to change at page 8, line 5 skipping to change at page 7, line 39
to the conference policy. to the conference policy.
A floor control server is a separate logical entity, typically A floor control server is a separate logical entity, typically
co-located with focus and/or conference policy server. Therefore, co-located with focus and/or conference policy server. Therefore,
the floor control server can interact with focus, conference Policy the floor control server can interact with focus, conference Policy
Server and media servers as needed. Communication mechanisms between Server and media servers as needed. Communication mechanisms between
floor control server and other central conferencing entities are not floor control server and other central conferencing entities are not
within the scope of the floor control protocol requirements described within the scope of the floor control protocol requirements described
in this document. in this document.
Conferences may be cascaded and hence a single participant in one
conference representing a second conference (called subconference).
From a floor control perspective there is no difference between a
participant (identified by its URI) representing a single person or
another (set of) subconference(s).
Note: In the latter case, it is the responsibility of the
subconference to internally negotiate floor requests before passing
on a request to the conference and to internally assign a floor upon
receiving a floor grant. This may be done recursively by employing
the floor control protocol with a different floor control server in
the subconference.
6. Assumptions about a Conference Policy 6. Assumptions about a Conference Policy
The floor control protocol is supposed to be used to manage access to The floor control protocol is supposed to be used to manage access to
shared resources in the context of a conference. It is up to this shared resources in the context of a conference. It is up to this
conference -- more precisely: its conference policy [4] -- to define conference -- more precisely: its conference policy [4] -- to define
the rules for the operation of the floor control protocol. the rules for the operation of the floor control protocol.
Furthermore, a conference policy control protocol [4] may define Furthermore, a conference policy control protocol [4] may define
mechanisms to alter those rules during the course of a conference. mechanisms to alter those rules during the course of a conference.
This section briefly outlines the assumptions made by a floor control This section briefly outlines the assumptions made by a floor control
protocol about the conference policy and means for its modification. protocol about the conference policy and means for its modification.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
REQ-GEN-4: It MUST be possible for the participants and chairs to REQ-GEN-4: It MUST be possible for the participants and chairs to
authenticate the server. authenticate the server.
REQ-GEN-5: It MUST be possible to ensure message integrity between REQ-GEN-5: It MUST be possible to ensure message integrity between
participants and chairs and the floor control server. participants and chairs and the floor control server.
REQ-GEN-6: It MUST be possible to ensure privacy of messages REQ-GEN-6: It MUST be possible to ensure privacy of messages
exchanged between participants and chairs and the floor control exchanged between participants and chairs and the floor control
server. server.
8. Open Issue 8. Acknowledgements
Conferences can be cascaded, such that a participant of the
conference can be a conference in its own right. What implications
(if any) does this have on floor control and the requirements on a
floor control protocol?
9. Acknowledgements
The authors would like to thank IETF conferencing design team and The authors would like to thank IETF conferencing design team and
Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen,
and Nermeen Ismail for their feedback. and Nermeen Ismail for their feedback.
10. References 9. References
10.1 Normative References 9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997. Levels", RFC 2119, BCD 14, March 1997.
[2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC
3261, June 2002. 3261, June 2002.
[3] Rosenberg, J., "A Framework for Conferencing with the Session [3] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02.txt (work in draft-ietf-sipping-conferencing-framework-02.txt (work in
progress), June 2004. progress), June 2004.
10.2 Informative References 9.2 Informative References
[4] Koskelainen, P. and H. Khartabil, "Additional Requirements to [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to
Conferencing", January 2004. Conferencing", August 2004.
[5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and
SOAP for conference floor control", January 2003.
[6] Camarillo, G., Ott, J. and K. Drage, "", June 2004. [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP
for conference floor control", January 2003.
[7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based [6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based
conference control framework", Nossdav'2002 Miami Beach, May conference control framework", Nossdav'2002 Miami Beach, May
2002. 2002.
[8] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for [7] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for
activity coordination in networked multimedia applications", activity coordination in networked multimedia applications",
Proc. of 2nd Asian-pacific Conference on Communications APPC, Proc. of 2nd Asian-pacific Conference on Communications APPC,
Osaka Japan, June 1995. Osaka Japan, June 1995.
[9] Koskelainen, P. and H. Khartabil, "An Extensible Markup [8] Koskelainen, P., Khartabil, H. and A. Niemi, "The Conference
Language (XML) Configuration Access Protocol (XCAP) Usage for Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01.txt
Conference Policy Manipulation", (work in progress), October 2004.
draft-koskelainen-xcon-xcap-cpcp-usage-02.txt (work in
progress), February 2004.
[10] Borman, C., Kutscher, D., Ott, J. and D. Trossen, "Simple [9] Borman, C., Kutscher, D., Ott, J. and D. Trossen, "Simple
conference control protocol service specification", conference control protocol service specification",
draft-ietf-mmusic-sccp-00.txt (work in progress), March 2001. draft-ietf-mmusic-sccp-00.txt (work in progress), March 2001.
Authors' Addresses Authors' Addresses
Petri Koskelainen Petri Koskelainen
Nokia Nokia
P.O. Box 100 (Visiokatu 1) 5 Wayside Road
Tampere FIN-33721 Burlington 01803
Finland USA
EMail: petri.koskelainen@nokia.com EMail: petri.koskelainen@nokia.com
Joerg Ott Joerg Ott
Uni Bremen TZI Uni Bremen TZI
Bibliothekstr. 1 Bibliothekstr. 1
Bremen D-28359 Bremen D-28359
Germany Germany
EMail: jo@tzi.uni-bremen.de EMail: jo@tzi.uni-bremen.de
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/