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.