idnits 2.17.1 draft-dusseault-rvp-schema-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 14) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 183 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 440: '...Some group nodes MAY forward users' ni...' RFC 2119 keyword, line 444: '... client MAY send the nickname...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '...listing conta...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 700 looks like a reference -- Missing reference section? '3' on line 704 looks like a reference -- Missing reference section? '1' on line 696 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jeff Bone, Activerse 3 Expires: Sept 1998 Lisa Dusseault, Microsoft 5 RVP Schemas 6 draft-dusseault-rvp-schema-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), 12 its areas, and its working groups. Note that other groups may 13 also distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as "work 18 in progress." 20 To learn the current status of any Internet-Draft, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ds.internic.net (US East Coast), 23 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 24 munnari.oz.au (Pacific Rim). 26 2. Abstract 28 The RVP protocol [2] can be used to query properties of objects, 29 subscribe to certain kinds of events, and send instant messages 30 to objects. These objects are often users, but there are other 31 classes of objects as well. 33 A schema needs to be defined which applies to all kinds of RVP 34 objects, as well as more detailed schemas for the most commonly 35 used objects, users and groups. 37 The required properties for all RVP objects include common name 38 (Cn), schema type and access control list. The required 39 properties for a user object, which represents a single human 40 user of the system, include status, status message, email address 41 and directory server address. The required properties for a 42 group object, which represents a list of objects which may be 43 messaged all at once by messaging this group, include member- 44 count and owner. 46 3. Contents 48 1. Status of this Memo.........................................1 49 2. Abstract....................................................1 50 3. Contents....................................................2 51 4. Overview....................................................3 52 4.1. The User Schema.......................................3 53 4.2. Group Schema..........................................3 54 5. Outline of a Schema.........................................4 55 5.1. Properties............................................4 56 5.2. Subscriptions Lists...................................4 57 5.3. Access Control lists..................................4 58 5.4. Timeouts..............................................4 59 5.5. Default Values........................................5 60 6. Schemas.....................................................5 61 6.1. Format of schema properties...........................5 62 6.2. All RVP Objects.......................................6 63 6.2.1. Schema-type property..............................6 64 6.2.2. Cn...............................................6 65 6.2.3. Link..............................................6 66 6.3. User Schema...........................................7 67 6.3.1. Status............................................7 68 6.3.2. Online-status.....................................7 69 6.3.3. Dir-entry.........................................8 70 6.3.4. V-Card............................................8 71 6.3.5. LastOn............................................8 72 6.3.6. LastOff...........................................8 73 6.3.7. Offline-msg.......................................9 74 6.3.8. Online-msg........................................9 75 6.3.9. Active-clients....................................9 76 6.4. Group Schema.........................................10 77 6.4.1. Online-members...................................10 78 6.4.2. Expires-offline..................................11 79 6.4.3. Multicast-addr...................................11 80 6.4.4. Max-Timeout......................................11 81 6.4.5. Total-members....................................12 82 6.4.6. Archive..........................................12 83 6.4.7. Owner............................................12 84 6.4.8. List-info........................................12 85 6.4.9. Recurses.........................................12 86 7. Extending Schemas..........................................13 87 7.1. Extending Existing Schemas...........................13 88 7.1.1. Storing private information in namespace.........13 89 7.2. Defining New Schemas.................................13 90 7.3. Auto-discovery of schemas............................14 91 8. REFERENCES.................................................14 92 9. Authors' Addresses.........................................14 94 4. Overview 95 The RVP system is designed to provide dynamic information, not 96 static information. As such, all properties of objects are 97 dynamic, RVP-specific or very frequently queried by RVP users. 98 Some static properties such as the "directory address" property 99 for users and the "list-info" property for groups are required so 100 that users can find out where static information is supposed to 101 reside. 103 4.1. The User Schema 105 The user object is the most easily understood RVP object: it 106 represents a user. Some interesting properties of a user: 108 - They can have a status of offline, active, idle or busy. 109 - They may have a directory entry with static information. 110 - They may have a message intended for other users to see when 111 they are offline. 112 - They may have a message intended for other users to see when 113 they are online. 114 - They have an access control list (ACL) which defines who can 115 see the user object and who can message the user object. 116 - They have a subscription list (SL) which defines who wants to 117 receive instant messages which are sent to this user, and who 118 wants to receive notifications of things which change (certain 119 events) on the user object. 121 There must also be an access control list for each property which 122 defines who can read and who can write this property. There may 123 also be a timeout value for each property: for example, the 124 status of "active" times out to "offline" if the user does not 125 refresh the status property with a new timeout value. 127 Every entry in a subscription list contains the RVP address of 128 the subscriber, the address to send the notification to (the 129 callback, which may be a proxy address), and the kind of 130 notification they are interested in. Each entry in the 131 subscription list may also have a timeout entry and an access 132 control list. Some access control or other security mechanism 133 for the subscription list is required so that a malicious third- 134 party cannot cancel other people's subscriptions at will, but 135 subscribers can cancel their own subscriptions. 137 4.2. Group Schema 139 The next object to define is the group schema. A group is a list 140 of RVP objects which all receive an instant message sent to the 141 group. The group is an object itself because it is in many ways 142 similar to the user object. 143 - Users can post to the group just like a user, the server 144 forwards to the members of the group. 146 - Users will want to know how many members of the group are 147 online, similar to knowing if a user is online. 149 Other aspects of groups are unique: 150 - Some groups will have a dynamic list of members who are all 151 online 152 - Some groups will have a static list of members, some of whom 153 may be online. 154 - Users may want to know what the total number of online & 155 offline members is 157 5. Outline of a Schema 158 5.1. Properties 159 Any property may have an ACL, default value, timeout value and 160 max timeout value. 162 5.2. Subscriptions Lists 163 Every entry in an SL may have an ACL and a timeout value. The SL 164 might have a max timeout value. The SL itself may also have an 165 ACL to decide who can GET the list, delete it, etc. 166 5.3. Access Control lists 168 Access Control Lists (ACL) are defined for DAV in [3]. These are 169 very flexible lists which can define access per user, per access 170 type. A user might be able to GET a property, but not SUBSCRIBE 171 to it or set it with PUT. ACL may define access by inclusion or 172 exclusion. ACLs are set on a property or object by sending an ACL 173 method message with a text/XML body. XML is flexible enough to 174 allow for additional access types and levels not foreseen here. 176 Every object and property may have an ACL. The ACL for the 177 object defines who send NOTIFY messages to the object, who can 178 SUBSCRIBE to messages from the object, who can use PUT to change 179 ACLs within the object, who can use GET to read ACLs within the 180 object, and who can DELETE the entire object. 181 For example, on a user object, SUBSCRIBE access is typically 182 granted to the user only, NOTIFY access to everybody except a few 183 people who hassle the user, and ACL/PUT/GET/DELETE access to the 184 user and their admin only. 186 An example of ACLs on a property: for the status property of a 187 user object, PUT would be restricted to the user, GET and 188 SUBSCRIBE would be granted to everybody but a few users, and 189 NOTIFY/DELETE would be meaningless and therefore might be 190 disallowed to everybody. 192 5.4. Timeouts 194 Timeout fields indicate the exact date and time when a property 195 or a list entry should expire. These fields are formatted 196 according to ISO8601. The value of the timeout field may also be 197 "never". 199 For any property which can have a timeout, the server may also 200 maintain a maximum expiry duration. For example, if a user tries 201 to set the timeout on a subscription entry for longer than a day 202 away, the server may return a message which indicates that the 203 subscription was accepted but the timeout value was set to a 204 value of the server's choosing (specified in the return message). 206 When a list entry (ACL or SL) expires, the server should delete 207 the entry. It is not required that an implementation support 208 timeouts on ACL entries. It is required that an implementation 209 support timeouts on SL entries. 211 When a property expires, the server should set the property to 212 the default value. 214 5.5. Default Values 216 Properties which can expire (have timeout fields) should also 217 have default values. When the timeout is reached, the server 218 should set the property to the default value. 220 For example, the default value for the "status" field must be 221 "offline". 223 6. Schemas 225 6.1. Format of schema properties 227 Each schema property listed hereafter has several things 228 specified. The format of the property, the value, a description 229 of what the property is for, and an example are all pretty self- 230 explanatory. 232 The "required" bit specifies whether or not this must be 233 supported by a server implementation. Properties which are 234 supported by a server may still have a null value, and where that 235 is possible this is noted explicitly. 237 The "subscribable" information specifies whether the server 238 implementation must permit subscriptions to this property. "No" 239 means that an implementation is not required to support 240 subscriptions to this property, although an implementation may 241 support it anyway. 243 The "has" entry specifies what the server needs to have for each 244 property. All properties must have an Access Control List (ACL) 245 and may have to specify certain kinds of access, such as GET, PUT 246 and SUBSCRIBE, which are explicitly included in this 247 specification. Finally, the property may have to have a timeout 248 (TO) and default value (DV). When a specific DV is required by 249 this specification, it is included. Items which are missing from 250 the "has" entry are optional. 252 6.2. All RVP Objects 254 All RVP Objects have an ACL and an SL. The SL is used to list all 255 subscriptions relating to that object, including subscriptions to 256 receive notifications sent to that object and subscriptions to 257 receive notifications when a particular property of the object 258 changes. 260 RVP objects can have content. For example, the authors envision 261 the content of an online document would be its text, and users 262 can subscribe to its properties. The issue has been raised that 263 user objects might have some sort of dynamic content to replace 264 some of their properties, but this issue has not been resolved 265 yet. In addition, all RVP Objects have the following properties: 267 6.2.1. Schema-type property 269 Format: string 270 Value: "user" | "group" | other defined schema 271 Has: ACL (put, get) 272 Required: Yes 273 Subscribable: No 274 Description: This allows the client to look up which scheme to 275 apply to the object. The client can then know what properties 276 are likely to be present. 278 Issue: We also need to define some way of showing that a new 279 schema is a sub-class of a known schema. 281 6.2.2. Cn 283 Format: String 284 Value: Common name of object 285 Has: ACL (put, get) 286 Required: Yes 287 Subscribable: No 288 Example: "Joe User" 290 6.2.3. Link 292 Format: String 293 Value: "REFER":[url] | "REFER-IM":[url] | "PROXY":[url] | 294 "LINK":[url] | null 295 Has: ACL (put, get) TO 296 Required: No 297 Subscribable: No 298 Example: REFER:rvp://host.com/joeuser 299 Description: this is how another server or client can take over 300 control of the node. A detailed discussion of referral and 301 proxying can be found in the RVP draft [2]. Linking is much 302 simpler: the LINK value merely means that this object is only a 303 pointer to an object stored elsewhere, but which this server is 304 still responsible for. 306 6.3. User Schema 308 All user objects may have the following properties in addition to 309 properties required for all objects. 311 6.3.1. Status 313 Format: String 314 Value: "offline" | "online" 315 Has: ACL (put, get, subscribe), TO, DV = "offline" 316 Required: Yes 317 Subscribable: Yes 318 Description: 320 This indicates the user's online status. Online status is used 321 only when the user's has an open TCP connection to the server 322 which is responsible for the user's status, or if UDP is used 323 between client and server then this property must be refreshed 324 before the timeout (recommended 10 minutes) or the user will be 325 marked as "offline". If the server realizes that the connection 326 is lost or the property has not been refreshed, the server is 327 responsible for marking the user as offline. Thus, 328 online/offline status is determined by the client/server 329 connection. The exception is when a client wishes to be online 330 yet appear offline (invisible). 332 6.3.2. Online-status 334 Format: String 335 Value: "available" | "busy" | "idle" 336 Has: ACL (put, get, subscribe), TO, DV = "offline" 337 Required: Yes 338 Subscribable: Yes 339 Description: 341 Idle status is determined by the user's client. If the client 342 detects no input on the system hardware after a certain time, the 343 client should set this property on the server to "idle". The 344 client may change status back to "active" if new input is 345 detected, or the server may change status to "offline" if the 346 connection is dropped or the property times out. 348 Busy status is set by the user and can be taken to mean "do not 349 disturb". The user decides when they are busy, and when they are 350 no longer busy (active). The server can change the status to 351 "offline" if the connection is dropped or the property times out. 353 Keeping these two status fields accurate, a job for clients, 354 servers and users, is important for a presence system. A user 355 should never appear as "available" if they have not touched their 356 computer (or other client) in over 15 minutes, or "online" if the 357 connection was lost. 359 6.3.3. Dir-entry 361 Format: String 362 Value: URL or blank 363 Has: ACL (put, get) 364 Required: Yes 365 Subscribable: No 366 Example: "URI:ldap://host.com:6666/o=3DABC%20Industries\, 367 c=3DUS??(cn=3DBJoe%20Users" 369 Description: this field points to the directory entry, typically 370 a LDAP URL but possibly a web page or other URL/URI, where static 371 information for the user can be found. Static information might 372 include phone number, email address, public key, etc. 374 6.3.4. V-Card 376 Format: String 377 Value: URL or blank 378 Has: ACL (put, get) 379 Required: No 380 Subscribable: No 381 Description: this field points to a location where a VCard can be 382 found for the user object. 384 6.3.5. LastOn 386 Format: date/time (RFC 1123) 387 Value: Date and time user last logged on 388 Required: No 389 Has: ACL (put, get) 390 Subscribable: No 391 Example: 06 Nov 1994 08:49:37 GMT 392 Description: This field records the last time the user became 393 active. The server should set this field. If multiple clients 394 are used, the server records the last time any client became 395 active. 397 6.3.6. LastOff 399 Format: date/time (RFC 1123) 400 Value: Date and time user last logged off (became "offline") 401 Required: No 402 Subscribable: No 403 Has: ACL (put, get) 404 Description: If the user has multiple clients, the server records 405 the last time the user was completely offline (no online 406 clients). 408 6.3.7. Offline-msg 410 Format: MIME-type, typically text/plain 411 Value: Message intended for use when user is offline 412 Has: ACL (put, get, subscribe), TO, DV. 413 Required: no 414 Subscribable: Yes 415 Example: "I'm not logged in right now, please send email." 416 Description: This message will typically be like the voice mail 417 user messages or email OOF messages. We have not decided whether 418 or not the server must return the offline-msg in response to an 419 instant message sent when the user is offline. 421 6.3.8. Online-msg 423 Format: MIME-type, typically text/plain 424 Value: Message intended for use when user is online. 425 Has: ACL (put, get, subscribe), may also have TO/DV) 426 Required: no 427 Subscribable: Yes 428 Example: "I'm chatting in #foo if anybody wants to join me." 429 Description: This message will typically offer some information 430 about what the user is doing while online. This may help other 431 users decide how to get in touch. 433 6.3.9. Nickname 435 Format: String 436 Value: User's current nickname 437 Has: ACL (put, get) 438 Required: no 439 Subscribable: no 440 Description: Some group nodes MAY forward users' nicknames, if 441 provided, rather than users' real names. These group nodes will 442 typically be those provided for social interaction rather than 443 work. In cases where the user wishes to remain anonymous, the 444 client MAY send the nickname and not the Cn (common name) with an 445 instant message. The recipient of an "anonymous" message of this 446 type may refuse it. More details need to be worked out on the 447 use of nickname. 449 6.3.10. Active-clients 451 Format: string 452 Value: List of active client for this user, or null. 453 Has: ACL (put, get), TO, DV = null 454 Required: no 455 Subscribable: No 456 Description: Frequently users will have more than one client 457 connected. Clients should have types and may have simple 458 identities. Each client type/identity is separated by a comma. 459 For example: "desktop=lisadu, desktop=lisa2, laptop=lisa, 460 cellphone=, pager=555-5555, PDA" In this example, the cellphone 461 identity is left blank because the user doesn't want their phone 462 number known that widely, and the PDA doesn't have an identity. 464 6.4. Group Schema 466 A group is similar to an email distribution list: it is a way of 467 redistributing instant messages to a list of users. A group is 468 structured similarly to users for ease of implementation. 470 Like any RVP object, the group object has a ACL and a SL. The SL 471 includes the list of users who wish to receive messages sent to 472 that group, and may also include users who wish to be notified 473 when a property of the group changes. The ACL for the group 474 object defines: 475 - who can send NOTIFY messages to the group 476 - who can GET the subscription list to see all members 477 - who can use ACL to change any of the ACLs under the group 478 object 479 - who can SUBSCRIBE to notifications sent to group 480 - who can DELETE the group object 482 Using PUT on the group object itself has no meaning. 484 An interesting aspect of groups is that in a dynamic system such 485 as RVP, group membership may also be very dynamic. For example, 486 a group such as "people looking for a ride home now" might have a 487 very dynamic member list. The server might have a maximum 488 timeout value on subscription list entries of twenty minutes 489 hence. Another group such as "members of this test team" might 490 have a very static member list, with timeout entries of "never". 492 In addition to the base object properties, the Group Schema has 493 the following properties. 495 6.4.1. Online-members 497 Format: Integer 498 Value: Number of online group members | NULL 499 Has: ACL (GET, SUBSCRIBE) 500 Required: Yes 501 Subscribable: no 502 Example: 42 503 Description: This value records the number of entities which are 504 currently online and subscribed to receive notifications sent to 505 the group, and should be maintained accurately by the server when 506 possible. 508 A value of NULL can mean several things: 509 - The number of online members is indefinite because there are 510 sub-groups 511 - The number of online members is unknown because this is a 512 public group which may be fanned out by any proxy. 514 6.4.2. Expires-offline 516 Format: Boolean 517 Value: True | False 518 Has: ACL (Get, Subscribe) 519 Required: Yes 520 Subscribable: No 521 Description: This property, which should be GETable by all 522 potential members of the list, indicates whether the server 523 expires subscription list entries when the receiver is offline. 524 If TRUE, then offline recipients are dropped from the list. This 525 occurs if the response to a message from the publishing server is 526 an error/offline or no connection. If a server ever decides to 527 drop a member from a subscription list without an explicit 528 cancellation, the server should send a subscription cancellation 529 message to the client. 531 Note that this property also indicates to the client what the 532 client is supposed to do when it goes offline. The graceful 533 thing to do when expires-offline is TRUE is for the client to 534 cancel their subscription before going offline. Similarly, if a 535 proxy server is in the call-back path and the proxy server 536 becomes aware that the subscriber has gone offline, the proxy 537 server should cancel the subscription. The ability of the 538 publishing server to drop subscriptions from the list is supposed 539 to be used only when the graceful method fails. 541 6.4.3. Multicast-addr 543 Format: IP multicast addr 544 Value: Address which messages for this group are sent to 545 Has: ACL (Get, subscribe) 546 Required: No 547 Subscribable: no 548 Description: Large and public groups may support multicast: 549 messages to the group are sent to the multicast address. If a 550 multicast address is listed here and the client supports 551 multicast, the client should listen on the multicast address 552 rather than become a member of the group. Note that use of this 553 feature improves scalability but eliminates read ACLs. 555 6.4.4. Max-Timeout 557 Format: Integer 558 Value: Number of seconds 559 Has: ACL (GET, PUT) 560 Required: Yes 561 Subscribable: no 562 Example: 3600 563 Description: The max-timeout value should be queryable in most 564 cases, by most potential list members. A max-timeout of 0 565 indicates "never": users can subscribe to this list without any 566 timeout on their subscriptions. 568 6.4.5. Total-members 570 Format: Integer 571 Value: Number of offline & online members | NULL 572 Has: ACL (get, put) 573 Required: Yes 574 Subscribable: no 575 Example: 58 576 Description: The value of this property is different from the 577 online-members property only for lists for which expires-offline 578 is false. The NULL value indicates the number of members is 579 unknown or uncertain. 581 6.4.6. Archive 583 Format: URL 584 Value: Location of archives | Null 585 Has: ACL (Get, put) 586 Required: No 587 Subscribable: no 588 Example: http://host.com/archives/rvpdisc 589 Description: if archives of this list are stored, this points to 590 them. 592 6.4.7. Owner 594 Format: URL 595 Value: Pointer to owner/moderator of list | Null 596 Has: ACL (Get,put) 597 Required: No 598 Subscribable: no 599 Example: rvp://host.com/joeuser 600 Description: This could be a RVP URL, mailto URL, web-page with 601 list of URLs, or other pointer to the owner/moderator of the 602 list. 604 6.4.8. List-info 606 Format: URL 607 Value: Pointer to more information about the list | Null 608 Has: ACL (Get, put) 609 Required: No 610 Subscribable: No 611 Example: http://host.com/protocols/rvpdisc/policies.html 612 Description: Any further information about the list, such as 613 requirements for getting onto the list, rules of behavior etc, 614 should be at the list-info URL or linked to from there. 616 6.4.9. Recurses 618 Format: Boolean 619 Value: True | False 620 Has: ACL (GET, PUT) 621 Required: No 622 Subscribable: No 623 Description: If the server supports recursion of groups, and if 624 the value of "recurses" for a group is "true", then a message 625 sent to that group will also be sent to all child nodes of that 626 group. This allows large groups which don't have individual 627 members but which have child nodes, or groups which make up the 628 larger group. For example, the group 630 rvp://host.com/groups/rvpdisc 632 could have child nodes 634 rvp://host.com/groups/rvpdisc/newschemas 635 rvp://host.com/groups/rvpdisc/prot-methods 637 If recurses is set to true for rvpdisc, then both sub-groups 638 receive a message sent to rvpdisc. 640 7. Extending Schemas 642 7.1. Extending Existing Schemas 644 The user and group schemas are bound to be extended, with 645 properties for users such as "phone-status". Extensions to 646 existing, known schemas should always add, and not take away. If 647 this guideline is followed, then the extensions can all be listed 648 in this property after the base schema name, or in a new 649 property. Old clients which understand the "user" schema but not 650 any of the extensions can then ignore the extensions. The format 651 for listing extensions is undefined and suggestions are welcome. 653 When an extension to a schema is defined, it should be published 654 with a unique name. 656 7.1.1. Storing private information in namespace 657 This is entirely an optional feature. Servers may store 658 information in the namespace which is only intended for the 659 server and any of its users to get and set. For example, if a 660 user has a number of subscriptions which they wish to have active 661 every time they are online, then to minimize logon time the 662 server may allow the subscription information to be stored online 663 somewhere under the user's node in the namespace. When the user 664 logs on, the user may send a command to tell the user to activate 665 all the subscriptions stored in a particular location in the 666 local namespace. 668 7.2. Defining New Schemas 669 New schemas must be clearly justified and specified, published 670 and assigned a unique name. 672 A new schema type of "automaton" has been suggested, with 673 potential sub-types of "gateway" and "archiver". This would 674 clearly identify automatic and special-purpose processes. 676 7.3. Auto-discovery of schemas 678 An unknown object can first be identified by the schema-type 679 property. However, the value of this field may not be known by 680 the client. It would be desirable to define a mechanism through 681 which the new schemas may be discovered on-the-fly. 683 This mechanism would have to communicate the name, format and 684 presence of SL/ACL/TO fields for each undefined property of the 685 schema. The name would have to be included so that a user could 686 decide whether to view the property, the format so that the 687 client could guess how to display the property, and the presence 688 of SL/ACL/TO information so that the client knows what may be 689 done with the property. 691 This mechanism could also be used to discover the nature of 692 extensions to known schemas. 694 8. REFERENCES 696 [1] S. Bradner, "Key words for use in RFCs to indicate 697 requirement levels," RFC 2119, Internet Engineering Task Force, 698 Mar. 1997. 700 [2] M. Calsyn, L. Dusseault and G. Mohr, "RVP: A Presence 701 Information Protocol", INTERNET-DRAFT , 702 March 1998 704 [3] Leach P. and Goland Y., "WebDAV ACL Protocol", INTERNET-DRAFT 705 , November 1997. 708 9. Authors' Addresses 710 Lisa Dusseault 712 Microsoft Corporation 713 One Microsoft Way 714 Redmond, WA 98052 715 EMail: lisadu@microsoft.com 717 Jeff Bone 719 Activerse, Inc. 720 1301 W. 25th St 721 Suite 500 722 Austin, TX 78705 723 Email: jbone@activerse.com