idnits 2.17.1 draft-ietf-calsch-locating-00.txt: 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 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 2 longer pages, the longest (page 12) being 66 lines 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 108 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 382: '... MAY (calCalURI calFBU...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 11, 1998) is 9451 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) -- Missing reference section? '10' on line 553 looks like a reference -- Missing reference section? '13' on line 569 looks like a reference -- Missing reference section? '14' on line 578 looks like a reference -- Missing reference section? '8' on line 545 looks like a reference -- Missing reference section? '7' on line 541 looks like a reference -- Missing reference section? '5' on line 534 looks like a reference -- Missing reference section? '6' on line 537 looks like a reference -- Missing reference section? '4' on line 531 looks like a reference -- Missing reference section? '2' on line 522 looks like a reference -- Missing reference section? '1' on line 518 looks like a reference -- Missing reference section? '3' on line 526 looks like a reference -- Missing reference section? '9' on line 549 looks like a reference -- Missing reference section? '11' on line 561 looks like a reference -- Missing reference section? '12' on line 566 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Small, Microsoft Corporation 3 INTERNET-DRAFT Denis Hennessy, ISOCOR 4 Calendaring and Scheduling Working Group 5 Frank Dawson, Lotus 7 Expires six months from June 11, 1998 8 Calendar attributes for vCard and LDAP 10 draft-ietf-calsch-locating-00.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 33 When scheduling a calendar entity, such as an event, it is a 34 prerequisite that an organizer has the calendar address of each 35 attendee that will be invited to the event. Additionally, access to an 36 attendee's current "busy time" provides an a priori indication of 37 whether the attendee will be free to participate in the event. 38 In order to meet these challenges, a calendar user agent (CUA) needs a 39 mechanism to locate (URI) individual user's calendar and free/busy 40 time. 42 This draft defines three mechanisms for obtaining a URI to a user's 43 calendar and free/busy time. These include: 45 - Manual transfer of the information; 46 - Personal data exchange using the vCard format; and 47 - Directory lookup using the LDAP protocol. 49 1. URIs 51 This draft defines four classes of URIs. URIs are more useful if it is 53 understood what the URIs point to. Here is a brief description: 55 1.1. Free/Busy URI (FBURL) 57 The free/busy URI is defined to be a transport independent location 58 where a client can obtain information about when a user is busy. At the 59 present time, this URI only points to busy time data. Future revisions 60 of this specification may provide for the extended capability of 61 publishing free time data. 63 If a calendaring and scheduling client (i.e., CUA) were to retrieve 64 data from this location using FTP or HTTP, it would get back an 65 iCalendar object [10] containing one or more "VFREEBUSY" calendar 66 components. If a MIME transport is being used, the response will be 67 contained within a "text/calendar" MIME body part as specified in the 68 iCalendar specification [10]. For example: 70 BEGIN:VCALENDAR 71 VERSION:2.0 72 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 73 METHOD:PUBLISH 74 BEGIN:VFREEBUSY 75 ATTENDEE:MAILTO:jane_doe@host1.com 76 DTSTART:19971013T050000Z 77 DTEND:19971124T050000Z 78 DTSTAMP:19970901T083000Z 79 FREEBUSY:19971015T133000Z/19971015T180000Z 80 FREEBUSY:19971015T190000Z/19971015T220000Z 81 FBURL:http://www.host.com/calendar/busy/jdoe.ifb 82 END:VFREEBUSY 83 END:VCALENDAR 85 The amount of busy time data pointed to by the FBURL will generally be 86 pre-determined; for example one month of free/busy inforation. As a 87 guideline, it is recommended that the previous six weeks of busy time 88 data be published at the location associated with the FBURL. If this 89 URI points to a file resource, it is recommended that the file 90 extension be "ifb" to distinguish it from an arbitrary iCalendar 91 object. 93 1.2 Calendar Address URI (CALADRURI) 95 The calendar address URI is defined to be a transport independent 96 communication end-point for a user. The organizer's calendaring and 97 scheduling client (ie. CUA) would use this URI to determine where to 98 send an event request when organizing a meeting with a particular 99 attendee. 101 If the user prefers to receive event requests via iMIP, then the user 102 would provide a "mailto" URI containing the user's e-mail address. [13] 103 For example: 105 "mailto:user@host1.com" 106 The URI for an iRIP user is yet to be defined, but that is another 107 possible URI value in this property. [14] 109 1.3. Calendar Access URI (CAPURI) 111 The Calendar Access URI is defined to be a protocol independent 112 location from which a calendaring and scheduling client (i.e., CUA) can 113 communicate with a user's entire calendar. 115 The semantics for using this URI as an access protocol locator are yet 116 to be defined by the IETF CALSCH Working Group. This will be addressed 117 in the "Calendar Access Protocol" specification. 119 1.4 Calendar URI (CALURI) 121 The Calendar URI is defined to be a protocol independent location from 122 which a calendaring and scheduling client (ie. CUA) can retrieve an 123 entire copy of a user's calendar. Retrieving data from this URI 124 obtains a published "snapshot" of the user's calendar. 126 HTTP URI -- If the URI is an HTTP URI, then the content returned with a 127 GET should be a "text/calendar" MIME body part containing one or more 128 iCalendar object. 130 FTP URI -- If the URI is an FTP URI, then the resource pointed to 131 should be a file with an "ics" file extension containing one or more 132 iCalendar objects. 134 1.5. Default URIs 136 There are many cases where a user may have more than one calendar. In 137 these cases, a user may have multiple URIs, each URI pointing to a 138 calendar or free/busy data. 140 To make the case of multiple calendars simpler for clients, the concept 141 of the "default" calendar is introduced. A "default" calendar is one 142 that the user has designated as the calendar that other users should 143 look at when accessing the user's calendar, or retrieving the user's 144 free/busy time. 146 The default calendar may, in fact, include rolled-up information from 147 all the user's other calendars. The other calendars may only exist for 148 organizational purposes. 150 2. Distribution 152 These four URIs provide valuable pointers to calendaring and scheduling 153 data that other users need in order to know when to schedule meetings, 154 etc. There are several possibilities on how users can communicate 155 these URIs to other users. The following section outlines how these 156 URIs can be distributed to other users. 158 2.1. Manual Transfer 160 The simplest way to obtain these URIs is for a user to communicate the 161 URIs using some out-of-band mechanism such as verbally, or in an e-mail 162 message, or by printing these URIs on a paper business card. 164 When using this mechanism, the user obtains these URIs using an out-of- 165 band mechanism and then enters these URIs into their calendaring 166 software manually. 168 2.2. Personal Data Exchange Using A vCard 170 A more sophisticated way to obtain these URIs is for users to publish 171 vCards containing these URIs. The vCard object can be transferred 172 between one another. Since many e-mail clients allow a user to 173 automatically include a vCard with every message that the user sends, 174 this provides a simple, transparent way for a user to distribute their 175 calendaring and scheduling URIs. 177 On the receiving end, an e-mail client that provides an integrated 178 vCard database can provide a way to lookup calendaring URIs for users 179 whose vCards are stored locally. 181 2.2.1. vCard Schema Extensions 183 Since the vCard [8] specification doesn't specify how to encode 184 calendaring URIs in a vCard, this section is provided as an extension 185 to vCard which specifies how to encode calendaring URIs within a vCard. 187 Inside a vCard object, four new properties are defined: "CALURI", 188 _CAPURI_, _CALADRURI_, and "FBURL", as defined above. 190 Any vCard can have one or more of these properties, each representing a 191 calendar or free/busy time that is associated with the user. 193 One of these properties can be designated as the "default" by adding 194 the "PREF" parameter. 196 Here is a simple example of a vCard containing a "FBURL" and a 197 "CALURI". 199 BEGIN:VCARD 200 VERSION:3.0 201 FN:Alec Dun 202 N:Dun;Alec 203 ORG:Microsoft Corporation 204 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 205 Redmond;WA;98052-6399;USA 206 TEL;WORK;MSG:+1-206-936-4544 207 TEL;WORK;FAX:+1-206-936-7329 208 EMAIL;INTERNET:user@host1.com 209 CALADRURI;PREF:mailto:user@host1.com 210 CALURI;PREF:http://cal.host1.com/user/cal.ics 211 FBURL;PREF:http://cal.host1.com/user/fb.ifb 212 CALURI:http://cal.company.com/projectA/pjtA.ics 213 FBURL:http://cal.company.com/projectA/pjtAfb.ifb 214 END:VCARD 216 2.2.1.1 FBURL Property IANA Registration 218 To: ietf-mime-directory@imc.org 219 Subject: Registration of FBURL type for text/directory MIME type 220 vCard profile. 221 Type name: FBURL 222 Type purpose: To specify the URI for a user's busy time in a vCard 223 object. 224 Type encoding: 8bit 225 Type value: A single URI value. 226 Type special notes: Where multiple FBURL properties are specified, 227 the default FBURL property is indicated with the PREF 228 parameter. The FTP or HTTP type of URI points to an iCalendar 229 object associated with a snapshot of the last six weeks of the 230 user's busy time data. If the iCalendar object is represented 231 as a file or document, it's file type should be "ifb". 232 Intended usage: Refer to section 1.1. 234 Type examples: 235 FBURL;PREF:http://www.host1.com/busy/janedoe 236 FBURL:FTP://ftp.host.com/busy/project-a.ifb 238 2.2.1.2 CALADRURI Property IANA Registration 240 To: ietf-mime-directory@imc.org 241 Subject: Registration of CALADRURI type for application/directory 242 MIME type vCard profile. 243 Type name: CALADRURI 244 Type purpose: To specify the location to which an event request 245 should be sent for the user. 246 Type encoding: 8bit 247 Type value: A single URI value. 248 Type special notes: Where multiple CALADRURI properties are 249 specified, the default CALADRURI property is indicated with the 250 PREF parameter. 251 Intended usage: Refer to section 1.2. 253 Type examples: 254 CALADRURI;PREF:mailto:janedoe@host.com 256 2.2.1.3 CAPURI Property IANA Registration 258 To: ietf-mime-directory@imc.org 259 Subject: Registration of CAPURI type for application/directory MIME 260 type vCard profile. 261 Type name: CAPURI 262 Type purpose: To specify a protocol independent location from which 263 a calendaring and scheduling client (i.e., CUA) can communicate 264 with a user's entire calendar. 265 Type encoding: 8bit 266 Type value: A single URI value. 267 Type special notes: Where multiple CAPURI properties are specified, 268 the default CAPURI property is indicated with the PREF 269 parameter. 270 Intended usage: Refer to section 1.3. 272 2.2.1.4 CALURI Property IANA Registration 274 To: ietf-mime-directory@imc.org 275 Subject: Registration of CALURI type for text/directory MIME type 276 vCard profile. 277 Type name: CALURI 278 Type purpose: To specify the URI for a user's calendar in a vCard 279 object. 280 Type encoding: 8bit 281 Type valuetype: A single URI value. 282 Type special notes: Where multiple CALURI properties are specified, 283 the default CALURI property is indicated with the PREF 284 parameter. The property should contain a URI pointing to an 285 iCalendar object associated with a snapshot of the user's 286 calendar store. If the iCalendar object is represented as a 287 file or document, it's file type should be "ics". 288 Intended usage: Refer to section 1.4. 290 Type examples: 291 CALURI;PREF:http://cal.host1.com/calA 292 CALURI:ftp://ftp.host1.com/calA.ics 294 2.3. Directory Lookup Using The LDAP v3 Protocol 296 Another way to obtain these URIs is to look them up in a directory 297 using the LDAP protocol. 299 If an organizer knows an attendee's e-mail address, then using DNS, 300 the attendee's directory server can be found. The mechanism for this 301 is described in detail in [7]. From the directory server, the client 302 can look up the URLs for a user's calendar. Here's a summary of how it 303 works. For more detail, please see the draft [7]. 305 The client first parses the domain name out from the rfc822 mailbox 306 name. For the fictitious mailbox "janedoe@host1.com", the domain name 307 would be "host1.com". 309 Given the domain name, the client prepends "ldap.tcp" to the domain 310 name and formulating a host. Next the client retrieves the queries the 311 DNS server for the SRV record for "ldap.tcp.host1.com". The mechanism 312 for adding "ldap.tcp" onto the original domain name is described in 313 detail in [5]. The DNS server returns the IP address for the 314 associated server for 'ldap.tcp.host1.com'. 316 Once the IP address for the LDAP server has been obtained, the client 317 constructs a DN from which to search using the DNS name. In this case, 318 it would be "DC=host1,DC=COM". The mechanism to construct the DN is 319 described in detail in [6]. With the IP address and the DN, the client 320 issues a search request to the server where the attribute named "mail" 321 [4] "equalityMatch"es the user's email address. From the first 322 matching entry, client obtains the calendaring and scheduling URLs. 324 If a user's URIs can be found using directory lookup, they should, in 325 general, be considered "more up-to-date" than URIs in any vCards that 326 are stored locally. 328 2.3.1. LDAP Schema Extensions 330 In order to encode the calendaring URIs in the directory, the following 331 are defined: 333 one object class: 335 @ calEntry 337 and eight attributes: 339 @ calCalURI 340 @ calFBURL 341 @ calCAPURI 342 @ calCalAdrURI 343 @ calOtherCalURIs 344 @ calOtherFBURLs 345 @ calOtherCAPURIs 346 @ calOtherCalAdrURIs 348 The calCalURI contains the URI to a snapshot of the user's entire 349 default calendar. The calFBURL contains the URI to the user's default 350 busy time data. The calCAPURI represents contains a URI that can be 351 used to communicate with the user's calendar. The calCalAdrURI 352 contains a URI that points to the location to which event requests 353 should be sent for that user. 355 The calOtherCalURIs is a multi-valued property containing URIs to 356 snapshots of other calendars that the user may have. The 357 calOtherFBURLs is a multi-valued property containing URIs to other 358 free/busy data that the user may have. The calOtherCAPURIs attribute 359 is a multi-valued property containing URIs to other calendars that the 360 user may have. The calOtherCalAdrURIs attribute is a multi-valued 361 property containing URIs to other locations that a user may want event 362 requests sent to. 364 There is no predetermined order to the values in either multi-valued 365 property. 367 2.3.2. Notation 369 The notation used in this document is the same as that used in [2]. 371 2.3.3. Object Definitions 373 2.3.3.1. calEntry 375 The Calendar Entry is a class derived from _TOP_ [2], which contains 376 the four calendaring attributes. 378 ( 1.2.840.113556.1.5.87 379 NAME 'calEntry' 380 TOP 381 AUXILIARY 382 MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs 383 calCAPURI calOtherCAPURLs) 384 ) 386 2.3.4. Attribute Definitions 388 2.3.4.1. calCalURI 390 ( 1.2.840.113556.1.4.478 391 NAME 'calCalURI' 392 EQUALITY caseIgnoreMatch 393 SUBSTRING caseIgnoreMatch 394 SYNTAX 'Directory String' 395 USAGE userApplications 396 ) 398 2.3.4.2. calFBURL 399 ( 1.2.840.113556.1.4.479 400 NAME 'calFBURL' 401 EQUALITY caseIgnoreMatch 402 SUBSTRING caseIgnoreMatch 403 SYNTAX 'Directory String' 404 USAGE userApplications 405 ) 407 2.3.4.3. calCAPURI 409 ( 1.2.840.113556.1.4.480 410 NAME 'calCAPURI' 411 EQUALITY caseIgnoreMatch 412 SUBSTRING caseIgnoreMatch 413 SYNTAX 'Directory String' 414 USAGE userApplications 415 ) 417 2.3.4.4. calCalAdrURI 419 ( 1.2.840.113556.1.4.481 420 NAME 'calCalAdrURI' 421 EQUALITY caseIgnoreMatch 422 SUBSTRING caseIgnoreMatch 423 SYNTAX 'Directory String' 424 USAGE userApplications 425 ) 427 2.3.4.5. calOtherCalURIs 429 ( 1.2.840.113556.1.4.482 430 NAME 'calOtherCalURIs' 431 EQUALITY caseIgnoreMatch 432 SUBSTRING caseIgnoreMatch 433 SYNTAX 'Directory String' 434 MULTI-VALUE 435 USAGE userApplications 436 ) 438 2.3.4.6. calOtherFBURLs 440 ( 1.2.840.113556.1.4.483 441 NAME 'calOtherFBURLs' 442 EQUALITY caseIgnoreMatch 443 SUBSTRING caseIgnoreMatch 444 SYNTAX 'Directory String' 445 MULTI-VALUE 446 USAGE userApplications 447 ) 449 2.3.4.7. calOtherCAPURIs 451 ( 1.2.840.113556.1.4.484 452 NAME 'calOtherCAPURIs' 453 EQUALITY caseIgnoreMatch 454 SUBSTRING caseIgnoreMatch 455 SYNTAX 'Directory String' 456 MULTI-VALUE 457 USAGE userApplications 458 ) 460 2.3.4.8. calOtherCalAdrURIs 462 ( 1.2.840.113556.1.4.485 463 NAME 'calOtherCalAdrURIs' 464 EQUALITY caseIgnoreMatch 465 SUBSTRING caseIgnoreMatch 466 SYNTAX 'Directory String' 467 MULTI-VALUE 468 USAGE userApplications 469 ) 471 Authors' Addresses 473 BEGIN:VCARD 474 VERSION:2.1 475 N:Small;Tony 476 FN:Tony Small 478 ORG:Microsoft Corporation 479 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 480 Redmond;WA;98052-6399;USA 481 TEL;WORK;MSG:+1-425-703-2190 482 TEL;WORK;FAX:+1-206-936-7329 483 EMAIL;INTERNET:tonysm@Microsoft.com 484 CALADRURI:MAIL-TO:tonysm@Microsoft.com 485 END:VCARD 487 BEGIN:VCARD 488 VERSION:2.1 489 N:Hennessy;Denis 490 FN:Denis Hennessy 491 ORG:ISOCOR 492 ADR;WORK;POSTAL;PARCEL:;;42-47 Lower Mount St; 493 Dublin 2;Ireland 494 TEL;WORK;MSG:+353-1-676-0366 495 TEL;WORK;FAX:+353-1-676-0856 496 EMAIL;INTERNET:denis.hennessy@isocor.com 497 CALADRURI:MAIL-TO:denis.hennessy@isocor.com 498 END:VCARD 500 BEGIN:VCARD 501 VERSION:2.1 502 N:Dawson;Frank 503 FN:Frank Dawson 504 ORG:Lotus Development Corporation 505 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; 506 Raleigh;NC;27613-3502;USA 507 TEL;WORK;MSG:+1-919-676-9515 508 TEL;WORK;FAX:+1-919-676-9564 509 EMAIL;INTERNET;PREF:Frank_Dawson@Lotus.com 510 EMAIL;INTERNET:fdawson@earthlink.net 511 CALADRURI;PREF:MAIL-TO:Frank_Dawson@Lotus.com 512 CALADRURI:MAIL-TO:fdawson@earthlink.net 513 URI:http://home.earthlink.net/~fdawson 514 END:VCARD 516 Bibliography 518 [1] M. Wahl, T. Howes, S. Kille, 'Lightweight Directory Access 519 Protocol (v3)', RFC 2251, December 1997, 520 522 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight Directory 523 Access Protocol (v3): Attribute Syntax Definitions', RFC 2252, 524 December 1997, 526 [3] M. Wahl, A Summary of the X.500(96) User Schema for use with 527 LDAPv3', 528 RFC 2256, December 1997, 529 531 [4] The Directory: Selected Attribute Types. ITU-T Recommendation 532 X.520, 1993. 534 [5] The Directory: Selected Object Classes. ITU-T Recommendation 535 X.521, 1993. 537 [6] P. Leach `Selecting a server from among many replicas', 538 INTERNET DRAFT , 539 February 1997 541 [7] P. Leach `Locating Native Internet LDAP Servers', 542 INTERNET DRAFT , 543 March 1997 545 [8] F. Dawson, T. Howes, 'vCard MIME Directory Profile', 546 INTERNET-DRAFT , 547 July 1997 549 [9] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location 550 of services (DNS SRV)", RFC 2052, 551 , October 1996. 553 [10] F. Dawson, D. Stenerson 'Internet Calendaring and Scheduling 554 Core Ojbect Specification (iCalendar)', Nov 1997, 555 561 [11] Mockapetris, P., "Domain Names - Implementation and 562 Specification", STD 13, RFC 1035, USC/Information Sciences 563 Institute, November 1987. 564 566 [12] Network Applications Consortium 'Lightweight Internet Person 567 Schema', April 1997, 569 [13] F. Dawson, S. Mansour `iCalendar Message-Based Interopability 570 Protocal (iMIP)', March 1998, 572 578 [14] A. 580 Courtemanche, S. Mansour, P. O'Leary `iCalendar Real-Time 581 Interopability Protocol ( 583 iRIP)', November 1997,