XCON H. Khartabil Internet-Draft A. Niemi Expires: April 12, 2005 Nokia October 12, 2004 Privileges for Manipulating a Conference Policy draft-ietf-xcon-conference-policy-privileges-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The Conference Policy is defined as the complete set of rules for a particular conference manipulated by the conference policy server. The Conferece Policy Control Protocol (CPCP) is the protocol used by client to manipulate the conference policy. This document specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy meta data that enable a user to assign privileges to users that enables them to read and/or manipulate parts of or the Khartabil & Niemi Expires April 12, 2005 [Page 1] Internet-Draft CPCP-Privileges October 2004 entire conference policy. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Structure of a Conference Policy Privileges XML Document . . . 4 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4 4.2 Privileges Root . . . . . . . . . . . . . . . . . . . . . 5 4.3 XML Document Description . . . . . . . . . . . . . . . . . 5 4.3.1 Conference Policy Privileges . . . . . . . . . . . . . 5 4.3.1.1 Conditions . . . . . . . . . . . . . . . . . . . . 6 4.3.1.1.1 Validity . . . . . . . . . . . . . . . . . . . 6 4.3.1.1.2 Identity . . . . . . . . . . . . . . . . . . . 7 4.3.1.1.2.1 Interpreting the Element . . . . . . 8 4.3.1.1.3 Conference Policy Identity . . . . . . . . . . 8 4.3.1.1.3.1 Matching Any Identity . . . . . . . . . . 8 4.3.1.1.3.2 Matching Identities in External Lists . . 8 4.3.1.1.4 Sphere . . . . . . . . . . . . . . . . . . . . 8 4.3.1.2 Actions . . . . . . . . . . . . . . . . . . . . . 8 4.3.1.2.1 Modifying Conference setting . . . . . . . . . 8 4.3.1.2.2 Modifying Conference Information . . . . . . . 9 4.3.1.2.3 Modifying Conference Time . . . . . . . . . . 9 4.3.1.2.4 Modifying Authorization rules . . . . . . . . 9 4.3.1.2.5 Modifying Conference Dial-out List . . . . . . 9 4.3.1.2.6 Modifying Conference Refer List . . . . . . . 9 4.3.1.2.7 Modifying Conference media streams . . . . . . 10 4.3.1.2.8 Creating Sidebars . . . . . . . . . . . . . . 10 4.3.1.2.9 Modifying Conference Dial-in List . . . . . . 10 4.3.1.2.10 Reading Conference setting . . . . . . . . . . 10 4.3.1.2.11 Reading Conference Information . . . . . . . . 11 4.3.1.2.12 Reading Conference Time . . . . . . . . . . . 11 4.3.1.2.13 Reading Authorization rules . . . . . . . . . 11 4.3.1.2.14 Reading Conference Dial-out List . . . . . . . 11 4.3.1.2.15 REading Conference Refer List . . . . . . . . 11 4.3.1.2.16 Reading Conference media streams Information . . . . . . . . . . . . . . . . . 12 4.3.1.2.17 Reading Sidebar Information . . . . . . . . . 12 4.3.1.2.18 Reading Conference Dial-in List . . . . . . . 12 4.3.1.3 Transformations . . . . . . . . . . . . . . . . . 12 4.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 A Simple Conference Policy Privileges Document . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1 application/privileges+xml MIME TYPE . . . . . . . . . . . 15 7.2 URN Sub-Namespace Registration for Khartabil & Niemi Expires April 12, 2005 [Page 2] Internet-Draft CPCP-Privileges October 2004 urn:ietf:params:xml:ns:privileges . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Khartabil & Niemi Expires April 12, 2005 [Page 3] Internet-Draft CPCP-Privileges October 2004 1. Introduction The Conference Policy Control Protocol (CPCP) [1]specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy data elements that enable a user to define a conference policy. It, however, does not define user privileges (who is allowed to read or modify certain parts or all of a conference policy). In many cases, the creator of the conference policy is the sole user with access rights to the conference policy and other users do not have any rights to view nor modify the document. However, there is a need for different privileges to exist where users can modify certain parts of the conference policy XML document. This document specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy meta data that enable such privileges to exist. 2. Conventions Used in This Document 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 [3]. 3. Terminology This document uses terminology from [13]. Some additional definitions are introduced in [1], including the defintion of a privileged user. 4. Structure of a Conference Policy Privileges XML Document The conference policy privileges document is an XML [4] document that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. The Conference policy privelges documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying conference policy privileges documents and document fragments. The namespace URI for elements defined by this specification is a URN [6], using the namespace identifier 'ietf' defined by [7] and extended by [8]. This URN is: urn:ietf:params:xml:ns:privileges 4.1 MIME Type for CPCP XML Document The MIME type for the CPCP XML document is Khartabil & Niemi Expires April 12, 2005 [Page 4] Internet-Draft CPCP-Privileges October 2004 "application/privileges+xml". 4.2 Privileges Root A conference policy privileges document begins with the root element tag . Other elements from different namespaces MAY be present for the purposes of extensibility. Elements or attributes from unknown namespaces MUST be ignored. A user may create a new conference policy privieleges at the CPS by placing a new conference policy document at the CPS. Depending on server policy and user privileges, the CPS may accept the creation. Only the creator of the conference can create a conference policy privileges document for that conference policy. A conference that exists without a conference policy privileges document allows all privileges to the creator of the conference policy only. A conference policy privielges document can be deleted permanently by removing the conference policy document from the CPS. When the user deletes a conference policy document, the user SHOULD also delete the conference policy privielges document associated with the deleted conference. A CPS may apply local policy in determining when and if to delete the conference policy privielges document if it has not been removed after a the conference policy document was deleted. 4.3 XML Document Description 4.3.1 Conference Policy Privileges One of the key components of the conference policy privileges document is the set of authorization rules that specify who is allowed to read and manipulate a conference policy. The unordered list of authorization rules together define the conference policy privileges in the form of an authorization policy. The element appears after the root element and contains the URI of the conference policy document that the privileges defines within it apply to. This is followed by the element which carry the rules defining the actual privileges. The conference policy privileges are enclosed in the element are formatted according to the XML schema defined in the common policy framework [2]. In the element, there can be multiple rules, each rule is represented by the element, each of which consist of three parts: conditions, actions and transformations. Conditions determine whether a particular rule applies to a request. Each action or transformation in the applied Khartabil & Niemi Expires April 12, 2005 [Page 5] Internet-Draft CPCP-Privileges October 2004 rule is a positive grant of permission to the conference policy user. The details of each specific element and attribute is described in [2]. Asking the conference policy server to allow certain users to manipulate the conference policy is achieved by modifying an existing authorization rule or creating a new one. If the conference is long-lasting, it is possible that new rules are added all the time but old rules are almost never removed (some of them are overwritten, though). This leads easily to the situation that the conference policy meta data contains many unnecessary rules which are not really needed anymore. Therefore, there is a need to delete rules. This can be achieved by removing that portion of the policy. Conflicting rules may exist (for example, both allowed and blocked action is defined for same target). The common policy directives [2] dictate the behaviour in such situations. This section outlines the new conditions, actions and transformations for conference policy privileges. 4.3.1.1 Conditions 4.3.1.1.1 Validity The element, as defined in the common policy framework [2], expresses the rule validity period by two attributes, a starting and a ending time. Times are expressed in XML dateTime format. Expressing the lifetime of a rule implements a garbage collection mechanism. A rule maker might not have always access to the conference policy server to remove some rules which grant permissions. Hence this mechanisms allows to remove or invalidate granted permissions automatically without further interaction between the rule maker and the conference policy server. To give a real life example, there are often meetings where users can have access to modify the dial-out list from 10 minutes before the conference starts until 10 mintues after the conference starts. One rules can be set in this scenario. The following example demostrates this. The meeting starts at 9:30 and ends at 12:30. A manager with identity "manager@example.com" can read and modify the dial-out list betweem 8:50 and 9:40. After that time until the conference ends, the manager can only read the dial-out-list Khartabil & Niemi Expires April 12, 2005 [Page 6] Internet-Draft CPCP-Privileges October 2004 2004-12-17T08:50:00-05:00 2004-12-17T09:40:00-05:00 manager@example.com allow manager@example.com allow ... 4.3.1.1.2 Identity The element is already defined in the common policy framework [2]The presence of the element is a condition requires any identity within it to be authenticated before a rule is applied to it. This includes the element (Section 4.3.1.1.2.1), the element (Section 4.3.1.1.3.1), the element (Section 4.3.1.1.3.2), their exceptions, and any future extension that carries an identity. The absence of the element with in a condition indicated that the rule applies to all unauthenticated Khartabil & Niemi Expires April 12, 2005 [Page 7] Internet-Draft CPCP-Privileges October 2004 identities. That is participants that have provided no authenticated identity to the conference focus. 4.3.1.1.2.1 Interpreting the Element As earlier indicated, the element is already defined in the common policy framework [2]. However, the rules for interpreting the identities in elements are left for each application to define separately. This document, however, does not define the rules for interpreting identities in elements in conferencing applications since those interpretation rules are signalling protocol specific. OPEN ISSUE: Do we need to state more than this? How are identities derived from users that join using POTS, H.323, etc.? 4.3.1.1.3 Conference Policy Identity 4.3.1.1.3.1 Matching Any Identity The element is used to match any participant. This allows a conference priveleges to be open to any authenticated user. Just as for the element in element, The element contains a list of elements and allows to implement a simple blacklist mechanism. The element contains the identity. It differs from the element in that the domain part is needed in the identity since it has not domain to refer to. 4.3.1.1.3.2 Matching Identities in External Lists The element can be used to match those participants that are part of a resource list that is created externally. The use of is similar to that defined in Section x of [1]. 4.3.1.1.4 Sphere The element has no meaning in the context of conference policy and MUST be ignored if present. 4.3.1.2 Actions 4.3.1.2.1 Modifying Conference setting The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference settings in the conference policy. If set to FALSE, any modifications to the conference settings are rejected. Khartabil & Niemi Expires April 12, 2005 [Page 8] If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.2 Modifying Conference Information The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference information in the conference policy. If set to FALSE, any modifications to the conference information are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.3 Modifying Conference Time The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference time in the conference policy. If set to FALSE, any modifications to the conference time are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.4 Modifying Authorization rules The element represents a boolean action. If set to TRUE, the identity is allowed to modify the authorization rules of a conference in the conference policy. If set to FALSE, any modifications to the rules are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.5 Modifying Conference Dial-out List The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference dial-out list in the conference policy. If set to FALSE, any modifications to the dial-out list are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.6 Modifying Conference Refer List The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference refer list in the conference policy. If set to FALSE, any modifications to the refer list are rejected. Khartabil & Niemi Expires April 12, 2005 [Page 9] Internet-Draft CPCP-Privileges October 2004 If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.7 Modifying Conference media streams The element represents a boolean action. If set to TRUE, the identity is allowed to modify the conference media streams in the conference policy. If set to FALSE, any modifications to the media streams are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.8 Creating Sidebars The element represents a boolean action. If set to TRUE, the identity is allowed to create and manipulate a sidebar by creating and modifying a element in a conference policy. If set to FALSE, any sidebar creation and manipulation is rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.9 Modifying Conference Dial-in List The conference dial-in list is virtual and is not represented by a physical list in the conference policy. It is rather a collection of authorization rules that allow users to join a conference. The element represents a boolean action. If set to TRUE, the identity is allowed to create an authorization rule in the conference policy that give a user a join handling of "allow". If set to FALSE, any modifications to authorization rules are rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.10 Reading Conference setting The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference settings in the conference policy. If set to FALSE, any attempts to read the conference settings are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. Khartabil & Niemi Expires April 12, 2005 [Page 10] Internet-Draft CPCP-Privileges October 2004 4.3.1.2.11 Reading Conference Information The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference information in the conference policy. If set to FALSE, any attempts to read the conference information are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.2.12 Reading Conference Time The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference time in the conference policy. If set to FALSE, any attempts to read the conference time are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.2.13 Reading Authorization rules The element represents a boolean action. If set to TRUE, the identity is allowed to read the authorization rules of a conference in the conference policy. If set to FALSE, any attempts to read the rules are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.2.14 Reading Conference Dial-out List The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference dial-out list in the conference policy. If set to FALSE, any attempts to read the dial-out list are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.2.15 REading Conference Refer List The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference refer list in the conference policy. If set to FALSE, any attempts to read the refer list are rejected. If this element is undefined it has a value of FALSE, causing the Khartabil & Niemi Expires April 12, 2005 [Page 11] Internet-Draft CPCP-Privileges October 2004 read requests to be rejected. 4.3.1.2.16 Reading Conference media streams Information The element represents a boolean action. If set to TRUE, the identity is allowed to read the conference media streams information in the conference policy. If set to FALSE, any attempts to read the media streams information are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.2.17 Reading Sidebar Information The element represents a boolean action. If set to TRUE, the identity is allowed to read side bar inforation in the conference policy, indicating how many sidebars are currently in a conference. If set to FALSE, any attempts to read sidebar information is rejected. If this element is undefined it has a value of FALSE, causing the modifications to be rejected. 4.3.1.2.18 Reading Conference Dial-in List The Dial-in List is defined in Section 4.3.1.2.9. If set to TRUE, the identity is allowed to read authorizations rule in the conference policy that give a user a join handling of "allow". If set to FALSE, any attempts to read such rules are rejected. If this element is undefined it has a value of FALSE, causing the read requests to be rejected. 4.3.1.3 Transformations No transformations are defined at this time. 4.4 XML Schema Khartabil & Niemi Expires April 12, 2005 [Page 12] Internet-Draft CPCP-Privileges October 2004 5. Examples Khartabil & Niemi Expires April 12, 2005 [Page 13] Internet-Draft CPCP-Privileges October 2004 5.1 A Simple Conference Policy Privileges Document The following document dictates that Bob and Alice are allowed to read and modify the conference settings at "http://xcap.example.com/services/conferences/users/Alice/conference. xml" why John can only read the dial-out list. http://xcap.example.com/services/conferences/users/Alice/conference.xml" bob@example.com alice@example.com true true john@example.com true 6. Security Considerations A conference policy privileges document may contain information that is highly sensitive. Its delivery to the conference server needs to Khartabil & Niemi Expires April 12, 2005 [Page 14] Internet-Draft CPCP-Privileges October 2004 happen strictly, paying special attention to integrity and confidentiality. Reading the document is also a security concern since the conference policy proviliges document contains sensitive information like who is allowed to modify certain parts of a conference policy document. A milicious user can manipulate parts of the conference policy privileges document giving themselves and others privileges to manipulate the conference policy, including the dial-out list and the ruleset. Those authorization rules carry the privileges that certain identities have. If an unauthorized user gets access to this document (pretending to be someone else), s/he can manipulate those rules giving himself and other unauthorized users access to the conference policy. Some of the things that a malicious user can do include: denying users certain privileges, removing rules for certain identities and giving privileges to other malicious users. Therefore, it is very important that only authorized clients are able to manipulate the conference policy privileges document. Any conference policy privileges document transport protocol MUST provide authentication, confidentiality and integrity. 7. IANA Considerations 7.1 application/privileges+xml MIME TYPE MIME media type: application MIME subtype name: privileges+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5]. Security considerations: See section 10 of RFC 3023 [5] and section Section 7 of this document. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to support conference policy manipulation for SIP based conferencing. Khartabil & Niemi Expires April 12, 2005 [Page 15] Internet-Draft CPCP-Privileges October 2004 Additional information: Magic number: None File extension: .cl or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Hisham Khartabil (hisham.khartabil@nokia.com) Intended Usage: COMMON Author/change controller: The IETF 7.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:privileges This section registers a new XML namespace, as per guidelines in URN document [8]. URI: The URI for this namespace is urn:ietf:params:xml:ns:privileges. Registrant Contact: IETF, XCON working group, Hisham Khartabil (hisham.khartabil@nokia.com) XML: BEGIN Conference Policy Namespace

