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