RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR
The following is an example of an iCalendar object passed in a MIME
message with a single body part consisting of a "text/calendar"
Content Type.
TO:jsmith@host1.com
FROM:jdoe@host1.com
MIME-VERSION:1.0
MESSAGE-ID:<id3@host1.com>
CONTENT-TYPE:text/calendar
BEGIN:VCALENDAR
METHOD:xyz
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\n
using iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR
The following is an example of a to-do due on April 15, 1998. An
audio alarm has been specified to remind the calendar user at noon,
the day before the to-do is expected to be completed and repeat
hourly, four additional times. The to-do definition has been modified
twice since it was initially created.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
The following is an example of a journal entry.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
Agenda\n1. Review of project version 1.0 requirements.\n2.
Definition
of project processes.\n3. Review of project schedule.\n
Participants: John Smith, Jane Doe, Jim Dandy\n-It was
decided that the requirements need to be signed off by
product marketing.\n-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays
and employee vacation time. Check with HR for specific
dates.\n-New schedule will be distributed by Friday.\n-
Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
The following is an example of published busy time information. The
iCalendar object might be placed in the network resource
www.host.com/calendar/busytime/jsmith.ifb.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
6 Recommended Practices
These recommended practices should be followed in order to assure
consistent handling of the following cases for an iCalendar object.
1. Content lines longer than 75 octets SHOULD be folded.
2. A calendar entry with a "DTSTART" property but no "DTEND"
property does not take up any time. It is intended to represent
an event that is associated with a given calendar date and time
of day, such as an anniversary. Since the event does not take up
any time, it MUST NOT be used to record busy time no matter what
the value for the "TRANSP" property.
3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
"VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
"VTODO" calendar components, have the same value data type (e.g.,
DATE-TIME), they SHOULD specify values in the same time format
(e.g., UTC time format).
4. When the combination of the "RRULE" and "RDATE" properties on an
iCalendar object produces multiple instances having the same
start date/time, they should be collapsed to, and considered as,
a single instance.
5. When a calendar user receives multiple requests for the same
calendar component (e.g., REQUEST for a "VEVENT" calendar
component) as a result of being on multiple mailing lists
specified by "ATTENDEE" properties in the request, they SHOULD
respond to only one of the requests. The calendar user SHOULD
also specify (using the "MEMBER" parameter of the "ATTENDEE"
property) which mailing list they are a member of.
6. An implementation can truncate a "SUMMARY" property value to 255
characters.
7. If seconds of the minute are not supported by an implementation,
then a value of "00" SHOULD be specified for the seconds
component in a time value.
8. If the value type parameter (VALUE=) contains an unknown value
type, it SHOULD be treated as TEXT.
9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI
form can be useful within an organization, but is problematic in
the Internet.
10. Some possible English values for CATEGORIES property include
"ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
"HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
OCCASION", "TRAVEL", "VACATION". Categories can be specified in
any registered language.
11. Some possible English values for RESOURCES property include
"CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
PHONE", "VEHICLE". Resources can be specified in any registered
language.
7 Registration of Content Type Elements
This section provides the process for registration of MIME
Calendaring and Scheduling Content Type iCalendar object methods and
new or modified properties.
7.1 Registration of New and Modified iCalendar Object Methods
New MIME Calendaring and Scheduling Content Type iCalendar object
methods are registered by the publication of an IETF Request for
Comments (RFC). Changes to an iCalendar object method are registered
by the publication of a revision of the RFCdefining the method.
7.2 Registration of New Properties
This section defines procedures by which new properties or enumerated
property values for the MIME Calendaring and Scheduling Content Type
can be registered with the IANA. Non-IANA properties can be used by
bilateral agreement, provided the associated properties names follow
the "X-" convention.
The procedures defined here are designed to allow public comment and
review of new properties, while posing only a small impediment to the
definition of new properties.
Registration of a new property is accomplished by the following
steps.
7.2.1 Define the property
A property is defined by completing the following template.
To: ietf-calendar@imc.org
Subject: Registration of text/calendar MIME property XXX
Property name:
Property purpose:
Property value type(s):
Property parameter (s):
Conformance:
Description:
Format definition:
Examples:
The meaning of each field in the template is as follows.
Property name: The name of the property, as it will appear in the
body of an text/calendar MIME Content-Type "property: value" line to
the left of the colon ":".
Property purpose: The purpose of the property (e.g., to indicate a
delegate for the event or to-do, etc.). Give a short but clear
description.
Property value type (s): Any of the valid value types for the
property value needs to be specified. The default value type also
needs to be specified. If a new value type is specified, it needs to
be declared in this section.
Property parameter (s): Any of the valid property parameters for the
property needs to be specified.
Conformance: The calendar components that the property can appear in
needs to be specified.
Description: Any special notes about the property, how it is to be
used, etc.
Format definition: The ABNF for the property definition needs to be
specified.
Examples: One or more examples of instances of the property needs to
be specified.
7.2.2 Post the Property definition
The property description MUST be posted to the new property
discussion list, ietf-calendar@imc.org.
7.2.3 Allow a comment period
Discussion on the new property MUST be allowed to take place on the
list for a minimum of two weeks. Consensus MUST be reached on the
property before proceeding to the next step.
7.2.4 Submit the property for approval
Once the two-week comment period has elapsed, and the proposer is
convinced consensus has been reached on the property, the
registration application should be submitted to the Method Reviewer
for approval. The Method Reviewer is appointed to the Application
Area Directors and can either accept or reject the property
registration. An accepted registration should be passed on by the
Method Reviewer to the IANA for inclusion in the official IANA method
registry. The registration can be rejected for any of the following
reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
Technical deficiencies raised on the list or elsewhere have not been
addressed. The Method Reviewer's decision to reject a property can be
appealed by the proposer to the IESG, or the objections raised can be
addressed by the proposer and the property resubmitted.
7.3 Property Change Control
Existing properties can be changed using the same process by which
they were registered.
1. Define the change
2. Post the change
3. Allow a comment period
4. Submit the property for approval
Note that the original author or any other interested party can
propose a change to an existing property, but that such changes
should only be proposed when there are serious omissions or errors in
the published memo. The Method Reviewer can object to a change if it
is not backward compatible, but is not required to do so.
Property definitions can never be deleted from the IANA registry, but
properties which are no longer believed to be useful can be declared
OBSOLETE by a change to their "intended use" field.
8 References
[IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
Message-based Interoperability Protocol (IMIP)", RFC2447,
November 1998.
[ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
"iCalendar Transport-Independent Interoperability Protocol
(iTIP) : Scheduling Events, Busy Time, To-dos and Journal
Entries", RFC2446, November 1998.
[ISO 8601] ISO 8601, "Data elements and interchange formats-
Information interchange--Representation of dates and
times", International Organization for Standardization,
June, 1988.
[ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support
Facilities--Registration Procedures for Public Text Owner
Identifiers", Second Edition, International Organization
for Standardization, April 1991.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC822, August 1982.
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, December 1994.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC1766, March 1995.
[RFC2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC2046,
November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four: Registration
Procedures", RFC2048, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC2279, January 1998.
[RFC2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
for Directory Information", RFC2425, September 1998.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC2426, September 1998.
[TZ] Olson, A.D., et al, Time zone code and data,
ftp://elsie.nci.nih.gov/pub/, updated periodically.
[VCAL] Internet Mail Consortium, "vCalendar - The Electronic
Calendaring and Scheduling Exchange Format",
http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.
9 Acknowledgments
A hearty thanks to the IETF Calendaring and Scheduling Working Group
and also the following individuals who have participated in the
drafting, review and discussion of this memo:
Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross
Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck
Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman,
Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch,
Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve
Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman,
John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert
Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod
Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov,
James L. Weiner, Mike Weston, William Wyatt.
10 Authors' and Chairs' Addresses
The following address information is provided in a MIME-VCARD,
Electronic Business Card, format.
The authors of this memo are:
BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
Raleigh;NC;27613-3502;USA
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564
EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Stenerson;Derik
FN:Derik Stenerson
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-425-936-5522
TEL;TYPE=WORK,FAX:+1-425-936-7329
EMAIL;TYPE=INTERNET:deriks@Microsoft.com
END:VCARD
The iCalendar object is a result of the work of the Internet
Engineering Task Force Calendaring and Scheduling Working Group. The
chairmen of that working group are:
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG: Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
The co-chairman of that working group is:
BEGIN:VCARD
VERSION:3.0
N:Moskowitz;Robert
FN:Robert Moskowitz
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD
11. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.