Namespace for Conference Policy

application/conference-policy+xml

See RFCXXXX.

END Khartabil & Niemi Expires April 12, 2005 [Page 16] Internet-Draft CPCP-Privileges October 2004 8. Acknowledgements The authors would like to thank Hannes Tschofenig, Aki Niemi, Alan Johnston, and the IETF XCON working group for their feedback and suggestions. 9 Normative References [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference Policy Control Protocol (CPCP)", Internet-Draft I-D.draft-ietf-xcon-cpcp, September 2004. [2] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J. Rosenberg, "Common Policy", Internet-Draft I-D.ietf-geopriv-common-policy, February 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000. [5] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [6] Moats, R., "URN Syntax", RFC 2141, May 1997. [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [8] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [9] Koskelainen, P. and H. Khartabil, "Requirements for conference policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in progress), January 2004. [10] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-03 (work in progress), February 2004. [11] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02 (work in progress), February 2004. [12] Rosenberg, J., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", Khartabil & Niemi Expires April 12, 2005 [Page 17] Internet-Draft CPCP-Privileges October 2004 draft-ietf-simple-xcap-list-usage-02 (work in progress), February 2004. [13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003. [14] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Authors' Addresses Hisham Khartabil Nokia P.O. Box 321 Helsinki FIN-00045 Finland EMail: hisham.khartabil@nokia.com Aki Niemi Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Khartabil & Niemi Expires April 12, 2005 [Page 18] Internet-Draft CPCP-Privileges October 2004 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 (2004). 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. Khartabil & Niemi Expires April 12, 2005 [Page 19]