One document matched: draft-boulton-xcon-userid-01.txt
Differences from draft-boulton-xcon-userid-00.txt
Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation
Expires: September 1, 2007 M. Barnes
Nortel
February 28, 2007
A User Identifier for Centralized Conferencing (XCON)
draft-boulton-xcon-userid-01
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 September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
A conferencing system is defined by "A framework and Data Model for
Centralized Conferencing" and represents a container for
administering and managing all conference related information. The
conference user concept is introduced in the framework to identify
the entity participating in a conference and manipulating
conferencing system related properties. This document defines a
Conference User Identifier and provides some guidelines for
Boulton & Barnes Expires September 1, 2007 [Page 1]
Internet-Draft XCON User ID February 2007
identifying a specific conference user within a conferencing system.
The document also provides some examples of the logical mapping of
this conference user identifier to protocol and signaling interface
specific user identifiers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Conference User Identifier Mapping Examples . . . . . . . . . . 5
5. Conference User Identifier Guidelines . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Boulton & Barnes Expires September 1, 2007 [Page 2]
Internet-Draft XCON User ID February 2007
1. Introduction
This document defines a user identifier for a conference user within
a conferencing system. A conferencing system is defined by "A
framework and Data Model for Centralized Conferencing" [3] and
represents a container for administering and managing all related
information ranging from conference policy to conference instance
management. Within a conferencing system, a conference user
identifies the entity participating in a conference and attempting to
manipulate conferencing system related properties.
A centralized conference as defined in [3] is both signaling and
protocol agnostic. However, users interface with the conferencing
system using specific protocol and signaling interfaces. Each of
these protocols/interfaces often define their own user identifier,
which provides a contextual representation of who exactly is
associated with a specific protocol or signaling interface.
This document provides a top level common user identifier to
associate these related protocol and interface user identifiers. It
also provides guidelines on how this conferencing system wide user
identifier can be used to derive a protocol or interface specific
user. The centralised user management allows for control over
uniqueness within a system. It also aids in the creation and
management of conferencing system wide policies.
2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [1] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant
implementations.
This document uses the terminology defined in [3].
3. Overview
Each user within a conferencing system is allocated a unique
Conference User Identifier. The conference user identifier is used
in association with the conference object identifier defined in [6]
and by the conference control protocol to uniquely identify a
conference user within the scope of a conferencing system. The
conference control protocol uses the conference user identifier to
uniquely determine who is issuing commands. Appropriate policies can
then be applied to the requested command.
Boulton & Barnes Expires September 1, 2007 [Page 3]
Internet-Draft XCON User ID February 2007
As with the conference object identifier, a number of supplementary
user identifiers defined in other protocols are used within a
conference instance. Such user identifiers can be associated with
this conference user identifier and enable the conferencing system to
correlate and map these multiple authenticated user identities to a
single global user identifier. This document defines no explicit
syntax or strict mapping mechanism for the conference user identier,
but rather provides some guidelines and examples that illustrate the
required logical association between the various user identifiers.
Figure 1 illustrates an example using the conference user identifier
in association with the user identity defined for BFCP and SIP Digest
user identity as defined in RFC3261[2], which would be used when SIP
is the call signaling protocol. It should be noted that a
conferencing system is free to structure such relationships as
required and this information is just included as a guideline that
can be used.
+---------------+
| Conference |
| User |
| Identifier |
+-------+-------+
|
|
|
+---------------+---------------+
| |
+-------+-------+ +-------+-------+
| BFCP | | SIP Digest |
| 'UserID' | | Username |
+---------------+ +-------+-------+
Figure 1: Conference User Identifier
Within a conferencing system, a user is identified by a single
conference user identifier. Any additional conferencing mechanisms
that contain a protocol specific user ID can be associated with the
conference user identifier, as illustrated in Figure 1. This
mechanism allows conferencing systems to manage and relate system
wide user identities in relation to specific conference objects and
helps in the enforcement of system wide policies.
Boulton & Barnes Expires September 1, 2007 [Page 4]
Internet-Draft XCON User ID February 2007
4. Conference User Identifier Mapping Examples
The section provides some more detailed examples of the mapping of
conferencing user identifier to the various signaling protocol user
identifiers.
The following example illustrates the representation and
relationships that might occur in a typical conference instance. The
table in Figure 2 lists a typical representation of User Identity
hierarchy and association.
+-------------------+-------------------+------------------+-------------------+
| Conf User ID | BFCP User ID | SIP User ID | H323 User ID |
+-------------------+-------------------+------------------+-------------------+
| John | HK37ihdaj | 123674 | 928373 |
+-------------------+-------------------+------------------+-------------------+
Figure 2: User Identity Representation
The information from Figure 2 can then be applied to the
representation introduced in Figure 1. This results in Figure 3.
+--------------+
| Conference |
| User |
| Identifier |
+--------------+
| John |
+------+-------+
|
|
|
+---------------------+---------------------+
| | |
+-------+--------+ +-------+-------+ +--------+-------+
| BFCP User ID | | SIP User ID | | H323 User ID |
+----------------+ +---------------+ +----------------+
| HK37ihdaj | | 123674 | | 928373 |
+----------------+ +-------+-------+ +----------------+
Figure 3: User ID Tree Representation
Further elements can be added to the tree representation in Figure 3
Boulton & Barnes Expires September 1, 2007 [Page 5]
Internet-Draft XCON User ID February 2007
to enable a complete representation of a conference instance within a
conferencing system.
If a conferencing system can guarantee that user identities for
varying protocols can use one unique identifier across the whole
system then this type of mechanism is not required. Some systems
require more complex user identity association. For example, a SIP
User dialing into a Conference might enter using a PIN code using
DTMF. The PIN code would then be used to uniquely identify the
conference user within the conferencing system.
5. Conference User Identifier Guidelines
The conference user identifier is reflected in the XCON data model
[7] by the <user> entity. It is RECOMMENDED that a display name
field be included as part of the identifer to support non-English
display names.
A typical mode for distributing the user identifer is out of band
during conferencing client configuration, thus the mechanism is
outside the scope of the centralized conferencing framework and
protocols. However, a conferencing system MUST also be capable of
allocating and distributing a user identifier during the first
signaling interaction with the conferencing system, such as an
initial request for blueprints or adding a new user to an existing
conference using the conference control protocol. When a user joins
a conference using a signaling specific protocol, such as SIP for a
dial-in conference, a conference user identifier MUST be assigned if
one is not already associated with that user. While this conference
user identifier isn't required for the participant to join the
conference, it is required to be allocated and assigned by the
conferencing system such that it is available for use for any
subsequent conference control protocol operations and/or
notifications associated with that conference. For example, the
conference user identifer would be sent in any notifications that may
be sent to existing participants, such as the moderator, when this
user joins.
This document proposes no strict guidelines for mapping between the
Conference User Identifier and other signaling protocol specific user
identifiers.
6. Security Considerations
As discussed in the centralized conferencing framework, there are a
wide variety of potential attacks related to conferencing, due to the
Boulton & Barnes Expires September 1, 2007 [Page 6]
Internet-Draft XCON User ID February 2007
natural involvement of multiple endpoints and the many, often user-
invoked, capabilities provided by the conferencing system. As
discussed in the centralized conferencing framework, the security
associated with conference control protocol MUST provide mechanisms
for confidentiality and integrity of the protocol messages.
The primary area of concern related to the conference user identifier
would be around the security and privacy of the identity that is
associated with the conference user identifier. The conferencing
system has an idea of the identity of a user but it SHOULD be
revealed only to authorized parties, due to privacy considerations.
7. Acknowledgments
This document was initially created from content based upon details
in the XCON FW document that were deemed out of scope for a framework
document. The authors would like to thank Oscar Novo, Roni Even and
Srivatsa Srinivasan for their feeback on this document.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-07 (work in progress),
January 2007.
[4] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006.
[5] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006.
[6] Boulton, C. and M. Barnes, "A Universal Resource Identifier
(URI) for Centralized Conferencing (XCON)",
draft-boulton-xcon-uri-00 (work in progress), October 2006.
Boulton & Barnes Expires September 1, 2007 [Page 7]
Internet-Draft XCON User ID February 2007
[7] Novo, O., "A Common Conference Information Data Model for
Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-03 (work in progress),
October 2006.
Authors' Addresses
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com
Mary Barnes
Nortel
2201 Lakeside Blvd
Richardson, TX
Email: mary.barnes@nortel.com
Boulton & Barnes Expires September 1, 2007 [Page 8]
Internet-Draft XCON User ID February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Boulton & Barnes Expires September 1, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:33 |