Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation
Expires: September 1, 2007 M. Barnes
Nortel
February 28, 2007
A Universal Resource Identifier (URI) for Centralized Conferencing
(XCON)
draft-boulton-xcon-uri-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 Uniform Resource Identifier (URI) is defined as a compact string of
characters for identifying an abstract or physical resource. This
document defines a URI scheme and syntax for the conference object
identifier, as defined in "A Framework and Data Model for Centralized
Conferencing".
Boulton & Barnes Expires September 1, 2007 [Page 1]
Internet-Draft XCON URI February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Conference URI Mapping Examples . . . . . . . . . . . . . . . 6
5. Conference URI Definition . . . . . . . . . . . . . . . . . . 8
6. Conference Object Identifier Creation and Distribution . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Boulton & Barnes Expires September 1, 2007 [Page 2]
Internet-Draft XCON URI February 2007
1. Introduction
A Uniform Resource Identifier (URI) is defined as a compact string of
characters for identifying an abstract or physical resource. This
document defines a URI scheme and syntax for the conference object
identifier, as defined in "A Framework and Data Model for Centralized
Conferencing" [3]
A Conference Object, defined in [3], provides the data representation
of a conference instance during its varying life-cycle stages. A
conference object is unique within a conferencing system and requires
a mechanism for identifying and associating varying components/
interfaces that construct and manipulate a conference instance. The
XCON-URI scheme defined in this document provides a unique top-level
conference object identifier that provides such functionality. The
conference object identifier can then be used by the conferencing
system and related protocols to gain access and reference a specific
conference object (for example, used by a Conference Control
Protocol). It is expected that a Conference Object may be accessed
by a number of future mechanisms.
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
The conference object identifier can be viewed as a key to accessing
a specific conference object. It is used by the conference control
protocol as described in [TBD] to access, manipulate and delete a
conference object. A conference object identifier is provided to the
conferencing client to enable such functions to be carried out. This
can either be returned through the conference control protocol while
creating a conference object, be provided by the conference
notification service or through out-of-band mechanisms (e.g.
E-Mail).
A centralized conferencing system, as defined in "A Framework and
Data Model for Centralized Conferencing" [3], has potential to expose
a range of interfaces and protocols. It is also possible that future
Boulton & Barnes Expires September 1, 2007 [Page 3]
Internet-Draft XCON URI February 2007
additions to the centralized conferencing framework might place
requirements to provide further additional protocols and interfaces.
A conference object can consist and be associated with many
identifiers that are in some way related to a conference object.
Good examples incude the Binary Floor Control Protocol (BFCP)[4] and
call signaling protocols, such as SIP. Each of these protocols use a
unique identifier to represent a protocol instance associated with a
conference object.
A conferencing system may maintain a relationship between the
conference object identifiers and the identifiers associated with
each of the complimentary centralized conferencing protocols (e.g.,
call signaling protocols, BFCP, etc.). To facilitate the maintenance
of these relationships, the conference object identifier acts as a
top level identifier within the conferencing system for the purpose
of identifying the interfaces for these other protocols. This
implicit binding provides a structured mapping of the various
protocols with the associated conference object Identifier. Figure 1
illustrates the relationship between the identifiers used for the
protocols within this framework and the general conference object
identifier.
+--------------+
| Conference |
| Object |
| Identifier |
+------+-------+
|
|
|
+-----------------+---------------+
| |
+-------+---------+ +-------+-------+
|CSP Conference ID| | BFCP 'confid' |
+-----------------+ +---------------+
Figure 1: Conference Object Mapping.
In Figure 1, the conference object identifier acts as the top level
key in the identification process. The call signaling protocols have
an associated conference user identifier, often represented in the
form of URIs. The binary floor control protocol, as defined in [5],
defines the 'conf-id' identifier which represents a conference
instance within floor control. When created within the conferencing
system, the 'conf-id' has a 1:1 mapping to the unique conference
object Identifier. Operations associated with the conference control
Boulton & Barnes Expires September 1, 2007 [Page 4]
Internet-Draft XCON URI February 2007
protocols are directly associated with the conference object, thus
the primary identifier associated with these protocols is the
conference object identifier. The mappings between additional
protocols/interface is not strictly 1:1 and does allow for multiple
occurrences. For example, multiple call signaling protocols will
each have a representation that is implicitly linked to the top level
conference object identifier e.g. H323 and SIP URIs that represent a
conference instance. 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.
The following example illustrates the representation and
relationships that might occur in a typical conference instance. The
table in Figure 2 lists a typical conference instance and related
properties.
+------------------------+------------------------+------------------------+
| Conf Obj URI | CSP URI | BFCP Conf-ID |
+------------------------+------------------------+------------------------+
| xcon:Ji092i | sip:Ji092i@example.com | Ji092i |
| | tel:+44(0)2920930033 | |
| | h323:Ji092i@example.com| |
+------------------------+------------------------+------------------------+
Figure 2: Conference Table Representation
The information from Figure 2 can then be applied to the
representation introduced in Figure 1. This results in Figure 3.
Boulton & Barnes Expires September 1, 2007 [Page 5]
Internet-Draft XCON URI February 2007
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
| xcon:Ji092i |
+------+-------+
|
|
|
+-----------------+---------------+
| |
+-----------+-----------+ +-------+-------+
| CSP Conference IDs | | BFCP 'confid' |
+-----------------------+ +---------------+
|h323:Ji092i@example.com| | Ji092i |
|tel:+44(0)2920930033 | +-------+-------+
|sip:Ji092i@example.com | |
+-----------------------+ +-------|-------+
| BFCP 'floorid |
+---------------+
| UEK78d |
| 09cnJk |
+---------------+
Figure 3: Conference Tree Representation
Further elements can be added to the tree representation in Figure 3
to enable a complete representation of a conference instance within a
conferencing system.
This style of association can be applied to any supplementary
mechanisms that are applied to the centralized conferencing model
defined in this document as long as a unique reference per conference
instance is available that can be mapped to a conference object.
4. Conference URI Mapping Examples
As mentioned in the previous section, it is possible, although not
required, to map an 'xcon' URI from this specification for multiple
usages. Identification of a conference instance within related
protocols can be derived from the appropriate 'xcon' URI. It is
expected that any future additions to centralized conferencing will
make use of the mappings provided in this section.
Boulton & Barnes Expires September 1, 2007 [Page 6]
Internet-Draft XCON URI February 2007
A basic XCON URI looks as follows:
xcon:83Hd79qhjsd@example.com
The left hand side of the URI (to the left of the '@') represents the
unique token. This token can be used by any protocol wishing to gain
access to functionality associated with a specific conference object.
For example, when used to construct a SIP INVITE request, the token
would be used to populate the 'user' part of the SIP URI - as defined
in RFC 3261[2]. The right hand side of the URI, as with any URI,
provides domain level information ('example.com' in previous
example). So continuing the previous example, the SIP URI domain
part would be equal to this domain information. This would result in
the following SIP URI that would enable a request to be sent to the
conference instance (to join) at a conferencing system:
sip:83Hd79qhjsd@example.com
Another example would be the mapping of the previous 'xcon' URI for
the purpose of BFCP. Again, the previously described 'left side' of
the URI would be extracted and used as the 'confid' defined in [5]
the 'right side' of the URI provides the required connection
information to construct a BFCP connection. The hostname can be used
to provide either a an IP address or use DNS resolution to provide a
connection location (and optionally port). A port can be explicitly
defined if required.
The syntax defined in Section 5 also allows additional URI parameters
to be defined. This specification does not define any parameters or
usages but future documentation MAY require additional functionality.
All unknown parameters SHOULD be ignored when used for mapping
purposes but MAY be included if specifically documented.
It should be highlighted that the examples provided in this section
are not normative and some implementations might find that such
strict mapping is not necessary. The information is maintained as
defined in the XCON data model and it is up to the conferencing
system to implement a mechanism to logically associate the Conference
URI with the signaling protocol specific URIs associated with a
conference.
Boulton & Barnes Expires September 1, 2007 [Page 7]
Internet-Draft XCON URI February 2007
5. Conference URI Definition
XCON-URI = "xcon" "://" [conf-object-id "@"] hostport
*( ";" url-parameter)
; hostport as defined in RFC3261
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
url-parameter = token ["=" token]
6. Conference Object Identifier Creation and Distribution
The Conference Object Identifier is created both by the conferencing
system based on internal actions as well as based on specific
conference protocol requests. As discussed in the centralized
conference framework, there is a unique conference object identifier
associated with each conference object. Thus, a conferencing system
will allocate a conferencing object identifier for every conference
blueprint, for every conference reservation and for every active
conference. The distribution of the conference object identifier
depends upon the specific use case and includes a variety of
mechanisms, such as the through the conference control protocol
mechanism, the data model and conference package or out of band
mechanisms such as E-Mail.
The conference object identifier MUST be included in any conference
control protocol request associated with a conference reservation or
active conference. When a user wishes to create or join a conference
and the user does not have the conference object identifier for the
specific conference, more general signaling mechanisms apply, such
that a user may have a pre-configured conference object identifier to
access the conferencing system or other signaling protocols may be
used and the conferencing system maps those to a specific conference
object identifier. Once a conference is established, a conference
object identifier is required for the user to manipulate any of the
conferencing data or take advantage of any of the advanced
conferencing features. The same notion applies to users joining a
conference using other signaling protocols. They are able to
initially join a conference using any of the other signaling
protocols supported by the specific conferencing system, but the
conference object identifer MUST be used to manipulate any of the
conferencing data or take advantage of any of the advanced
conferencing features. As mentioned previously, the mechanism by
which the user learns of the conference object identifier varies and
could be via the conference control protocol, using the data model
Boulton & Barnes Expires September 1, 2007 [Page 8]
Internet-Draft XCON URI February 2007
and conference packager or entirely out of band such as E-Mail or a
web interface.
7. Security Considerations
The security considerations for the conference object URI are related
to those identifed in the centralized conferencing framework.
Through conference control protocol signaling, the conference object
URI is used to access the data associated with a specific conference
within a conferencing system. Using the conference object URI and
the signaling protocol, a user can perform perform actions on the
conferencing system to invoke specific capabilities. The
implementation must ensure that only authorized entities are able to
manipulate the data to access the capabilities.
8. IANA Considerations
To be completed.
9. 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,
Srivatsa Srinivasan and Lorenzo Miniero for their feeback on this
document.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.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.
Boulton & Barnes Expires September 1, 2007 [Page 9]
Internet-Draft XCON URI February 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.
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 10]
Internet-Draft XCON URI 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 11]