idnits 2.17.1
draft-ietf-simple-winfo-format-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 6 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
== 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 (January 31, 2003) is 7756 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)
** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665)
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6')
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
** Obsolete normative reference: RFC 3023 (ref. '9') (Obsoleted by RFC 7303)
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force SIMPLE WG
3 Internet Draft J. Rosenberg
4 dynamicsoft
5 draft-ietf-simple-winfo-format-04.txt
6 January 31, 2003
7 Expires: July 2003
9 An Extensible Markup Language (XML) Based Format
10 for Watcher Information
12 STATUS OF THIS MEMO
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
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 Internet-
20 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 To view the list Internet-Draft Shadow Directories, see
31 http://www.ietf.org/shadow.html.
33 Abstract
35 Watchers are defined as entities that request (i.e., subscribe to)
36 information about a resource. There is fairly complex state
37 associated with these subscriptions. The union of the state for all
38 subscriptions to a particular resource is called the watcher
39 information for that resource. This state is dynamic, changing as
40 subscribers come and go. As a result, it is possible, and indeed
41 useful, to subscribe to the watcher information for a particular
42 resource. In order to enable this, a format is needed to describe the
43 state of watchers on a resource. This specification describes an XML
44 document format for such state.
46 Table of Contents
48 1 Introduction ........................................ 3
49 2 Terminology ......................................... 3
50 3 Structure of Watcher Information .................... 3
51 4 Computing Watcher Lists from the Document ........... 5
52 5 Example ............................................. 6
53 6 XML Schema .......................................... 7
54 7 Security Considerations ............................. 9
55 8 IANA Considerations ................................. 9
56 8.1 application/watcherinfo+xml MIME Registration ....... 9
57 8.2 URN Sub-Namespace Registration for
58 urn:ietf:params:xml:ns:watcherinfo ............................. 10
59 9 Contributors ........................................ 11
60 10 Acknowledgements .................................... 12
61 11 Authors Addresses ................................... 12
62 12 Normative References ................................ 12
63 13 Informative References .............................. 13
65 1 Introduction
67 Watchers are defined as entities that request (i.e., subscribe to)
68 information about a resource, using the SIP event framework, RFC 3265
69 [1]. There is fairly complex state associated with these
70 subscriptions. This state includes the identity of the subscriber,
71 the state of the subscription, and so on. The union of the state for
72 all subscriptions to a particular resource is called the watcher
73 information for that resource. This state is dynamic, changing as
74 subscribers come and go. As a result, it is possible, and indeed
75 useful, to subscribe to the watcher information for a particular
76 resource. An important application of this is the ability for a user
77 to find out the set of subscribers to their presentity [11]. This
78 would allow the user to provide an authorization decision for the
79 subscription.
81 To support subscriptions to watcher information, two components are
82 needed. The first is the definition of a SIP event template-package
83 for watcher information. The other is the definition of a data format
84 to represent watcher information. The former is specified in [2], and
85 the latter is specified here.
87 2 Terminology
89 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
91 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
92 indicate requirement levels for compliant implementations.
94 This document also uses the terms subscriber, watcher, subscription,
95 notification, watcherinfo subscription, watcherinfo subscriber, and
96 watcherinfo notification with the meanings described in [2].
98 3 Structure of Watcher Information
100 Watcher information is an XML document [4] that MUST be well-formed
101 and SHOULD be valid. Watcher information documents MUST be based on
102 XML 1.0 and MUST be encoded using UTF-8. This specification makes use
103 of XML namespaces for identifying watcherinfo documents and document
104 fragments. The namespace URI for elements defined by this
105 specification is a URN [5], using the namespace identifier 'ietf'
106 defined by [6] and extended by [7]. This URN is:
108 urn:ietf:params:xml:ns:watcherinfo
109 A watcher information document begins with the root element tag
110 "watcherinfo". It consists of any number of "watcher-list" sub-
111 elements, each of which is a list of watchers for a particular
112 resource. Other elements from different namespaces MAY be present for
113 the purposes of extensibility; elements or attributes from unknown
114 namespaces MUST be ignored. There are two attributes associated with
115 this element, both of which MUST be present:
117 version: This attribute allows the recipient of watcherinfo
118 documents to properly order them. Versions start at 0, and
119 increment by one for each new document sent to a
120 subscriber. Versions are scoped within a watcherinfo
121 subscription. Versions MUST be representable using a 32 bit
122 integer. However, versions do not wrap.
124 state: This attribute indicates whether the document contains
125 the full watcherinfo state, or whether it contains only
126 information on those watchers which have changed since the
127 previous document (partial).
129 Each "watcher-list" element contains the set of watchers on a
130 particular resource. Other elements from different namespaces MAY be
131 present for the purposes of extensibility; elements or attributes
132 from unknown namespaces MUST be ignored. There are two attributes
133 associated with this element, both of which MUST be present:
135 resource: This attribute contains a URI for the resource being
136 watched by that list of watchers. It is mandatory.
138 package: This attribute contains a token indicating the event
139 package for which watcher information on that resource is
140 being provided. It is mandatory.
142 The "watcher" element describes a watcher in the watcher list. The
143 value of the "watcher" element is a URI for the watcher. This URI
144 SHOULD be an address-of-record (for example, sip:joe@example.com) as
145 opposed to a device address (for example, sip:joe@192.0.2.3). There
146 are three mandatory attributes which MUST be present:
148 id: A unique identifier for the subscription described by the
149 watcher element. The id MUST be representable using the
150 grammar for token as specified by RFC 3261 [8]. It MUST be
151 unique across all other watchers reported in documents sent
152 in notifications for a particular watcherinfo subscription.
154 status: The status of the subscription. The meaning of the
155 various statuses are defined in the watcher information
156 event package [2].
158 event: The event which caused the transition to the current
159 status. The events are defined in the watcher information
160 event package [2].
162 There are also some optional, informative attributes of the watcher
163 element. These are:
165 display-name: A textual representation of the name of the
166 subscriber.
168 expiration: The amount of time, in seconds from the current
169 time, that the subscription will expire.
171 duration-subscribed: The amount of time, expressed in seconds,
172 between the time the SUBSCRIBE which created the
173 subscription was received, and the current time.
175 The xml:lang attribute MAY be used with the "watcher" element to
176 specify the language of the "display-name".
178 The number of watchers present for each resource, and the set of
179 resources listed, depends on the type of data being provided, and to
180 whom.
182 For example, consider a presence system using watcher information.
183 In one scenario, a user, A, subscribes to the presence of another
184 user, B. A would like to find out about the status of their
185 subscription. To do so, A subscribes to the watcher information for
186 B's presence. A does not have authorization to learn the status of
187 all watchers for B's presence. As a result, the watcher information
188 sent to A will contain only one watcher - A themself.
190 In another scenario, a user, B, wishes to learn the set of people who
191 have subscribed to B's presence. To do this, B subscribes to the
192 watcher information for B's presence. Here, B is authorized to see
193 all the watchers of B's presence. As a result, the watcher
194 information sent to B will contain all watchers of B's presence.
196 In the case where an administrator wishes to learn the current status
197 in the system, the watcher information could contain all watchers for
198 all resources.
200 4 Computing Watcher Lists from the Document
202 Typically, the watcherinfo NOTIFY will only contain information about
203 those watchers whose state has changed. To construct a coherent view
204 of the total state of all watchers, a watcherinfo subscriber will
205 need to combine NOTIFYs received over time. The watcherinfo
206 subscriber maintains a table for each watcher list it receives
207 information about. Each watcher list is uniquely identified by the
208 URI in the "resource" attribute of the "watcher-list" element. Each
209 table contains a row for each watcher in that watcher list. Each row
210 is indexed by the unique ID for that watcher. It is conveyed in the
211 "id" attribute of the "watcher" element. The contents of each row
212 contain the state of that watcher as conveyed in the "watcher"
213 element. The tables are also associated with a version number. The
214 version number MUST be initialized with the value of the "version"
215 attribute from the "watcherinfo" element in the first document
216 received. Each time a new document is received, the value of the
217 local version number, and the "version" attribute in the new
218 document, are compared. If the value in the new document is one
219 higher than the local version number, the local version number is
220 increased by one, and the document is processed. If the value in the
221 document is more than one higher than the local version number, the
222 local version number is set to the value in the new document, the
223 document is processed, and the watcherinfo subscriber SHOULD generate
224 a refresh request to trigger a full state notification. If the value
225 in the document is less than the local version, the document is
226 discarded without processing.
228 The processing of the watcherinfo document depends on whether it
229 contains full or partial state. If it contains full state, indicated
230 by the value of the "state" attribute in the "watcherinfo" element,
231 the contents of all tables associated with this watcherinfo
232 subscription are flushed. They are repopulated from the document. A
233 new table is created for each "watcher-list" element, and a new row
234 in each table is created for each "watcher" element. If the
235 watcherinfo contains partial state, as indicated by the value of the
236 "state" attribute in the "watcherinfo" element, the document is used
237 to update the existing tables. For each "watcher-list" element, the
238 watcherinfo subscriber checks to see if a table exists for that list.
239 This check is done by comparing the URI in the "resource" attribute
240 of the "watcher-list" element with the URI associated with the table.
241 If a table doesn't exist for that list, one is created. For each
242 "watcher" element in the list, the watcherinfo subscriber checks to
243 see whether a row exists for that watcher. This check is done by
244 comparing the ID in the "id" attribute of the "watcher" element with
245 the ID associated with the row. If the watcher doesn't exist in the
246 table, a row is added, and its state is set to the information from
247 that "watcher" element. If the watcher does exist, its state is
248 updated to be the information from that "watcher" element. If a row
249 is updated or created, such that its state is now terminated, that
250 entry MAY be removed from the table at any time.
252 5 Example
253 The following is an example of watcher information for a presentity,
254 who is a professor. There are two watchers, userA and userB.
256
257
259
260 sip:userA@example.net
264 sip:userB@example.org
268
269
271 6 XML Schema
273 The following is the schema definition of the watcherinfo document
274 format:
276
279
280
282
283
284
285
287
289
290
292
293
294
295
296
298
299
300
301
302
303
304
305
306
307
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
353 7 Security Considerations
355 Watcher information is sensitive information. The protocol used to
356 distribute it SHOULD ensure privacy, message integrity and
357 authentication. Furthermore, the protcol should provide access
358 controls which restrict who can see who elses watcher information.
360 8 IANA Considerations
362 This document registers a new MIME type, application/watcherinfo+xml,
363 and registers a new XML namespace.
365 8.1 application/watcherinfo+xml MIME Registration
367 MIME media type name: application
369 MIME subtype name: watcherinfo+xml
371 Mandatory parameters: none
373 Optional parameters: Same as charset parameter application/xml
374 as specified in RFC 3023 [9].
376 Encoding considerations: Same as encoding considerations of
377 application/xml as specified in RFC 3023 [9].
379 Security considerations: See Section 10 of RFC 3023 [9] and
380 Section 7 of this specification.
382 Interoperability considerations: none.
384 Published specification: This document.
386 Applications which use this media type: This document type has
387 been used to support subscriber authorization functions for
388 SIP-based presence [10] [2].
390 Additional Information:
392 Magic Number: None
394 File Extension: .wif or .xml
396 Macintosh file type code: "TEXT"
398 Personal and email address for further information: Jonathan
399 Rosenberg,
401 Intended usage: COMMON
403 Author/Change controller: The IETF.
405 8.2 URN Sub-Namespace Registration for
406 urn:ietf:params:xml:ns:watcherinfo
408 This section registers a new XML namespace, as per the guidelines in
409 [7].
411 URI: The URI for this namespace is
412 urn:ietf:params:xml:ns:watcherinfo.
414 Registrant Contact: IETF, SIMPLE working group,
415 , Jonathan Rosenberg
416 .
418 XML:
420 BEGIN
421
422
424
425
426
428 Watcher Information Namespace
429
430
431 Namespace for Watcher Information
432 application/watcherinfo+xml
433 See RFCXXXX.
434
435
436 END
438 9 Contributors
440 The following people were part of the original design team that
441 developed the first version of this specification:
443 Dean Willis
444 dynamicsoft
445 5100 Tennyson Parkway, Suite 1200
446 Plano, Texas 75024
447 email: dwillis@dynamicsoft.com
449 Robert Sparks
450 dynamicsoft
451 5100 Tennyson Parkway, Suite 1200
452 Plano, Texas 75024
453 email: rsparks@dynamicsoft.com
455 Ben Campbell
456 dynamicsoft
457 5100 Tennyson Parkway, Suite 1200
458 Plano, Texas 75024
459 email: bcampbell@dynamicsoft.com
461 Henning Schulzrinne
462 Columbia University
463 M/S 0401
464 1214 Amsterdam Ave.
465 New York, NY 10027-7003
466 email: schulzrinne@cs.columbia.edu
468 Jonathan Lennox
469 Columbia University
470 M/S 0401
471 1214 Amsterdam Ave.
472 New York, NY 10027-7003
473 email: lennox@cs.columbia.edu
475 Christian Huitema
476 Microsoft Corporation
477 One Microsoft Way
478 Redmond, WA 98052-6399
479 email: huitema@microsoft.com
481 Bernard Aboba
482 Microsoft Corporation
483 One Microsoft Way
484 Redmond, WA 98052-6399
485 email: bernarda@microsoft.com
487 David Gurle
488 Microsoft Corporation
489 One Microsoft Way
490 Redmond, WA 98052-6399
491 email: dgurle@microsoft.com
493 Jonathan Lennox contributed the text for the DTD and its usage that
494 were part of earlier versions of this specification.
496 10 Acknowledgements
498 The authors would like to thank Sean Olson, Steve Donovan, and Cullen
499 Jennings for their detailed comments and assistance with the XML
500 schema.
502 11 Authors Addresses
504 Jonathan Rosenberg
505 dynamicsoft
506 72 Eagle Rock Avenue
507 East Hanover, NJ 07936
508 email: jdrosen@dynamicsoft.com
510 12 Normative References
512 [1] A. B. Roach, "Session initiation protocol (sip)-specific event
513 notification," RFC 3265, Internet Engineering Task Force, June 2002.
515 [2] J. Rosenberg, "A watcher information event template-package for
516 the session initiation protocol (SIP)," internet draft, Internet
517 Engineering Task Force, Dec. 2002. Work in progress.
519 [3] S. Bradner, "Key words for use in rfcs to indicate requirement
520 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
522 [4] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup
523 language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-
524 20001006, World Wide Web Consortium (W3C), Oct. 2000. Available at
525 http://www.w3.org/XML/.
527 [5] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
528 Force, May 1997.
530 [6] R. Moats, "A URN namespace for IETF documents," RFC 2648,
531 Internet Engineering Task Force, Aug. 1999.
533 [7] M. Mealling, "The IETF XML registry," internet draft, Internet
534 Engineering Task Force, July 2002. Work in progress.
536 [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
537 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
538 initiation protocol," RFC 3261, Internet Engineering Task Force, June
539 2002.
541 [9] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
542 3023, Internet Engineering Task Force, Jan. 2001.
544 [10] J. Rosenberg, "A presence event package for the session
545 initiation protocol (SIP)," internet draft, Internet Engineering Task
546 Force, Dec. 2002. Work in progress.
548 13 Informative References
550 [11] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
551 instant messaging," RFC 2778, Internet Engineering Task Force, Feb.
552 2000.
554 Intellectual Property Statement
556 The IETF takes no position regarding the validity or scope of any
557 intellectual property or other rights that might be claimed to
558 pertain to the implementation or use of the technology described in
559 this document or the extent to which any license under such rights
560 might or might not be available; neither does it represent that it
561 has made any effort to identify any such rights. Information on the
562 IETF's procedures with respect to rights in standards-track and
563 standards-related documentation can be found in BCP-11. Copies of
564 claims of rights made available for publication and any assurances of
565 licenses to be made available, or the result of an attempt made to
566 obtain a general license or permission for the use of such
567 proprietary rights by implementors or users of this specification can
568 be obtained from the IETF Secretariat.
570 The IETF invites any interested party to bring to its attention any
571 copyrights, patents or patent applications, or other proprietary
572 rights which may cover technology that may be required to practice
573 this standard. Please address the information to the IETF Executive
574 Director.
576 Full Copyright Statement
578 Copyright (c) The Internet Society (2003). All Rights Reserved.
580 This document and translations of it may be copied and furnished to
581 others, and derivative works that comment on or otherwise explain it
582 or assist in its implementation may be prepared, copied, published
583 and distributed, in whole or in part, without restriction of any
584 kind, provided that the above copyright notice and this paragraph are
585 included on all such copies and derivative works. However, this
586 document itself may not be modified in any way, such as by removing
587 the copyright notice or references to the Internet Society or other
588 Internet organizations, except as needed for the purpose of
589 developing Internet standards in which case the procedures for
590 copyrights defined in the Internet Standards process must be
591 followed, or as required to translate it into languages other than
592 English.
594 The limited permissions granted above are perpetual and will not be
595 revoked by the Internet Society or its successors or assigns.
597 This document and the information contained herein is provided on an
598 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
599 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
600 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
601 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
602 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.