ietf-corpus

rfc-2739

Calendar Attributes for vCard and LDAP

T. Small, D. Hennessy, F. Dawson
date2000-01 streamIETF areaapp wgcalsch statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc2739 doi10.17487/RFC2739 errataview
This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]

updated by

Extracted elements (17)

design-rationale §1.4

The 'default' calendar concept is introduced to simplify multi-calendar scenarios. A user designates one calendar (possibly an aggregation of all others) as the default that other users should consult, identified by the PREF parameter on the relevant vCard property.

realtime

design-rationale §2

Three distribution mechanisms are defined for calendar URIs—manual transfer, vCard exchange, and LDAP directory lookup—to accommodate varying deployment environments from simple personal exchange to enterprise directory integration.

realtime, ldap

interoperability-note §2.4

URIs found via LDAP directory lookup should generally be considered more up-to-date than URIs stored in locally cached vCards, because directory entries can be updated centrally.

ldap, realtime

normative-requirement §1.3 SHOULD

If the CALURI is an HTTP URI, the content returned with a GET SHOULD be a 'text/calendar' MIME body part. If it is an FTP URI, the resource SHOULD be a file with an 'ics' extension.

realtime, http

normative-requirement §1.1 SHOULD

If the FBURL points to a file or document resource, its file extension SHOULD be 'ifb' to distinguish it from a generic iCalendar object (which uses 'ics').

realtime

normative-requirement §1.1 RECOMMENDED

It is RECOMMENDED that the previous six weeks of busy time data be published at the FBURL location.

realtime

normative-requirement §2.3 MUST

When multiple FBURL, CALURI, CALADRURI, or CAPURI properties are present in a vCard, the default property MUST be indicated using the PREF parameter.

realtime

protocol-element §2.3.2

CALADRURI is a URI specifying the location to which an event request should be sent for a user. It is analogous to an email address but for calendar scheduling requests.

realtime

protocol-element §1.3

CALURI (Calendar URI) is a protocol-independent URI from which a CUA can retrieve a snapshot of a user's entire calendar. HTTP URIs return 'text/calendar' MIME content; FTP URIs point to a file with '.ics' extension.

realtime

protocol-element §1.2

CAPURI (Calendar Access URI) is a protocol-independent URI from which a CUA can communicate with a user's entire calendar. Semantics for using this URI as an access protocol locator are deferred to the Calendar Access Protocol specification.

realtime

protocol-element §2.4.4

Eight LDAP attributes are defined: calCalURI (OID .478), calFBURL (.479), calCAPURI (.480), calCalAdrURI (.481), calOtherCalURIs (.482), calOtherFBURLs (.483), calOtherCAPURIs (.484), calOtherCalAdrURIs (.485). All use IA5String syntax with caseIgnoreMatch equality. The calOther* attributes are MULTI-VALUE.

ldap, realtime

protocol-element §1.1

FBURL (Free/Busy URI) is a transport-independent URI pointing to a user's busy time data. Retrieving it via HTTP or FTP returns an iCalendar object containing one or more VFREEBUSY components in a 'text/calendar' MIME body part.

realtime, ldap

protocol-element §2.4.3.1

The LDAP calEntry object class (OID 1.2.840.113556.1.5.87) is an AUXILIARY class derived from TOP that MAY contain calCalURI, calFBURL, calOtherCalURIs, calOtherFBURLs, calCAPURI, and calOtherCAPURLs attributes.

ldap, realtime

registry §2.3

This document registers four new vCard property types with the text/directory MIME type registration agent (ietf-mime-directory@imc.org): FBURL, CALADRURI, CAPURI, and CALURI.

registry, realtime

registry §3

This document registers LDAP schema extensions: one object class (calEntry) and eight attributes (calCalURI, calFBURL, calCAPURI, calCalAdrURI, calOtherCalURIs, calOtherFBURLs, calOtherCAPURIs, calOtherCalAdrURIs) under the 1.2.840.113556 OID arc.

registry, ldap

security-consideration §4

Information obtained from directory servers supplied by clients may be out of date; for example, dynamically assigned IP addresses stored in the directory may have been reassigned to a different host. This issue is not specific to LDAP or dynamic directories.

security, ldap

security-consideration §4

LDAP servers may permit anonymous clients to refresh entries they did not create, which has implications for data integrity. Servers may require clients to bind before issuing a RefreshRequest, impacting performance and scalability. vCard objects may have been created by an entity other than the one they represent, so recipients should verify the vCard source.

security, ldap