idnits 2.17.1
draft-ietf-simple-xcap-pidf-manipulation-usage-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 3978, Section 5.1.a on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 471.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461.
** 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 are 3 instances of too long lines in the document, the longest one
being 8 characters in excess of 72.
** There are 2 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
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- 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 22, 2004) is 7098 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)
== Outdated reference: A later version (-12) exists of
draft-ietf-simple-xcap-03
** Obsolete normative reference: RFC 2617 (ref. '5') (Obsoleted by RFC
7235, RFC 7615, RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2818 (ref. '6') (Obsoleted by RFC 9110)
== Outdated reference: A later version (-10) exists of
draft-ietf-simple-rpid-03
== Outdated reference: A later version (-07) exists of
draft-ietf-simple-cipid-03
== Outdated reference: A later version (-07) exists of
draft-ietf-simple-presence-data-model-00
== Outdated reference: A later version (-10) exists of
draft-ietf-simple-prescaps-ext-01
== Outdated reference: A later version (-05) exists of
draft-ietf-simple-future-02
Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIMPLE WG M. Isomaki
3 Internet-Draft E. Leppanen
4 Expires: April 22, 2005 Nokia
5 October 22, 2004
7 An Extensible Markup Language (XML) Configuration Access Protocol
8 (XCAP) Usage for Manipulating Presence Document Contents
9 draft-ietf-simple-xcap-pidf-manipulation-usage-02
11 Status of this Memo
13 This document is an Internet-Draft and is subject to all provisions
14 of section 3 of RFC 3667. By submitting this Internet-Draft, each
15 author represents that any applicable patent or other IPR claims of
16 which he or she is aware have been or will be disclosed, and any of
17 which he or she become aware will be disclosed, in accordance with
18 RFC 3668.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as
23 Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on April 22, 2005.
38 Copyright Notice
40 Copyright (C) The Internet Society (2004).
42 Abstract
44 This document describes a usage of the Extensible Markup Language
45 (XML) Configuration Access Protocol (XCAP) for manipulating the
46 contents of Presence Information Data Format (PIDF) based presence
47 document. It is intended to be used in Session Initiation Protocol
48 (SIP) based presence systems, where the Event State Compositor can
49 use the XCAP-manipulated presence document as one of the inputs on
50 which it builds the overall presence state for the presentity.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
56 3. Relationship with Presence State Published Using SIP
57 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 4. Application Usage ID . . . . . . . . . . . . . . . . . . . . 6
59 5. Structure of Manipulated Presence Information . . . . . . . 6
60 6. Additional Constraints . . . . . . . . . . . . . . . . . . . 6
61 7. Resource Interdependencies . . . . . . . . . . . . . . . . . 6
62 8. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 6
63 9. Authorization Policies . . . . . . . . . . . . . . . . . . . 6
64 10. Example Document . . . . . . . . . . . . . . . . . . . . . . 6
65 11. Security Considerations . . . . . . . . . . . . . . . . . . 8
66 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
67 12.1 XCAP Application Usage ID . . . . . . . . . . . . . . . 8
68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
70 14.1 Normative References . . . . . . . . . . . . . . . . . . . 9
71 14.2 Informative References . . . . . . . . . . . . . . . . . . 9
72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
73 Intellectual Property and Copyright Statements . . . . . . . 11
75 1. Introduction
77 The Session Initiation Protocol (SIP) for Instant Messaging and
78 Presence (SIMPLE) specifications allow a user, called a watcher, to
79 subscribe to another user, called a presentity, in order to learn
80 their presence information [7]. The presence data model has been
81 specified in [10]. The data model makes a clean separation between
82 person, service and device related information.
84 A SIP based mechanism, SIP PUBLISH method, has been defined for
85 publishing presence state [4]. Using SIP PUBLISH a Presence User
86 Agent (PUA) can publish its view of the presence state, independently
87 of and without the need to learn about the states set by other PUAs.
88 However, SIP PUBLISH has a limited scope and does not address all the
89 requirements for setting presence state. The main issue is that SIP
90 PUBLISH creates a soft state which expires after the negotiated
91 lifetime unless it is refreshed. This makes it unsuitable for cases
92 where the state should prevail without active devices capable of
93 refreshing the state.
95 There are three main use cases where setting of permanent presence
96 state that is independent of activeness of any particular device is
97 useful. The first case concerns setting person related state. The
98 presentity would often like to set its presence state even for
99 periods when it has no active devices capable of publishing
100 available. Good examples are traveling, vacations and so on. The
101 second case is about setting state for services that are open for
102 communication even if the presentity does not have a device running
103 that service on-line. Examples of this kind of services include
104 e-mail, MMS and SMS. In these services the presentity is provisioned
105 with a server that makes the service persistently available, at least
106 in certain form, and it would be good to be able to advertise this to
107 the watchers. Since it is not realistic to assume that all e-mail,
108 MMS or SMS servers can publish presence state on their own (and even
109 if this were possible, such state would almost never change), this
110 has to be done by some other device - and since the availability of
111 the service is not dependent on that device, it would be unpractical
112 to require that device to be constantly active just to publish such
113 availability. The third case concerns setting the default state of
114 person, any service or any device in the absence of any device
115 capable of actively publishing such state. For instance the
116 presentity might want to advertise that his or her voice service is
117 right now closed, just to let the watchers to know that such service
118 might be open at some point. Again, this type of default state is
119 independent of any particular device, and can be considered to be
120 rather persistent.
122 Even though SIP PUBLISH remains to be the main way of publishing
123 presence state in SIMPLE based presence systems and is espcially well
124 suited for publishing dynamic state (which presence mainly is), it
125 needs to be complemented by the mechanism described in this document
126 to address the use cases presented above.
128 XML Configuration Access Protocol (XCAP) [2] allows a client to read,
129 write and modify application configuration data, stored in XML format
130 on a server. The data has no expiration time, so it must be
131 explicitly inserted and deleted. The protocol allows multiple
132 clients to manipulate the data, provided that they are authorized to
133 do so. XCAP is already used in SIMPLE based presence systems for
134 manipulation of presence lists and presence authorization policies.
135 This makes XCAP an ideal choice for doing device independent presence
136 document manipulation.
138 This document defines an XML Configuration Access Protocol (XCAP)
139 application usage for manipulating the contents of presence document.
140 Presence Information Document Format (PIDF) [3] is used as the
141 presence document format, since event state compositor already has to
142 support it, as it is used in SIP PUBLISH.
144 Section 3 describes in more detail how the presence document
145 manipulated with XCAP is related to soft state publishing done with
146 SIP PUBLISH.
148 XCAP requires application usages to standardize several pieces of
149 information, including a unique application usage ID (AUID), and an
150 XML schema for the manipulated data. These are specified starting
151 from Section 4.
153 2. Conventions
155 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
156 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
157 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1]
158 and indicate requirement levels for compliant implementations.
160 Comprehensive terminology of presence and event state publishing is
161 provided in Session Initiation Protocol (SIP) Extension for Event
162 State Publication [4].
164 3. Relationship with Presence State Published Using SIP PUBLISH
166 The framework for publishing presence state is described in Figure 1.
167 A central part of the framework is the event state compositor element
168 whose function is to compose presence information received from
169 several sources into a single coherent presence document.
171 The presence state manipulated with XCAP can be seen as one of the
172 information sources for the compositor to be combined with the soft
173 state information published using SIP PUBLISH. This is illustrated
174 in Figure 1. It is expected that in the normal case there can be
175 several PUAs publishing their separate views with SIP PUBLISH, but
176 only a single XCAP manipulated presence document. As shown in the
177 figure, there can be multiple XCAP clients (for instance in different
178 physical devices) manipulating the same document on the XCAP server,
179 but this still creates only one input to the event state compositor.
181 As individual inputs the presence states set by XCAP and SIP PUBLISH
182 are completely separated and it is not possible to directly
183 manipulate the state set by one mechanism with the other. How the
184 compositor treats XCAP based inputs with respect to SIP PUBLISH based
185 inputs is a matter of compositor policy, which is beyond the scope of
186 this specification. Since the SIP PUBLISH specification already
187 mandates the compositor to be able to construct the overall presence
188 state from multiple inputs which may contain non-orthogonal (or in
189 some ways even conflicting) information, this XCAP usage does not
190 impose any new requirements on the compositor functionality.
192 +---------------+ +------------+
193 | Event State | | Presence |<-- SIP SUBSCRIBE
194 | Compositor +---------+ Agent |--> SIP NOTIFY
195 | | | (PA) |
196 +-------+-------+ +------------+
197 ^ ^ ^
198 | | |
199 | | | +---------------+
200 +--------+ | +-------| XCAP server |
201 | | +-------+-------+
202 | | ^ ^
203 | SIP Publish | | XCAP |
204 | | | |
205 +--+--+ +--+--+ +-------+ +-------+
206 | PUA | | PUA | | XCAP | | XCAP |
207 | | | | | client| | client|
208 +-----+ +-----+ +-------+ +-------+
210 Figure 1: Framework for Presence Publishing and Event State
211 Composition
213 The protocol interface between XCAP server and the event state
214 compositor is not specified here.
216 4. Application Usage ID
218 XCAP requires application usages to define a unique application usage
219 ID (AUID) in either the IETF tree or a vendor tree. This
220 specification defines the 'pidf-manipulation' AUID within the IETF
221 tree, via the IANA registration in the Section 12.
223 5. Structure of Manipulated Presence Information
225 The XML Schema of the presence information (PIDF) is defined in CPIM
226 Presence Information Data Format [3]. The PIDF also defines a
227 mechanism for extending presence information. See [8], [9], [11] and
228 [12] for currently defined PIDF extensions and their XML Schemas.
230 The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf'.
232 6. Additional Constraints
234 There are no constraints on the document beyond those described in
235 the XML schemas (PIDF and its extensions) and in the description of
236 CPIM PIDF [3].
238 7. Resource Interdependencies
240 There are no resource interdependencies beyond the possible
241 interdependencies defined in CPIM PIDF [3] and XCAP [2] that need to
242 be defined for this application usage.
244 8. Naming Conventions
246 There are no naming conventions beyond the possible conventions
247 defined in CPIM PIDF [3] that need to be defined for this application
248 usage.
250 9. Authorization Policies
252 This application usage does not modify the default XCAP authorization
253 policy, which allows only a user (owner) to read, write or modify
254 their own documents. A server can allow privileged users to modify
255 documents that they do not own, but the establishment and indication
256 of such policies is outside the scope of this document.
258 10. Example Document
260 The section provides an example of presence document provided by an
261 XCAP Client to an XCAP Server. The presence document illustrates the
262 situation where a (human) presentity has left for vacation, and
263 before that has set his presence information such that he is only
264 available via e-mail. In the absence of any published soft state
265 information, this would be the sole input to the compositor forming
266 the presence document. The example document contain PIDF extensions
267 specified in RPID: Rich Presence Extensions to the Presence
268 Information Data Format (PIDF) [8] and CIPID: Contact Information in
269 Presence Information Data Format [9].
271 First, the presence document is created.
273 PUT http://xcap.example.com/services/pidf-manipulation/users/someone/pidf.xml
274 HTTP/1.1
275 Content type:appliation/pidf+xml
277
278
285
286
287 closed
288
289
290 auth-1
291 sip:user@example.com
292 I'm available only by e-mail.
293 2004-02-06T16:49:29Z
294
296
297
298 open
299
300 auth-1
301 mailto:someone@example.com
302 I'm reading mail a couple of times a week
303
305
306 auth-A
307 http://www.example.com/~someone
308
309
310 Vacation
311
313
314
316
318 HTTP/1.1 201 Created
319 Etag: "xyz"
321 Next, the note concerning the e-mail is changed.
323 PUT http://xcap.example.com/services/pidf-manipulation/users/someone/pidf.xml
324 /~~/presence/tuple%5b@id=%228eg92n%22%5d/note HTTP/1.1
325 If-Match: "xyz"
326 Content type:appliation/xcap-el+xml
328 I'm reading mails on Tuesdays and Fridays
330 HTTP/1.1 200 OK
331 Etag:"xyzz"
333 11. Security Considerations
335 A presence document may contain information that is highly sensitive.
336 Its delivery to watchers needs to happen strictly according to the
337 relevant authorization policies. It is also important that only
338 authorized clients are able to manipulate the presence information.
340 The XCAP base specification mandates that all XCAP servers MUST
341 implement HTTP Digest authentication specified in RFC 2617 [5].
342 Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is
343 recommended that administrators of XCAP servers use an HTTPS URI as
344 the XCAP root services URI, so that the digest client authentication
345 occurs over TLS. By using these means, XCAP client and server can
346 ensure the confidentiality and integrity of the XCAP presence
347 document manipulation operations, and that only authorized clients
348 are allowed to perform them.
350 12. IANA Considerations
352 There is an IANA consideration associated with this specification.
354 12.1 XCAP Application Usage ID
356 This section registers a new XCAP Application Usage ID (AUID)
357 according to the IANA procedures defined in [2].
359 Name of the AUID: pidf-manipulation
361 Description: Pidf-manipulation application usage defines how XCAP is
362 used to manipulate the contents of PIDF based presence documents.
364 13. Acknowledgements
366 The authors would like to thank Jonathan Rosenberg, Hisham Khartabil,
367 Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss,
368 Jose Costa-Requena, George Foti and Paul Kyzivat for their comments.
370 14. References
372 14.1 Normative References
374 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
375 Levels", BCP 14, RFC 2119, March 1997.
377 [2] Rosenberg, J., "The Extensible Markup Language (XML)
378 Configuration Access Protocol (XCAP)",
379 draft-ietf-simple-xcap-03 (work in progress), July 2004.
381 [3] Sugano, H., "CPIM presence information data format",
382 draft-ietf-impp-cpim-pidf-08, May 2003.
384 [4] Niemi, A., "An Event State Publication Extension for Session
385 Initiation Protocol (SIP)", draft-ietf-sip-publish-04.txt, May
386 2004.
388 [5] Franks, J., "HTTP Authentication: Basic and Digest Access
389 Authentication", RFC 2617, June 1999.
391 [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
393 14.2 Informative References
395 [7] Rosenberg, J., "A Presence Event Package for the Session
396 Initiation Protocol (SIP)", RFC 3856, August 2004.
398 [8] Schulzrinne, H., "RPID: Rich Presence Extensions to the
399 Presence Information Data Format (PIDF)",
400 draft-ietf-simple-rpid-03.txt (work in progress), March 2004.
402 [9] Schulzrinne, H., "CIPID: Contact Information in Presence
403 Information Data Format", draft-ietf-simple-cipid-03.txt (work
404 in progress), July 2004.
406 [10] Rosenberg, J., "A Data Model for Presence",
407 draft-ietf-simple-presence-data-model-00 (work in progress),
408 September 2004.
410 [11] Lonnfors, M., "User Agent Capability Extension to Presence
411 Information Data Format (PIDF)",
412 draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004.
414 [12] Schulzrinne, H., "Timed Presence Extensions to the Presence
415 Information Data Format (PIDF) to Indicate Presence Information
416 for Past and Future Time Intervals",
417 draft-ietf-simple-future-02 (work in progress), July 2004.
419 Authors' Addresses
421 Markus Isomaki
422 Nokia
423 P.O.BOX 100
424 00045 NOKIA GROUP
425 Finland
427 Phone:
428 EMail: markus.isomaki@nokia.com
430 Eva Leppanen
431 Nokia
432 P.O BOX 785
433 33101 Tampere
434 Finland
436 Phone:
437 EMail: eva-maria.leppanen@nokia.com
439 Intellectual Property Statement
441 The IETF takes no position regarding the validity or scope of any
442 Intellectual Property Rights or other rights that might be claimed to
443 pertain to the implementation or use of the technology described in
444 this document or the extent to which any license under such rights
445 might or might not be available; nor does it represent that it has
446 made any independent effort to identify any such rights. Information
447 on the procedures with respect to rights in RFC documents can be
448 found in BCP 78 and BCP 79.
450 Copies of IPR disclosures made to the IETF Secretariat and any
451 assurances of licenses to be made available, or the result of an
452 attempt made to obtain a general license or permission for the use of
453 such proprietary rights by implementers or users of this
454 specification can be obtained from the IETF on-line IPR repository at
455 http://www.ietf.org/ipr.
457 The IETF invites any interested party to bring to its attention any
458 copyrights, patents or patent applications, or other proprietary
459 rights that may cover technology that may be required to implement
460 this standard. Please address the information to the IETF at
461 ietf-ipr@ietf.org.
463 Disclaimer of Validity
465 This document and the information contained herein are provided on an
466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
468 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
469 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
470 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
473 Copyright Statement
475 Copyright (C) The Internet Society (2004). This document is subject
476 to the rights, licenses and restrictions contained in BCP 78, and
477 except as set forth therein, the authors retain all their rights.
479 Acknowledgment
481 Funding for the RFC Editor function is currently provided by the
482 Internet Society.