idnits 2.17.1
draft-ietf-xcon-cpcp-xcap-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 481.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
487), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 37.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 7 instances of too long lines in the document, the longest one
being 90 characters in excess of 72.
** There are 18 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 372 has weird spacing: '...ocument and i...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (September 9, 2004) is 7168 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Normative reference to a draft: ref. '1'
-- Possible downref: Normative reference to a draft: ref. '2'
-- No information found for draft-ietf-xcon-cpcp-req - is the name correct?
-- Possible downref: Normative reference to a draft: ref. '4'
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-cc-conferencing-03
== Outdated reference: A later version (-12) exists of
draft-ietf-simple-xcap-02
== Outdated reference: A later version (-05) exists of
draft-ietf-simple-xcap-list-usage-02
== Outdated reference: A later version (-05) exists of
draft-ietf-sipping-conferencing-framework-01
** Downref: Normative reference to an Informational draft:
draft-ietf-sipping-conferencing-framework (ref. '8')
** Obsolete normative reference: RFC 2617 (ref. '9') (Obsoleted by RFC
7235, RFC 7615, RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2818 (ref. '10') (Obsoleted by RFC
9110)
Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 XCON H. Khartabil
2 Internet-Draft Nokia
3 Expires: March 10, 2005 September 9, 2004
5 An Extensible Markup Language (XML) Configuration Access Protocol
6 (XCAP) Usages for Conference Policy Manipulation and Conference
7 Policy Privelges Manipulation
8 draft-ietf-xcon-cpcp-xcap-02
10 Status of this Memo
12 By submitting this Internet-Draft, I certify that any applicable
13 patent or other IPR claims of which I am aware have been disclosed,
14 and any of which I become aware will be disclosed, in accordance with
15 RFC 3668.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on March 10, 2005.
35 Copyright Notice
37 Copyright (C) The Internet Society (2004). All Rights Reserved.
39 Abstract
41 The Conference Policy is defined as the complete set of rules for a
42 particular conference manipulated by the conference policy server.
43 The Conferece Policy Control Protocol (CPCP) is the protocol used by
44 client to manipulate the conference policy. This document defines an
45 XML Configuration Access Protocol (XCAP) application usage that may
46 be used to store and manipulate a conference policy.
48 There also exists an Extensible Markup Language (XML) Schema that
49 enumerates the conference policy meta data that enable a user to
50 assign privileges to users that enables them to read and/or
51 manipulate parts of or the entirety of a conference policy. This
52 document defines an XML Configuration Access Protocol (XCAP)
53 application usage that may be used to store and manipulate a
54 conference policy priveleges XML document.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. An XCAP Usage for Conference Policy Manipulation . . . . . . . 4
62 4.1 Application Unique ID . . . . . . . . . . . . . . . . . . 4
63 4.2 Resource Interdependencies . . . . . . . . . . . . . . . . 4
64 4.3 Additional Constraints . . . . . . . . . . . . . . . . . . 4
65 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 4
66 4.5 Authorization Policies . . . . . . . . . . . . . . . . . . 4
67 4.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4
68 5. An XCAP Usage for Conference Policy Privileges Manipulation . 5
69 5.1 Application Unique ID . . . . . . . . . . . . . . . . . . 5
70 5.2 Resource Interdependencies . . . . . . . . . . . . . . . . 5
71 5.3 Additional Constraints . . . . . . . . . . . . . . . . . . 5
72 5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 5
73 5.5 Authorization Policies . . . . . . . . . . . . . . . . . . 5
74 5.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5
75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
76 6.1 Conference Policy Manipulation . . . . . . . . . . . . . . 5
77 6.1.1 Creating a Conference . . . . . . . . . . . . . . . . 5
78 6.1.2 Expelling a User . . . . . . . . . . . . . . . . . . . 6
79 6.1.3 Allowing An Expelled Participant To Join Again . . . . 6
80 6.1.4 Allowing Sarah to Refer Users . . . . . . . . . . . . 7
81 6.1.5 Removing A Conference . . . . . . . . . . . . . . . . 7
82 6.2 Conference Policy Privileges Manipulation . . . . . . . . 8
83 6.2.1 Creating Conference Policy Privilegtes . . . . . . . . 8
84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
86 8.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 9
87 8.1.1 conference-policies . . . . . . . . . . . . . . . . . 9
88 8.1.2 conference-policy-privielges . . . . . . . . . . . . . 9
89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
90 10. Normative References . . . . . . . . . . . . . . . . . . . . 9
91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
92 Intellectual Property and Copyright Statements . . . . . . . . 11
94 1. Introduction
96 The SIP conferencing framework [8] defines the mechanisms for
97 multi-party centralized conferencing in a SIP environment.
99 Existing SIP mechanisms allow users, for example, to join and leave a
100 conference, as described in [5]. A centralised server, called focus,
101 can expel and invite users, and may have proprietary access control
102 lists and user privilege definitions. The Conference Policy Control
103 Protocol [1] defines an XML Schema that enumerates the conference
104 policy data elements that enable a user to define a conference
105 policy. This policy document may be given to a focus using a number
106 of transports. Mechanisms such as a web page or a voice response
107 system can also be used to manipulate conference policy data.
109 Similarily, Privileges for Manipulating a Conference Policy [2]
110 defines an Extensible Markup Language (XML) Schema that enumerates
111 the conference policy meta data that enable a user to assign
112 privileges to users that enables them to read and/or manipulate a
113 conference policy. Mechanims are also needed to manipulate such
114 data.
116 In many cases it is useful to have standardised means to manipulate
117 conference policy elements and conference policy privileges elements.
118 Two XML Configuration Access Protocol (XCAP) [6] application usages
119 are defined that allow for the real-time manipulation of conference
120 policy and conference policy privileges and meets the requirements in
121 [4] to store and manipulate a conference policy object and a
122 conference policy privileges object.
124 XCAP has many advantages in its use for conference policy control
125 protocol. It is a HTTP 1.1 based protocol that allows clients to
126 read, write, modify and delete application data stored in XML format
127 at a server. XCAP maps XML document elements and attributes to HTTP
128 URIs that can be directly accessed by HTTP. One application area
129 which has already adopted XCAP is the manipulation of event lists
130 [7].
132 For manipulation of the Conference Policy XML object, the system MAY
133 support the XCAP usage defined in Section 4. For manipulation of the
134 Conference Policy Privileges XML object, the system MAY support the
135 XCAP usage defined in Section 5.
137 2. Conventions Used in This Document
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141 document are to be interpreted as described in RFC 2119 [3].
143 3. Terminology
145 This document uses terminology from [8]. Some additional definitions
146 are introduced in [1].
148 4. An XCAP Usage for Conference Policy Manipulation
150 4.1 Application Unique ID
152 XCAP requires application usages to define a unique application usage
153 ID (AUID) in either the IETF tree or a vendor tree. This
154 specification defines the "conference-policies" AUID within the IETF
155 tree, via the IANA registration in Section 8.
157 4.2 Resource Interdependencies
159 The conference policy server MAY fill the conference URI(s), but the
160 client MUST propose a conference URI. If the CPS does not allow
161 assignments of URIs by the client, it rejects the request with a
162 "409" response and SHOULD include a body in the response detailing
163 the error. XCAP Base document [6] section 7.2.1 explains how such a
164 response body is constructed. The CPS MAY assign multiple conference
165 URIs to a conference, one for each call signaling protocol that it
166 supports. Section xx of [1] (Conference Settings) discusses this is
167 more detail.
169 Sidebar URIs are subject to the same behaviour.
171 4.3 Additional Constraints
173 These are defined within the XML structure definition in [1].
175 4.4 Naming Conventions
177 There are no naming conventions that need to be defined for this
178 application usage.
180 4.5 Authorization Policies
182 A server can allow privileged users to modify documents that they
183 don't own. The establishment and indication of such policies is done
184 by setting the authorization rules as described in [2].
186 4.6 MIME Type for CPCP XML Document
188 The MIME type for the CPCP XML document is defined in [1].
190 5. An XCAP Usage for Conference Policy Privileges Manipulation
192 5.1 Application Unique ID
194 XCAP requires application usages to define a unique application usage
195 ID (AUID) in either the IETF tree or a vendor tree. This
196 specification defines the "conference-policy-privileges" AUID within
197 the IETF tree, via the IANA registration in Section 8.
199 5.2 Resource Interdependencies
201 There are no resource interdependencies that need to be defined fo
202 this application usage.
204 5.3 Additional Constraints
206 These are defined within the XML structure definition in [2].
208 5.4 Naming Conventions
210 There are no naming conventions that need to be defined for this
211 application usage.
213 5.5 Authorization Policies
215 This application usage does not modify the default XCAP authorization
216 policy, which is that only a user can read, write or modify their own
217 documents.
219 5.6 MIME Type for CPCP XML Document
221 The MIME type for the Conference Policy Privileges XML document is
222 defined in [2]
224 6. Examples
226 6.1 Conference Policy Manipulation
228 6.1.1 Creating a Conference
230 Continuing with the example in Section xx of [1], Alice's client uses
231 XCAP to transport the conference policy to the conference policy
232 server
234 PUT
235 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml HTTP/1.1
236 Content-Type: application/conference-policy+xml
238 [conference policy from [1] example goes here].
240 At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE
241 request to Alice and a SIP REFER request to Sarah. At
242 2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from
243 anyone at domain example.com. Any attempts to join the conference by
244 users in other domains are rejected.
246 6.1.2 Expelling a User
248 After the conference has started, Alice decides to expel Bob who has
249 joined the conference. So she modifies the authorization rule that
250 allows everyone at example.com to join:
252 PUT
253 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
255 Content-Type:text/plain
257
258 example.com
259 bob@example.com
260
262 At this point, the focus sends a SIP BYE request to Bob ending Bob's
263 participation in the conference. This also guarantees that Bob
264 cannot rejoin the conference since he is explicitly blocked. Any
265 attempt Bob makes in rejoining the conference will fail.
267 6.1.3 Allowing An Expelled Participant To Join Again
269 Continuing with the example above, Alice now decides to allow Bob to
270 join again after a period of time. She does so by rewriting parts of
271 the rule that blocks him from joining.
273 PUT
274 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
276 Content-Type:text/plain
278
279 example.com
280
282 Bob can now rejoin the conference by sending a SIP INVITE request.
284 6.1.4 Allowing Sarah to Refer Users
286 Alice now decides that Sarah can ask the focus to refer users to the
287 conference:
289 PUT
290 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id="3"] HTTP/1.1
292 Content-Type:text/plain
294
295
296
297 sarah@example.com
298
299
300
301 true
302
303
304
306 6.1.5 Removing A Conference
308 Alice now decides she no longer wants this conference to exist and
309 therefore deletes the conference:
311 DELETE
312 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml
314 As a result of this action, the focus sends SIP BYE requests to all
315 current participants in the conference. The conference server
316 terminates the focus thereafter.
318 6.2 Conference Policy Privileges Manipulation
320 6.2.1 Creating Conference Policy Privilegtes
322 Continuing with the example in Section xx of [2], Alice's client uses
323 XCAP to transport the conference policy privileges to the conference
324 policy server
326 PUT
327 http://xcap.example.com/services/conference-policy-privileges/users/Alice/cp-privileges.xml HTTP/1.1
329 Content-Type: application/privileges+xml
331 [conference policy privileges from [2] example goes here].
333 7. Security Considerations
335 A conference document may contain information that is highly
336 sensitive. Its delivery to the conference server needs to happen
337 strictly, paying special attention to integrity and confidentiality.
338 Reading the document is also a security concern since the conference
339 policy contains sensitive information like the topic of the
340 conference, who is allowed to join and the URIs of the users that can
341 participate.
343 Manipulations of the conference policy have similar security issues.
344 Users with relevant privileges can manipulate parts of the conference
345 policy giving themselves and others privileges to manipulate the
346 conference policy, including the dial-out list and the security level
347 settings for a conference. This can happen because the conference
348 policy itself carries the identities and the authorization rules that
349 apply to those identities. Those authorization rules carry the
350 privileges that certain identities have. If an unauthorized user
351 gets access to this document (pretending to be someone else), s/he
352 can manipulate those rules giving himself and other unauthorized
353 users access to the conference policy. S/he can also manipulate
354 other parts of the conference policy under a false identity. Some of
355 the things that a malicious user can do include: denying users
356 certain privileges, giving himself floor moderation, removing users
357 from lists, removing rules for certain identities, giving privileges
358 to other malicious users, changing the media streams and changing
359 conference time. Therefore, it is very important that only
360 authorized clients are able to manipulate the conference policy. Any
361 conference policy transport protocol MUST provide authentication,
362 confidentiality and integrity.
364 In the case that XCAP is used to create and manipulate a conference
365 policy, the XCAP base specification mandates that all XCAP servers
366 MUST implement HTTP Authentication: Basic and Digest Access
367 Authentication [9]. Furthermore, XCAP servers MUST implement HTTP
368 over TLS [10]. It is recommended that administrators of XCAP servers
369 use an HTTPS URI as the XCAP root services URI, so that the digest
370 client authentication occurs over TLS. By using these means, XCAP
371 client and server can ensure the confidentiality and integrity of the
372 XCAP created conference policy document and its manipulation
373 operations, and that only authorized clients are allowed to perform
374 them.
376 8. IANA Considerations
378 8.1 XCAP Application Usage IDs
380 8.1.1 conference-policies
382 Name of the AUID: conference-policies
383 Description: Conference policy application manipulates conference
384 policy at a server.
386 8.1.2 conference-policy-privielges
388 Name of the AUID: conference-policy-privileges
389 Description: Conference policy privileges application manipulates
390 conference policy privielges at a server.
392 9. Acknowledgements
394 The authors would like to thank Alan Johnston and the IETF XCON
395 working group for their feedback and suggestions.
397 10 Normative References
399 [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference
400 Policy Control Protocol (CPCP)", Internet-Draft
401 I-D.draft-ietf-xcon-cpcp, September 2004.
403 [2] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
404 Conference Policy", Internet-Draft
405 I-D.draft-ietf-xcon-conference-policy-privileges, September
406 2004.
408 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
409 Levels", RFC 2119, BCD 14, March 1997.
411 [4] Koskelainen, P. and H. Khartabil, "Requirements for conference
412 policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
413 progress), January 2004.
415 [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call
416 Control - Conferencing for User Agents",
417 draft-ietf-sipping-cc-conferencing-03 (work in progress),
418 February 2004.
420 [6] Rosenberg, J., "The Extensible Markup Language (XML)
421 Configuration Access Protocol (XCAP)",
422 draft-ietf-simple-xcap-02 (work in progress), February 2004.
424 [7] Rosenberg, J., "An Extensible Markup Language (XML)
425 Configuration Access Protocol (XCAP) Usage for Presence Lists",
426 draft-ietf-simple-xcap-list-usage-02 (work in progress),
427 February 2004.
429 [8] Rosenberg, J., "A Framework for Conferencing with the Session
430 Initiation Protocol",
431 draft-ietf-sipping-conferencing-framework-01 (work in
432 progress), October 2003.
434 [9] Franks, J., "HTTP Authentication: Basic and Digest Access
435 Authentication", RFC 2617, June 1999.
437 [10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
439 Author's Address
441 Hisham Khartabil
442 Nokia
443 P.O. Box 321
444 Helsinki FIN-00045
445 Finland
447 EMail: hisham.khartabil@nokia.com
449 Intellectual Property Statement
451 The IETF takes no position regarding the validity or scope of any
452 Intellectual Property Rights or other rights that might be claimed to
453 pertain to the implementation or use of the technology described in
454 this document or the extent to which any license under such rights
455 might or might not be available; nor does it represent that it has
456 made any independent effort to identify any such rights. Information
457 on the procedures with respect to rights in RFC documents can be
458 found in BCP 78 and BCP 79.
460 Copies of IPR disclosures made to the IETF Secretariat and any
461 assurances of licenses to be made available, or the result of an
462 attempt made to obtain a general license or permission for the use of
463 such proprietary rights by implementers or users of this
464 specification can be obtained from the IETF on-line IPR repository at
465 http://www.ietf.org/ipr.
467 The IETF invites any interested party to bring to its attention any
468 copyrights, patents or patent applications, or other proprietary
469 rights that may cover technology that may be required to implement
470 this standard. Please address the information to the IETF at
471 ietf-ipr@ietf.org.
473 Disclaimer of Validity
475 This document and the information contained herein are provided on an
476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
483 Copyright Statement
485 Copyright (C) The Internet Society (2004). This document is subject
486 to the rights, licenses and restrictions contained in BCP 78, and
487 except as set forth therein, the authors retain all their rights.
489 Acknowledgment
491 Funding for the RFC Editor function is currently provided by the
492 Internet Society.