Network Working Group C. Boulton Internet-Draft Ubiquity Software Corporation Intended status: Informational M. Barnes Expires: April 16, 2007 Nortel October 13, 2006 A Universal Resource Identifier (URI) for Centralized Conferencing (XCON) draft-boulton-xcon-uri-00 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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 April 16, 2007 [Page 1] Internet-Draft XCON URI October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conference URI Definition . . . . . . . . . . . . . . . . . . 7 5. Conference Object Identifier Distribution . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Boulton & Barnes Expires April 16, 2007 [Page 2] Internet-Draft XCON URI October 2006 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. It is the intention of this document to also provide appropriate guidelines for mapping to future extensions. 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] and also defines the following additional terms: TODO : TODO. 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). Boulton & Barnes Expires April 16, 2007 [Page 3] Internet-Draft XCON URI October 2006 Editors Note: Part of the extension to the Conference Package for XCON? A centralized conferencing (XCON) system, as defined in the Conference Framework [3], has potential to expose a range of interfaces and protocols. It is also possible that future 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 include the Binary Floor Control Protocol (BFCP)[4] and call signaling protocols, such as SIP. Each use unique identifiers 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 Boulton & Barnes Expires April 16, 2007 [Page 4] Internet-Draft XCON URI October 2006 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 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 April 16, 2007 [Page 5] Internet-Draft XCON URI October 2006 +--------------+ | 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. 3.1. URI Mapping As mentioned in the previous section, it is possible 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 April 16, 2007 [Page 6] Internet-Draft XCON URI October 2006 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. [Editors Note: Describe mapping for Conference Control - TODO]. The syntax defined in Section 4 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. [Editors Note: This is currently for discussion. Strict mapping rules will be defined based on discussion]. 4. 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 Boulton & Barnes Expires April 16, 2007 [Page 7] Internet-Draft XCON URI October 2006 url-parameter = token ["=" token] 5. Conference Object Identifier Distribution The actual distribution of conference object identifiers is considered out of scope for this document. It is expected that they will be delivered to clients compliant to the centralized conferencing framework through a number of mechanisms. This could be through the conference control mechanism, the data model and conference package or out of band mechanisms such as E-Mail. 6. Security Considerations Security Considerations to be included in later versions of this document. 7. IANA Considerations 8. Acknowledgments TODO. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.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-05 (work in progress), September 2006. [4] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-06 (work in progress), December 2005. Boulton & Barnes Expires April 16, 2007 [Page 8] Internet-Draft XCON URI October 2006 [5] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-mmusic-sdp-bfcp-03 (work in progress), December 2005. 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 April 16, 2007 [Page 9] Internet-Draft XCON URI October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 April 16, 2007 [Page 10]