idnits 2.17.1 draft-ietf-calsch-locating-03.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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1008 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 an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 25 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 452: '... MAY (calCalURI calFBURL calOtherC...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 21, 1999) is 9069 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? '4' on line 668 looks like a reference -- Missing reference section? '5' on line 672 looks like a reference -- Missing reference section? '3' on line 665 looks like a reference -- Missing reference section? '1' on line 657 looks like a reference -- Missing reference section? '2' on line 661 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Small, Microsoft Corporation 2 INTERNET-DRAFT Denis Hennessy, ISOCOR 3 Calendaring and Scheduling Working Group Frank Dawson, Lotus 4 Expires six months after June 21, 1999 6 Calendar attributes for vCard and LDAP 8 draft-ietf-calsch-locating-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet- Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this document is unlimited. 30 Copyright (C) The Internet Society 1999. All Rights Reserved. 32 Abstract 34 When scheduling a calendar entity, such as an event, it is a 35 prerequisite that an organizer has the calendar address of each attendee 36 that will be invited to the event. Additionally, access to an attendee's 37 current "busy time" provides an a priori indication of whether the 38 attendee will be free to participate in the event. 40 In order to meet these challenges, a calendar user agent (CUA) needs a 41 mechanism to locate (URI) individual user's calendar and free/busy time. 43 This memo defines three mechanisms for obtaining a URI to a user's 44 calendar and free/busy time. These include: 46 - Manual transfer of the information; 48 - Personal data exchange using the vCard format; and 50 Small, Hennessy, Dawson -- Page 1 -- ExpiresDecember 1999 51 - Directory lookup using the LDAP protocol. 53 Small, Hennessy, Dawson -- Page 2 -- Expires December 1999 54 Table of Contents 56 1 CALENDARING AND SCHEDULING URIS......................................5 58 1.1 FREE/BUSY URI (FBURL) ............................................5 59 1.2 CALENDAR ADDRESS URI (CALADRURI) .................................6 60 1.3 CALENDAR ACCESS URI (CAPURI) .....................................6 61 1.4 CALENDAR URI (CALURI) ............................................6 62 1.5 DEFAULT URIS .....................................................7 64 2 DISTRIBUTION.........................................................7 66 2.1 MANUAL TRANSFER ..................................................7 67 2.2 PERSONAL DATA EXCHANGE USING A VCARD .............................7 68 2.3 VCARD SCHEMA EXTENSIONS ..........................................8 69 2.3.1 FBURL Property IANA Registration ..............................8 70 2.3.2 CALADRURI Property IANA Registration ..........................9 71 2.3.3 CAPURI Property IANA Registration ............................10 72 2.3.4 CALURI Property IANA Registration ............................10 73 2.4 DIRECTORY LOOKUP USING THE LDAP V3 PROTOCOL .....................11 74 2.4.1 LDAP Schema Extensions .......................................11 75 2.4.2 Notation .....................................................12 76 2.4.3 Object Definitions ...........................................12 77 2.4.3.1 calEntry .................................................12 78 2.4.4 Attribute Definitions ........................................12 79 2.4.4.1 calCalURI ................................................12 80 2.4.4.2 calFBURL .................................................13 81 2.4.4.3 calCAPURI ................................................13 82 2.4.4.4 calCalAdrURI .............................................13 83 2.4.4.5 calOtherCalURIs ..........................................13 84 2.4.4.6 calOtherFBURLs ...........................................14 85 2.4.4.7 calOtherCAPURIs ..........................................14 86 2.4.4.8 calOtherCalAdrURIs .......................................14 88 3 IANA CONSIDERATIONS.................................................14 90 4 SECURITY CONSIDERATIONS.............................................15 92 5 ACKNOWLEDGMENTS.....................................................15 94 6 AUTHORS'S ADDRESSES.................................................15 96 Small, Hennessy, Dawson -- Page 3 -- Expires December 1999 97 7 BIBLIOGRAPHY........................................................17 99 8 FULL COPYRIGHT STATEMENTS...........................................17 101 Small, Hennessy, Dawson -- Page 4 -- Expires December 1999 102 1 Calendaring and Scheduling URIs 104 This memo defines four classes of URIs. URIs are more useful if it is 105 understood what the URIs point to. Here is a brief description: 107 1.1 Free/Busy URI (FBURL) 109 The free/busy URI is defined to be a transport independent location 110 where a client can obtain information about when a user is busy. At the 111 present time, this URI only points to busy time data. Future revisions 112 of this specification may provide for the extended capability of 113 publishing free time data. 115 If a calendaring and scheduling client (i.e., CUA) were to retrieve data 116 from this location using FTP or HTTP, it would get back an iCalendar 117 object [4] containing one or more "VFREEBUSY" calendar components. If a 118 MIME transport is being used, the response will be contained within a 119 "text/calendar" MIME body part as specified in the iCalendar 120 specification [4]. For example: 122 BEGIN:VCALENDAR 123 VERSION:2.0 124 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 125 METHOD:PUBLISH 126 BEGIN:VFREEBUSY 127 ATTENDEE:MAILTO:jane_doe@host1.com 128 DTSTART:19971013T050000Z 129 DTEND:19971124T050000Z 130 DTSTAMP:19970901T083000Z 131 FREEBUSY:19971015T133000Z/19971015T180000Z 132 FREEBUSY:19971015T190000Z/19971015T220000Z 133 FBURL:http://www.host.com/calendar/busy/jdoe.ifb 134 END:VFREEBUSY 135 END:VCALENDAR 137 The amount of busy time data pointed to by the FBURL will generally be 138 pre-determined; for example one month of busy time data. As a guideline, 139 it is recommended that the previous six weeks of busy time data be 140 published at the location associated with the FBURL. If this URI points 141 to a file resource, it is recommended that the file extension be "ifb" 142 to distinguish it from an arbitrary iCalendar object (e.g., with the 143 "ics" file extension). 145 Small, Hennessy, Dawson -- Page 5 -- Expires December 1999 146 1.2 Calendar Address URI (CALADRURI) 148 The calendar address URI is defined to be a transport independent 149 communication end-point for a user. The organizer's calendaring and 150 scheduling client (ie. CUA) would use this URI to determine where to 151 send an event request when organizing a meeting with a particular 152 attendee. 154 If the user prefers to receive event requests via iMIP, then the user 155 would provide a "mailto" URI containing the user's e-mail address. [5] 156 For example: 158 mailto:user@host1.com 160 The URI for an iRIP user is yet to be defined, but that is another 161 possible URI value in this property. 163 1.3 Calendar Access URI (CAPURI) 165 The Calendar Access URI is defined to be a protocol independent location 166 from which a calendaring and scheduling client (i.e., CUA) can 167 communicate with a user's entire calendar. 169 The semantics for using this URI as an access protocol locator are yet 170 to be defined by the IETF CALSCH Working Group. This will be addressed 171 in the "Calendar Access Protocol" specification. 173 1.4 Calendar URI (CALURI) 175 The Calendar URI is defined to be a protocol independent location from 176 which a calendaring and scheduling client (i.e. CUA) can retrieve an 177 entire copy of a user's calendar. Retrieving data from this URI obtains 178 a published "snapshot" of the user's calendar. 180 HTTP URI -- If the URI is an HTTP URI, then the content returned with a 181 GET should be a "text/calendar" MIME body part containing one or more 182 iCalendar object. 184 FTP URI -- If the URI is an FTP URI, then the resource pointed to should 185 be a file with an "ics" file extension containing one or more iCalendar 186 objects. 188 Small, Hennessy, Dawson -- Page 6 -- Expires December 1999 189 1.5 Default URIs 191 There are many cases where a user may have more than one calendar. In 192 these cases, a user may have multiple URIs, each URI pointing to a 193 calendar or free/busy data. 195 To make the case of multiple calendars simpler for clients, the concept 196 of the "default" calendar is introduced. A "default" calendar is one 197 that the user has designated as the calendar that other users should 198 look at when accessing the user's calendar, or retrieving the user's 199 free/busy time. 201 The default calendar may, in fact, include rolled-up information from 202 all the user's other calendars. The other calendars may only exist for 203 organizational purposes. 205 2 Distribution 207 These four URIs provide valuable pointers to calendaring and scheduling 208 data that other users need in order to know when to schedule meetings, 209 etc. There are several possibilities on how users can communicate these 210 URIs to other users. The following section outlines how these URIs can 211 be distributed to other users. 213 2.1 Manual Transfer 215 The simplest way to obtain these URIs is for a user to communicate the 216 URIs using some out-of-band mechanism such as verbally, or in an e-mail 217 message, or by printing these URIs on a paper business card. 219 When using this mechanism, the user obtains these URIs using an out-of- 220 band mechanism and then enters these URIs into their calendaring 221 software manually. 223 2.2 Personal Data Exchange Using A vCard 225 A more sophisticated way to obtain these URIs is for users to publish 226 vCards containing these URIs. The vCard object can be transferred 227 between one another. Since many e-mail clients allow a user to 228 automatically include a vCard with every message that the user sends, 229 this provides a simple, transparent way for a user to distribute their 230 calendaring and scheduling URIs. 232 On the receiving end, an e-mail client that provides an integrated vCard 233 database can provide a way to lookup calendaring URIs for users whose 234 vCards are stored locally. 236 Small, Hennessy, Dawson -- Page 7 -- Expires December 1999 237 2.3 vCard Schema Extensions 239 Since the vCard [3] specification doesn't specify how to encode 240 calendaring URIs in a vCard, this section is provided as an extension to 241 vCard which specifies how to encode calendaring URIs within a vCard. 243 Inside a vCard object, four new properties are defined: "CALURI", 244 "CAPURI", "CALADRURI", and "FBURL", as defined above. 246 Any vCard can have one or more of these properties, each representing a 247 calendar or free/busy time that is associated with the user. 249 One of these properties can be designated as the "default" by adding the 250 "PREF" parameter. 252 Here is a simple example of a vCard containing a "FBURL" and a "CALURI". 254 BEGIN:VCARD 255 VERSION:3.0 256 N:Dun;Alec 257 FN:Alec Dun 258 ORG:Microsoft Corporation 259 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 260 Redmond;WA;98052-6399;USA 261 TEL;WORK;MSG:+1-206-936-4544 262 TEL;WORK;FAX:+1-206-936-7329 263 EMAIL;INTERNET:user@host1.com 264 CALADRURI;PREF:mailto:user@host1.com 265 CALURI;PREF:http://cal.host1.com/user/cal.ics 266 FBURL;PREF:http://cal.host1.com/user/fb.ifb 267 CALURI:http://cal.company.com/projectA/pjtA.ics 268 FBURL:http://cal.company.com/projectA/pjtAfb.ifb 269 END:VCARD 271 2.3.1 FBURL Property IANA Registration 273 To: ietf-mime-directory@imc.org 275 Subject: Registration of FBURL type for text/directory MIME type vCard 276 profile. 278 Type name: FBURL 280 Type purpose: To specify the URI for a user's busy time in a vCard 281 object. 283 Small, Hennessy, Dawson -- Page 8 -- Expires December 1999 284 Type encoding: 8bit 286 Type value: A single URI value. 288 Type special notes: Where multiple FBURL properties are specified, the 289 default FBURL property is indicated with the PREF parameter. The FTP or 290 HTTP type of URI points to an iCalendar object associated with a 291 snapshot of the last six weeks of the user's busy time data. If the 292 iCalendar object is represented as a file or document, it's file type 293 should be "ifb". 295 Intended usage: Refer to section 1.1. 297 Type examples: 299 FBURL;PREF:http://www.host1.com/busy/janedoe 300 FBURL:FTP://ftp.host.com/busy/project-a.ifb 302 2.3.2 CALADRURI Property IANA Registration 304 To: ietf-mime-directory@imc.org 306 Subject: Registration of CALADRURI type for application/directory MIME 307 type vCard profile. 309 Type name: CALADRURI 311 Type purpose: To specify the location to which an event request should 312 be sent for the user. 314 Type encoding: 8bit 316 Type value: A single URI value. 318 Type special notes: Where multiple CALADRURI properties are specified, 319 the default CALADRURI property is indicated with the PREF parameter. 321 Intended usage: Refer to section 1.2. 323 Type examples: 325 CALADRURI;PREF:mailto:janedoe@host.com 327 Small, Hennessy, Dawson -- Page 9 -- Expires December 1999 328 2.3.3 CAPURI Property IANA Registration 330 To: ietf-mime-directory@imc.org 332 Subject: Registration of CAPURI type for application/directory MIME type 333 vCard profile. 335 Type name: CAPURI 337 Type purpose: To specify a protocol independent location from which a 338 calendaring and scheduling client (i.e., CUA) can communicate with a 339 user's entire calendar. 341 Type encoding: 8bit 343 Type value: A single URI value. 345 Type special notes: Where multiple CAPURI properties are specified, the 346 default CAPURI property is indicated with the PREF parameter. 348 Intended usage: Refer to section 1.3. 350 2.3.4 CALURI Property IANA Registration 352 To: ietf-mime-directory@imc.org 354 Subject: Registration of CALURI type for text/directory MIME type vCard 355 profile. 357 Type name: CALURI 359 Type purpose: To specify the URI for a user's calendar in a vCard 360 object. 362 Type encoding: 8bit 364 Type value type: A single URI value. 366 Type special notes: Where multiple CALURI properties are specified, the 367 default CALURI property is indicated with the PREF parameter. The 368 property should contain a URI pointing to an iCalendar object associated 369 with a snapshot of the user's calendar store. If the iCalendar object is 370 represented as a file or document, it's file type should be "ics". 372 Intended usage: Refer to section 1.4. 374 Small, Hennessy, Dawson -- Page 10 -- Expires December 1999 375 Type examples: 377 CALURI;PREF:http://cal.host1.com/calA 378 CALURI:ftp://ftp.host1.com/calA.ics 380 2.4 Directory Lookup Using The LDAP v3 Protocol 382 Another way to obtain these URIs is to look them up in a directory using 383 the LDAP protocol [1]. 385 If a user's URIs can be found using directory lookup (i.e., searching 386 for one of the LDAP schema extensions defined below), they should, in 387 general, be considered "more up-to-date" than URIs in any vCards that 388 are stored locally. 390 2.4.1 LDAP Schema Extensions 392 In order to encode the calendaring URIs in the directory, the following 393 are defined: 395 - One object class: 397 - calEntry 399 - Eight attributes: 401 - calCalURI 403 - calFBURL 405 - calCAPURI 407 - calCalAdrURI 409 - calOtherCalURIs 411 - calOtherFBURLs 413 - calOtherCAPURIs 415 - calOtherCalAdrURIs 417 The calCalURI contains the URI to a snapshot of the user's entire 418 default calendar. The calFBURL contains the URI to the user's default 419 busy time data. The calCAPURI represents contains a URI that can be used 421 Small, Hennessy, Dawson -- Page 11 -- Expires December 1999 422 to communicate with the user's calendar. The calCalAdrURI contains a URI 423 that points to the location to which event requests should be sent for 424 that user. 426 The calOtherCalURIs is a multi-valued property containing URIs to 427 snapshots of other calendars that the user may have. The calOtherFBURLs 428 is a multi-valued property containing URIs to other free/busy data that 429 the user may have. The calOtherCAPURIs attribute is a multi-valued 430 property containing URIs to other calendars that the user may have. The 431 calOtherCalAdrURIs attribute is a multi-valued property containing URIs 432 to other locations that a user may want event requests sent to. 434 There is no predetermined order to the values in either multi-valued 435 property. 437 2.4.2 Notation 439 The notation used in this memo is the same as that used in [2]. 441 2.4.3 Object Definitions 443 2.4.3.1 calEntry 445 The Calendar Entry is a class derived from "TOP" [2], which contains the 446 four calendaring attributes. 448 (1.2.840.113556.1.5.87 449 NAME 'calEntry' 450 TOP 451 AUXILIARY 452 MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI 453 calOtherCAPURLs) 454 ) 456 2.4.4 Attribute Definitions 458 2.4.4.1 calCalURI 460 (1.2.840.113556.1.4.478 461 NAME 'calCalURI' 462 EQUALITY caseIgnoreMatch 463 SUBSTRING caseIgnoreMatch 464 SYNTAX 'IA5String' 465 USAGE userApplications 467 Small, Hennessy, Dawson -- Page 12 -- Expires December 1999 468 ) 470 2.4.4.2 calFBURL 472 (1.2.840.113556.1.4.479 473 NAME 'calFBURL' 474 EQUALITY caseIgnoreMatch 475 SUBSTRING caseIgnoreMatch 476 SYNTAX 'IA5String' 477 USAGE userApplications 478 ) 480 2.4.4.3 calCAPURI 482 (1.2.840.113556.1.4.480 483 NAME 'calCAPURI' 484 EQUALITY caseIgnoreMatch 485 SUBSTRING caseIgnoreMatch 486 SYNTAX 'IA5String' 487 USAGE userApplications 488 ) 490 2.4.4.4 calCalAdrURI 492 (1.2.840.113556.1.4.481 493 NAME 'calCalAdrURI' 494 EQUALITY caseIgnoreMatch 495 SUBSTRING caseIgnoreMatch 496 SYNTAX 'IA5String' 497 USAGE userApplications 498 ) 500 2.4.4.5 calOtherCalURIs 502 (1.2.840.113556.1.4.482 503 NAME 'calOtherCalURIs' 504 EQUALITY caseIgnoreMatch 505 SUBSTRING caseIgnoreMatch 506 SYNTAX 'IA5String' 507 MULTI-VALUE 508 USAGE userApplications 509 ) 511 Small, Hennessy, Dawson -- Page 13 -- Expires December 1999 512 2.4.4.6 calOtherFBURLs 514 (1.2.840.113556.1.4.483 515 NAME 'calOtherFBURLs' 516 EQUALITY caseIgnoreMatch 517 SUBSTRING caseIgnoreMatch 518 SYNTAX 'IA5String' 519 MULTI-VALUE 520 USAGE userApplications 521 ) 523 2.4.4.7 calOtherCAPURIs 525 (1.2.840.113556.1.4.484 526 NAME 'calOtherCAPURIs' 527 EQUALITY caseIgnoreMatch 528 SUBSTRING caseIgnoreMatch 529 SYNTAX 'IA5String' 530 MULTI-VALUE 531 USAGE userApplications 532 ) 534 2.4.4.8 calOtherCalAdrURIs 536 (1.2.840.113556.1.4.485 537 NAME 'calOtherCalAdrURIs' 538 EQUALITY caseIgnoreMatch 539 SUBSTRING caseIgnoreMatch 540 SYNTAX 'IA5String' 541 MULTI-VALUE 542 USAGE userApplications 543 ) 545 3 IANA Considerations 547 This memo defines IANA registered extensions to the attributes defined 548 by LDAP [1] and vCard [3]. 550 IANA registration proposals for vCard are to be emailed to the 551 registration agent for the "text/directory" MIME content-type, using the format defined in [3]. 554 Small, Hennessy, Dawson -- Page 14 -- Expires December 1999 555 4 Security Considerations 557 Standard vCard and LDAP security rules and support apply for the 558 extensions described in this document, and there are no special security 559 issues for these extensions. 561 Please note, though, that LDAP servers may permit anonymous clients to 562 refresh entries which they did not create. Servers are also permitted to 563 control a refresh access to an entry by requiring clients to bind before 564 issuing a RefreshRequest. This will have implications on the server 565 performance and scalability. 567 Please also note, though, that vCard objects may have been created by an 568 entity other than that represented by the vCard. Recipients should be 569 certain of the source that generated the vCard. 571 Also, care should be taken in making use of information obtained from 572 directory servers that has been supplied by client, as it may now be out 573 of date. In many networks, for example, IP addresses are automatically 574 assigned when a host connects to the network, and may be reassigned if 575 that host later disconnects. An IP address obtained from the directory 576 may no longer be assigned to the host that placed the address in the 577 directory. This issue is not specific to LDAP or dynamic directories. 579 5 Acknowledgments 581 The authors wish to acknowledge the work of Alec Dun, who acted as an 582 author for the early drafts of this memo. In addition, this document 583 received input from the various participants in the IETF CALSCH Working 584 Group discussions. 586 6 Authors's Addresses 588 The following address information is provided in a vCard v3.0 [3], 589 Electronic Business Card, format. 591 BEGIN:VCARD 592 VERSION:3.0 593 N:Small;Tony 594 FN:Tony Small 595 ORG:Microsoft Corporation 596 ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; 597 Redmond;WA;98052-6399;USA 598 TEL;TYPE=WORK,MSG:+1-425-703-2190 599 TEL;TYPE=WORK,FAX:+1-206-936-7329 601 Small, Hennessy, Dawson -- Page 15 -- Expires December 1999 602 EMAIL;TYPE=INTERNET:tonysm@Microsoft.com 603 CALADRURI:MAILTO:tonysm@Microsoft.com 604 END:VCARD 606 BEGIN:VCARD 607 VERSION:3.0 608 N:Hennessy;Denis 609 FN:Denis Hennessy 610 ORG:ISOCOR 611 ADR;TYPE=WORK,POSTAL,PARCEL:;;42-47 Lower Mount St; 612 Dublin 2;Ireland 613 TEL;TYPE=WORK,MSG:+353-1-676-0366 614 TEL;TYPE=WORK,FAX:+353-1-676-0856 615 EMAIL;TYPE=INTERNET:denis.hennessy@isocor.com 616 CALADRURI:MAILTO:denis.hennessy@isocor.com 617 END:VCARD 619 BEGIN:VCARD 620 VERSION:3.0 621 N:Dawson;Frank 622 FN:Frank Dawson 623 ORG:Lotus Development Corporation 624 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; 625 Raleigh;NC;27613-3502;USA 626 TEL;TYPE=WORK,PREF:+1-617-693-8728 627 TEL;TYPE=WORK,MSG:+1-919-676-9515 628 TEL;TYPE=FAX:+1-617-693-8728 629 EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com 630 EMAIL;TYPE=INTERNET:fdawson@earthlink.net 631 CALADRURI;TYPE=PREF:MAILTO:Frank_Dawson@Lotus.com 632 CALADRURI:MAILTO:fdawson@earthlink.net 633 URL:http://home.earthlink.net/~fdawson 634 END:VCARD 636 This memo is a result of the work of the Internet Engineering Task Force 637 Calendaring and scheduling Working Group. The chairman of that working 638 group is: 640 BEGIN:VCARD 641 VERSION:3.0 642 N:Egen;Pat 643 FN:Pat Egen 644 ORG:Engan Consulting 646 Small, Hennessy, Dawson -- Page 16 -- Expires December 1999 647 ADR;WORK:;;803 Creek Overlook;Chattanooga;TN;37415;USA 648 TEL;WORK;VOICE:423.875.2652 649 TEL;WORK;FAX:423.875.2017 650 EMAIL:pregen@egenconsulting.com 651 URL:www.egenconsulting.com 652 CALADRURI;TYPE=PREF:MAILTO:pregen@egenconsulting.com 653 END:VCARD 655 7 Bibliography 657 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 658 Protocol (v3)", RFC 2251, December 1997, 659 661 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 662 Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, 663 December 1997, 665 [3] F. Dawson, T. Howes, "vCard MIME Directory Profile", RFC 2426, 666 September 1998, 668 [4] F. Dawson, D. Stenerson "Internet Calendaring and Scheduling Core 669 Object Specification (iCalendar)", RFC 2445, November 1997, 670 672 [5] F. Dawson, S. Mansour "iCalendar Message-Based Interopability 673 Protocal (iMIP)", November 1997, 674 676 8 Full Copyright Statements 678 Copyright (C) The Internet Society (1999). All Rights Reserved. 680 This memo and translations of it may be copied and furnished to others, 681 and derivative works that comment on or otherwise explain it or assist 682 in its implementation may be prepared, copied, published and 683 distributed, in whole or in part, without restriction of any kind, 684 provided that the above copyright notice and this paragraph are included 685 on all such copies and derivative works. However, this memo itself may 686 not be modified in any way, such as by removing the copyright notice or 687 references to the Internet Society or other Internet organizations, 688 except as needed for the purpose of developing Internet standards in 689 which case the procedures for copyrights defined in the Internet 690 Standards process must be followed, or as required to translate it into 691 languages other than English. 693 Small, Hennessy, Dawson -- Page 17 -- Expires December 1999 694 The limited permissions granted above are perpetual and will not be 695 revoked by the Internet Society or its successors or assigns. 697 This memo and the information contained herein is provided on an "AS IS" 698 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 699 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 700 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 701 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 702 PARTICULAR PURPOSE. 704 Small, Hennessy, Dawson -- Page 18 -- Expires December 1999