idnits 2.17.1
draft-ietf-xcon-cpcp-xcap-03.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 3978, Section 5.1.a on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 472.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** 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:
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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 is 1 instance of too long lines in the document, the longest one
being 1 character 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 364 has weird spacing: '...cuments and t...'
-- 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 (October 12, 2004) is 7128 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: 10 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: April 12, 2005 October 12, 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-03
10 Status of this Memo
12 This document is an Internet-Draft and is subject to all provisions
13 of section 3 of RFC 3667. By submitting this Internet-Draft, each
14 author represents that any applicable patent or other IPR claims of
15 which he or she is aware have been or will be disclosed, and any of
16 which he or she become aware will be disclosed, in accordance with
17 RFC 3668.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as
22 Internet-Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on April 12, 2005.
37 Copyright Notice
39 Copyright (C) The Internet Society (2004).
41 Abstract
43 The Conference Policy is defined as the complete set of rules for a
44 particular conference manipulated by the conference policy server.
45 The Conferece Policy Control Protocol (CPCP) is the protocol used by
46 client to manipulate the conference policy. This document defines an
47 XML Configuration Access Protocol (XCAP) application usage that may
48 be used to store and manipulate a conference policy.
50 There also exists an Extensible Markup Language (XML) Schema that
51 enumerates the conference policy meta data that enable a user to
52 assign privileges to users that enables them to read and/or
53 manipulate parts of or the entirety of a conference policy. This
54 document defines an XML Configuration Access Protocol (XCAP)
55 application usage that may be used to store and manipulate a
56 conference policy priveleges XML document.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 4. An XCAP Usage for Conference Policy Manipulation . . . . . . . 4
64 4.1 Application Unique ID . . . . . . . . . . . . . . . . . . 4
65 4.2 Resource Interdependencies . . . . . . . . . . . . . . . . 4
66 4.3 Additional Constraints . . . . . . . . . . . . . . . . . . 4
67 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 4
68 4.5 Authorization Policies . . . . . . . . . . . . . . . . . . 4
69 4.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4
70 5. An XCAP Usage for Conference Policy Privileges Manipulation . 5
71 5.1 Application Unique ID . . . . . . . . . . . . . . . . . . 5
72 5.2 Resource Interdependencies . . . . . . . . . . . . . . . . 5
73 5.3 Additional Constraints . . . . . . . . . . . . . . . . . . 5
74 5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 5
75 5.5 Authorization Policies . . . . . . . . . . . . . . . . . . 5
76 5.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5
77 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
78 6.1 Conference Policy Manipulation . . . . . . . . . . . . . . 5
79 6.1.1 Creating a Conference . . . . . . . . . . . . . . . . 5
80 6.1.2 Expelling a User . . . . . . . . . . . . . . . . . . . 6
81 6.1.3 Allowing An Expelled Participant To Join Again . . . . 6
82 6.1.4 Allowing Sarah to Refer Users . . . . . . . . . . . . 7
83 6.1.5 Removing A Conference . . . . . . . . . . . . . . . . 7
84 6.2 Conference Policy Privileges Manipulation . . . . . . . . 8
85 6.2.1 Creating Conference Policy Privilegtes . . . . . . . . 8
86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
88 8.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 9
89 8.1.1 conference-policies . . . . . . . . . . . . . . . . . 9
90 8.1.2 conference-policy-privielges . . . . . . . . . . . . . 9
91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
92 10. Normative References . . . . . . . . . . . . . . . . . . . . 9
93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
94 Intellectual Property and Copyright Statements . . . . . . . . 11
96 1. Introduction
98 The SIP conferencing framework [8] defines the mechanisms for
99 multi-party centralized conferencing in a SIP environment.
101 Existing SIP mechanisms allow users, for example, to join and leave a
102 conference, as described in [5]. A centralised server, called focus,
103 can expel and invite users, and may have proprietary access control
104 lists and user privilege definitions. The Conference Policy Control
105 Protocol [1] defines an XML Schema that enumerates the conference
106 policy data elements that enable a user to define a conference
107 policy. This policy document may be given to a focus using a number
108 of transports. Mechanisms such as a web page or a voice response
109 system can also be used to manipulate conference policy data.
111 Similarily, Privileges for Manipulating a Conference Policy [2]
112 defines an Extensible Markup Language (XML) Schema that enumerates
113 the conference policy meta data that enable a user to assign
114 privileges to users that enables them to read and/or manipulate a
115 conference policy. Mechanims are also needed to manipulate such
116 data.
118 In many cases it is useful to have standardised means to manipulate
119 conference policy elements and conference policy privileges elements.
120 Two XML Configuration Access Protocol (XCAP) [6] application usages
121 are defined that allow for the real-time manipulation of conference
122 policy and conference policy privileges and meets the requirements in
123 [4] to store and manipulate a conference policy object and a
124 conference policy privileges object.
126 XCAP has many advantages in its use for conference policy control
127 protocol. It is a HTTP 1.1 based protocol that allows clients to
128 read, write, modify and delete application data stored in XML format
129 at a server. XCAP maps XML document elements and attributes to HTTP
130 URIs that can be directly accessed by HTTP. One application area
131 which has already adopted XCAP is the manipulation of event lists
132 [7].
134 For manipulation of the Conference Policy XML object, the system MAY
135 support the XCAP usage defined in Section 4. For manipulation of the
136 Conference Policy Privileges XML object, the system MAY support the
137 XCAP usage defined in Section 5.
139 2. Conventions Used in This Document
141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143 document are to be interpreted as described in RFC 2119 [3].
145 3. Terminology
147 This document uses terminology from [8]. Some additional definitions
148 are introduced in [1].
150 4. An XCAP Usage for Conference Policy Manipulation
152 4.1 Application Unique ID
154 XCAP requires application usages to define a unique application usage
155 ID (AUID) in either the IETF tree or a vendor tree. This
156 specification defines the "conference-policies" AUID within the IETF
157 tree, via the IANA registration in Section 8.
159 4.2 Resource Interdependencies
161 The conference policy server MAY fill the conference URI(s), but the
162 client MUST propose a conference URI. If the CPS does not allow
163 assignments of URIs by the client, it rejects the request with a
164 "409" response and SHOULD include a body in the response detailing
165 the error. XCAP Base document [6] section 7.2.1 explains how such a
166 response body is constructed. The CPS MAY assign multiple conference
167 URIs to a conference, one for each call signaling protocol that it
168 supports. Section xx of [1] (Conference Settings) discusses this is
169 more detail.
171 Sidebar URIs are subject to the same behaviour.
173 4.3 Additional Constraints
175 These are defined within the XML structure definition in [1].
177 4.4 Naming Conventions
179 There are no naming conventions that need to be defined for this
180 application usage.
182 4.5 Authorization Policies
184 A server can allow privileged users to modify documents that they
185 don't own. The establishment and indication of such policies is done
186 by setting the authorization rules as described in [2].
188 4.6 MIME Type for CPCP XML Document
190 The MIME type for the CPCP XML document is defined in [1].
192 5. An XCAP Usage for Conference Policy Privileges Manipulation
194 5.1 Application Unique ID
196 XCAP requires application usages to define a unique application usage
197 ID (AUID) in either the IETF tree or a vendor tree. This
198 specification defines the "conference-policy-privileges" AUID within
199 the IETF tree, via the IANA registration in Section 8.
201 5.2 Resource Interdependencies
203 There are no resource interdependencies that need to be defined fo
204 this application usage.
206 5.3 Additional Constraints
208 These are defined within the XML structure definition in [2].
210 5.4 Naming Conventions
212 The "filename" as defined in XCAP Base document [6] is used to
213 describe the final path segment in the document selector. This XCAP
214 usage requires that the filename of the conference policy privileges
215 be exactly the same as the filename given to the conference policy
216 that it relates to. This will save processing time in that the focus
217 does not need to search all conference privileges documents looking
218 for the right one. This also eliminates any conflicts that may occur
219 by disallowing more than one conference policy privileges document to
220 exist for a single conference policy.
222 5.5 Authorization Policies
224 This application usage does not modify the default XCAP authorization
225 policy, which is that only a user can read, write or modify their own
226 documents.
228 5.6 MIME Type for CPCP XML Document
230 The MIME type for the Conference Policy Privileges XML document is
231 defined in [2]
233 6. Examples
235 6.1 Conference Policy Manipulation
237 6.1.1 Creating a Conference
239 Continuing with the example in Section xx of [1], Alice's client uses
240 XCAP to transport the conference policy to the conference policy
241 server
243 PUT
244 http://xcap.example.com/services/conference-policies/users/Alice/c
245 onference.xml HTTP/1.1
246 Content-Type: application/conference-policy+xml
248 [conference policy from [1] example goes here].
250 At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE
251 request to Alice and a SIP REFER request to Sarah. At
252 2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from
253 anyone at domain example.com. Any attempts to join the conference by
254 users in other domains are rejected.
256 6.1.2 Expelling a User
258 After the conference has started, Alice decides to expel Bob who has
259 joined the conference. So she modifies the authorization rule that
260 allows everyone at example.com to join:
262 PUT
263 http://xcap.example.com/services/conference-policies/users/Alice/c
264 onference.xml/~~/conference/authorization-rules/rule[@id=""]/condi
265 tions/identity/ HTTP/1.1
266 Content-Type:text/plain
268
269 example.com
270 bob@example.com
271
273 At this point, the focus sends a SIP BYE request to Bob ending Bob's
274 participation in the conference. This also guarantees that Bob
275 cannot rejoin the conference since he is explicitly blocked. Any
276 attempt Bob makes in rejoining the conference will fail.
278 6.1.3 Allowing An Expelled Participant To Join Again
280 Continuing with the example above, Alice now decides to allow Bob to
281 join again after a period of time. She does so by rewriting parts of
282 the rule that blocks him from joining.
284 PUT
285 http://xcap.example.com/services/conference-policies/users/Alice/c
286 onference.xml/~~/conference/authorization-rules/rule[@id=""]/condi
287 tions/identity/ HTTP/1.1
288 Content-Type:text/plain
290
291 example.com
292
294 Bob can now rejoin the conference by sending a SIP INVITE request.
296 6.1.4 Allowing Sarah to Refer Users
298 Alice now decides that Sarah can ask the focus to refer users to the
299 conference:
301 PUT
302 http://xcap.example.com/services/conference-policies/users/Alice/c
303 onference.xml/~~/conference/authorization-rules/rule[@id="3"]
304 HTTP/1.1
305 Content-Type:text/plain
307
308
309
310 sarah@example.com
311
312
313
314 true
315
316
317
319 6.1.5 Removing A Conference
321 Alice now decides she no longer wants this conference to exist and
322 therefore deletes the conference:
324 DELETE
325 http://xcap.example.com/services/conference-policies/users/Alice/c
326 onference.xml
328 As a result of this action, the focus sends SIP BYE requests to all
329 current participants in the conference. The conference server
330 terminates the focus thereafter.
332 6.2 Conference Policy Privileges Manipulation
334 6.2.1 Creating Conference Policy Privilegtes
336 Continuing with the example in Section xx of [2], Alice's client uses
337 XCAP to transport the conference policy privileges to the conference
338 policy server
340 PUT
341 http://xcap.example.com/services/conference-policy-privileges/user
342 s/Alice/cp-privileges.xml HTTP/1.1
343 Content-Type: application/privileges+xml
345 [conference policy privileges from [2] example goes here].
347 7. Security Considerations
349 The information contained in conference-policies and
350 conference-policy-privileges documents are particularly sensitive.
351 The former represents critical conference information like allowed
352 user and conference time while the latter represents the list of
353 privileged people with assigned privileges. As a result, clients
354 SHOULD use TLS when contacting servers in order to fetch this
355 information. Note that this does not represent a change in
356 requirement strength from XCAP. The XCAP base specification mandates
357 that all XCAP servers MUST implement HTTP Authentication: Basic and
358 Digest Access Authentication [9]. Furthermore, XCAP servers MUST
359 implement HTTP over TLS [10]. It is recommended that administrators
360 of XCAP servers use an HTTPS URI as the XCAP root services URI, so
361 that the digest client authentication occurs over TLS. By using
362 these means, XCAP client and server can ensure the confidentiality
363 and integrity of the XCAP created conference policy and conference
364 policy privileges documents and their manipulation operations, and
365 that only authorized clients are allowed to perform them.
367 8. IANA Considerations
369 8.1 XCAP Application Usage IDs
371 8.1.1 conference-policies
373 Name of the AUID: conference-policies
374 Description: Conference policy application manipulates conference
375 policy at a server.
377 8.1.2 conference-policy-privielges
379 Name of the AUID: conference-policy-privileges
380 Description: Conference policy privileges application manipulates
381 conference policy privielges at a server.
383 9. Acknowledgements
385 The authors would like to thank Alan Johnston and the IETF XCON
386 working group for their feedback and suggestions.
388 10 Normative References
390 [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference
391 Policy Control Protocol (CPCP)", Internet-Draft
392 I-D.draft-ietf-xcon-cpcp, September 2004.
394 [2] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
395 Conference Policy", Internet-Draft
396 I-D.draft-ietf-xcon-conference-policy-privileges, September
397 2004.
399 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
400 Levels", RFC 2119, BCD 14, March 1997.
402 [4] Koskelainen, P. and H. Khartabil, "Requirements for conference
403 policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
404 progress), January 2004.
406 [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call
407 Control - Conferencing for User Agents",
408 draft-ietf-sipping-cc-conferencing-03 (work in progress),
409 February 2004.
411 [6] Rosenberg, J., "The Extensible Markup Language (XML)
412 Configuration Access Protocol (XCAP)",
413 draft-ietf-simple-xcap-02 (work in progress), February 2004.
415 [7] Rosenberg, J., "An Extensible Markup Language (XML)
416 Configuration Access Protocol (XCAP) Usage for Presence Lists",
417 draft-ietf-simple-xcap-list-usage-02 (work in progress),
418 February 2004.
420 [8] Rosenberg, J., "A Framework for Conferencing with the Session
421 Initiation Protocol",
422 draft-ietf-sipping-conferencing-framework-01 (work in
423 progress), October 2003.
425 [9] Franks, J., "HTTP Authentication: Basic and Digest Access
426 Authentication", RFC 2617, June 1999.
428 [10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
430 Author's Address
432 Hisham Khartabil
433 Nokia
434 P.O. Box 321
435 Helsinki FIN-00045
436 Finland
438 EMail: hisham.khartabil@nokia.com
440 Intellectual Property Statement
442 The IETF takes no position regarding the validity or scope of any
443 Intellectual Property Rights or other rights that might be claimed to
444 pertain to the implementation or use of the technology described in
445 this document or the extent to which any license under such rights
446 might or might not be available; nor does it represent that it has
447 made any independent effort to identify any such rights. Information
448 on the procedures with respect to rights in RFC documents can be
449 found in BCP 78 and BCP 79.
451 Copies of IPR disclosures made to the IETF Secretariat and any
452 assurances of licenses to be made available, or the result of an
453 attempt made to obtain a general license or permission for the use of
454 such proprietary rights by implementers or users of this
455 specification can be obtained from the IETF on-line IPR repository at
456 http://www.ietf.org/ipr.
458 The IETF invites any interested party to bring to its attention any
459 copyrights, patents or patent applications, or other proprietary
460 rights that may cover technology that may be required to implement
461 this standard. Please address the information to the IETF at
462 ietf-ipr@ietf.org.
464 Disclaimer of Validity
466 This document and the information contained herein are provided on an
467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
474 Copyright Statement
476 Copyright (C) The Internet Society (2004). This document is subject
477 to the rights, licenses and restrictions contained in BCP 78, and
478 except as set forth therein, the authors retain all their rights.
480 Acknowledgment
482 Funding for the RFC Editor function is currently provided by the
483 Internet Society.