Initial commit of libical. - libical - A simple ical library.
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) LICENSE
---
(DIR) commit bccaa1ea3b33f47b4be6de3745635d5378ab4016
(HTM) Author: Christoph Lohmann <20h@r-36.net>
Date: Fri, 28 Dec 2012 02:07:36 +0100
Initial commit of libical.
Diffstat:
LICENSE | 21 +++++++++++++++++++++
Makefile | 69 ++++++++++++++++++++++++++++++
README.md | 9 +++++++++
config.mk | 23 +++++++++++++++++++++++
examples/schedule.en.ics | 1802 +++++++++++++++++++++++++++++++
examples/schedule.en.produced.ics | 1828 +++++++++++++++++++++++++++++++
ical.c | 327 +++++++++++++++++++++++++++++++
ical.h | 63 +++++++++++++++++++++++++++++++
icaltest.c | 38 +++++++++++++++++++++++++++++++
ind.c | 182 +++++++++++++++++++++++++++++++
ind.h | 28 ++++++++++++++++++++++++++++
rfc/rfc2445.txt | 8291 +++++++++++++++++++++++++++++++
12 files changed, 12681 insertions(+), 0 deletions(-)
---
(DIR) diff --git a/LICENSE b/LICENSE
@@ -0,0 +1,21 @@
+MIT/X Consortium License
+
+© 2012 Christoph Lohmann <20h@r-36.net>
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+tto deal in the Software without restriction, including without limitation
+tthe rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
(DIR) diff --git a/Makefile b/Makefile
@@ -0,0 +1,69 @@
+# libical – simple ical library
+# See LICENSE file for copyright and license details.
+
+include config.mk
+
+SRC = ical.c ind.c
+OBJ = ${SRC:.c=.o}
+SOUT = ${NAME}.a
+DOUT = ${NAME}.so
+
+all: options ${SOUT} ${DOUT}
+
+options:
+ @echo ${NAME} build options:
+ @echo "CFLAGS = ${CFLAGS}"
+ @echo "LDFLAGS = ${LDFLAGS}"
+ @echo "CC = ${CC}"
+
+.c.o:
+ @echo CC $<
+ @${CC} -c ${CFLAGS} $<
+
+${OBJ}: config.mk
+
+${SOUT}: ${OBJ}
+ @ar rcs ${SOUT} ${OBJ}
+
+${DOUT}: ${OBJ}
+ @${CC} -shared ${OBJ} -o ${DOUT}
+
+icaltest: ${OBJ} icaltest.o
+ @echo CC -o $@
+ @${CC} -o $@ ${OBJ} icaltest.o ${LDFLAGS}
+
+ttest: icaltest
+ @echo running icaltest
+ ./icaltest examples/schedule.en.ics
+
+clean:
+ @echo cleaning
+ @rm -f *.so *.a ${NAME} ${OBJ} icaltest icaltest.o ${NAME}-${VERSION}.tar.gz
+
+dist: clean
+ @echo creating dist tarball
+ @mkdir -p ${NAME}-${VERSION}
+ @cp -R LICENSE Makefile README.md config.mk examples rfc\
+ ${SRC} *.h ${NAME}-${VERSION}
+ @tar -cf ${NAME}-${VERSION}.tar ${NAME}-${VERSION}
+ @gzip ${NAME}-${VERSION}.tar
+ @rm -rf ${NAME}-${VERSION}
+
+install: all
+ @echo installing libraries to ${DESTDIR}${PREFIX}/lib
+ @mkdir -p ${DESTDIR}${PREFIX}/lib
+ @cp -f ${NAME}.a ${NAME}.so ${DESTDIR}${PREFIX}/lib
+ @chmod 755 ${DESTDIR}${PREFIX}/lib/${NAME}.*
+ @echo installing header file to ${DESTDIR}${PREFIX}/include
+ @mkdir -p ${DESTDIR}${PREFIX}/include
+ @cp -f ical.h ${DESTDIR}${PREFIX}/include
+ @chmod 644 ${DESTDIR}${PREFIX}/include/ical.h
+
+uninstall:
+ @echo removing libraries from ${DESTDIR}${PREFIX}/bin
+ @rm -f ${DESTDIR}${PREFIX}/lib/${NAME}.*
+ @echo removing header file from ${DESTDIR}${PREFIX}/include
+ @rm -f ${DESTDIR}${PREFIX}/include/ical.h
+
+.PHONY: all options clean dist install uninstall test
+# DO NOT DELETE
(DIR) diff --git a/README.md b/README.md
@@ -0,0 +1,9 @@
+# A simple ical library
+
+## Usage
+
+see icaltest.c
+
+
+Have fun!
+
(DIR) diff --git a/config.mk b/config.mk
@@ -0,0 +1,23 @@
+# libical metadata
+NAME = libical
+VERSION = 0.5
+
+# Customize below to fit your system
+
+# paths
+PREFIX ?= /usr/local
+MANPREFIX = ${PREFIX}/share/man
+
+# includes and libs
+INCS = -I. -I/usr/include
+LIBS = -L/usr/lib -lc
+
+# flags
+CPPFLAGS = -DVERSION=\"${VERSION}\"
+CFLAGS = -g -fPIC -std=c99 -pedantic -Wall -O0 ${INCS} ${CPPFLAGS}
+LDFLAGS = -g ${LIBS}
+#LDFLAGS = -s ${LIBS}
+
+# compiler and linker
+CC = cc
+
(DIR) diff --git a/examples/schedule.en.ics b/examples/schedule.en.ics
@@ -0,0 +1,1802 @@
+BEGIN:VCALENDAR
+VERSION:2.0
+CALSCALE:GREGORIAN
+PRODID:-//Pentabarf//Schedule//EN
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5333.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5333@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Did you notice 262 42 in your mobile phone network search list
+ at the last CCC events? Did you and your friends buy SIM cards at the PoC a
+ nd help test the network by calling each other\, or by calling through the
+ bridge to the DECT network services? Did you ever wonder about the details
+ of this open source test network\, set up by a team of volunteers in the mi
+ ddle of the city? We would like to tell you all the details of the cell pho
+ ne network we operate at 29C3\, and show you some fancy graphs based on the
+ network activity!
+SUMMARY:29C3 GSM: Cell phone network review - 262 42 - The full spectrum
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5205.en.html
+DTSTART;TZID=Europe/Berlin:20121229T140000
+UID:5205@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:There are hundreds\, if not thousands\, of news articles and bl
+ og posts about the BlackHole Exploit Kit. Usually\, each story covers only
+ a very narrow part of the subject matter. This talk will summarize the hist
+ ory of the BlackHole Exploit Kit into one easy to follow story. There will
+ be diagrams and flow-charts for explaining code\, rather than a giant blob
+ of illegible Javascript\, PHP\, or x86 Assembly.
+SUMMARY:Analytical Summary of the BlackHole Exploit Kit - Almost Everything
+ You Ever Wanted To Know About The BlackHole Exploit Kit
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5146.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5146@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:There's about 100 top-level domains signed with DNSSEC and .nl
+ recently hit 1M second-level domains. At this occasion\, we take a look at
+ the goods and the bads of DNSSEC deployment\, including amplification attac
+ ks\, Zensursula-like DNS redirects\, China DNS injection and NASA key rollo
+ ver mistakes. We will find out what DNSCurve and Namecoin promise to make b
+ etter and what Zooko's triangle has all to do with this.
+SUMMARY:An Overview of Secure Name Resolution - DNSSEC\, DNSCurve and Namec
+ oin
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5237.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5237@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:With Visa and Mastercard pushing for EMV (http://www.emvco.com\
+ , aka “chip and pin”) rollout in the United States\, the uptake of contactl
+ ess payment and the use of mobile NFC wallets\, the chipcard security commu
+ nity will soon be getting more eyes to analyze the protocols in use with ch
+ ip and contactless credit card transactions.
+SUMMARY:A Rambling Walk Through an EMV Transaction
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5299.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5299@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Verfassungsschutzskandale gibt es nicht erst seit der Entdeckun
+ g des NSU vor einem Jahr. Vorgestellt werden: sie Affaire Traube\, der Schm
+ ücker-Prozess\, das Celler Loch\, die Vulkan-Affaire\, der Anschlagsversuch
+ auf das Jüdische Gemeindehaus West-Berlin\, vier Jahrzehnte Beobachtung vo
+ n Rolf Gössner. Vielleicht sind aber gar nicht die Pannen der Skandal\, son
+ dern vielmehr der ganz gewöhnliche Alltag des Verfassungsschutzes.
+SUMMARY:Best of ... Verfassungsschutz - Der Verfassungsschutz schützt die V
+ erfassung so wie Zitronenfalter Zitronen falten.
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5379.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5379@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir schauen nicht zurück im Zorn\, aber jetzt auch nicht grade
+ mit Euphorie. Im CCC-Jahresrückblick präsentieren wir Euch einige der hackt
+ ivistischen Themen des vergangenen Jahres\, an denen der CCC gearbeitet ode
+ r sich abgearbeitet hat. Diesmal mit schönen neuen Gesetzen\, Hacker-Humor\
+ , versäumten Gerichtsterminen\, bunten Blinkenlichtern und Iggy Pop. Wir ha
+ ben uns wirklich das ganze Jahr bemüht\, nur in begrenztem Umfange zu prokr
+ astinieren.
+SUMMARY:CCC-Jahresrückblick
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5319@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hypertext Transfer Protocol Secure (HTTPS) has evolved into the
+ de facto standard for secure web browsing. But in the security community\,
+ it has long been known that HTTPS is fundamentally broken\, and this has b
+ een confirmed by alarming hacks and security breaches at several Certificat
+ e Authorities (CAs). To tackle the global collapse of trust in these centra
+ l mediators of HTTPS communications and to augment HTTPS security\, the EU
+ has launched a proposal for strict regulation. Will these efforts succeed?
+SUMMARY:Certificate Authority Collapse - Will the EU Succeed in Regulating
+ HTTPS?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5263.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5263@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir brauchen ein maschinenlesbares und -schreibbares Gesetzgebu
+ ngsverfahren\, in dem jede Änderung transparent diskutiert und beschlossen
+ wird. Der Bundestag öffnet und digitalisiert sich eher langsam und widerwil
+ lig\, dennoch kann man schon heute anfangen\, die Werkzeuge der parlamentar
+ ischen Zukunft in Deutschland zu gestalten und auszuprobieren. Dazu stellen
+ wir die Projekte OffenesParlament.de und das Bundes-Git vor und zeigen\, w
+ ie es in Zukunft weitergehen könnte.
+SUMMARY:chmod o+rw bundestag - Mehr Transparenz und Teilhabe im Gesetzgebun
+ gsprozess
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5398.en.html
+DTSTART;TZID=Europe/Berlin:20121230T183000
+UID:5398@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Some facts and stats about Congress\, plus stories and legends.
+SUMMARY:Closing Event
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5221.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5221@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir sind Zeugen eines seit einigen Jahren stattfindenden Wettrü
+ stens im Cyberspace. Immer mehr Staaten bauen militärische Cyberware Einhei
+ ten auf\, die aus IT Spezialisten bestehen und dem Zweck dienen\, bestenfal
+ ls IT Systeme abzusichern oder schlechterdings Systeme von „Feinden“ anzug
+ reifen.
+SUMMARY:Cyberpeace statt Cyberwar
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5301.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5301@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Aside from further development of traditional forensic techniqu
+ es which involve post-mortem hard disk analysis\, in the last couple of yea
+ rs the field of computer forensics has been marked by significant developme
+ nt of live forensic techniques and tools.Memory forensics is composed of tw
+ o main activities: memory aquisition/capture and analysis. This presentatio
+ n will give an overview of the memory acquisition and analysis techniques a
+ nd tools on the Windows operating systems. The main part of the presentatio
+ n will cover current exploitation techniques and methods for defeating both
+ acquisition and analysis phase of the memory forensics\, as well as presen
+ t a new approach for hiding specific artifacts from forensic tools. Based o
+ n the covered exploitation techniques\, some suggestions and improvements o
+ f the current tools will be given.
+SUMMARY:Defeating Windows memory forensics
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5159.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5159@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Over the years we learned impressively how to oppose bad legisl
+ ation hurting our freedoms online. We are now facing an even bigger challen
+ ge: how to guarantee that a Free\, open\, decentralized Internet will be pr
+ otected in the long run? In 2012 The Internetz won major battles against SO
+ PA/PIPA in the US\, and against ACTA in the EU. Yet\, we know that the powe
+ rful industries and governments behind these projects will never stop. They
+ have an incentive to gain control of the Internet\, attacking fundamental
+ rights and promoting technologies like "Deep Packet Inspection"\, now being
+ deployed in each and every corner of the Net\, and used indifferently to b
+ reak Net neutrality\, to filter\, block and censor communications or to ins
+ pect citizens traffic.How to push for proposals that will ensure that the s
+ haring of knowledge and culture\, citizens freedoms\, and access to an open
+ infrastructure will be guaranteed in the future public policies? How to be
+ come as successful in proposition as we are now in opposition?(Hint: it's p
+ olitical\, stupid!)
+SUMMARY:Defend your Freedoms Online: It's Political\, Stupid! - A Positive
+ agenda against the next ACTA\, SOPA\, and such
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5401.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5401@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Die Debatte um die Tarifreform der GEMA war eines der großen Th
+ emen des Jahres 2012: Die Verwertungsgesellschaft geriet quer durch alle po
+ litischen Lager und gesellschaftlichen Schichten in die Kritik\, die Warnun
+ gen vor einem großen Clubsterben wurden von Tausenden auf die Straße getrag
+ en. Dies steigerte auch das Interesse an der »Cultural Commons Collecting S
+ ociety« (C3S)\, einem Graswurzelprojekt zur Gründung einer neuen\, modernen
+ und internetverstehenden Verwertungsgesellschaft\, die u. a. auch vollen S
+ upport für Creative-Commons-Lizenzen bieten soll. 2012 war daher auch ein e
+ reignisreiches Jahr für dieses Projekt\, und 2013 sollen nach Plan die Grün
+ dung als Europäische Genossenschaft und die Antragsstellung beim Deutschen
+ Patent- und Markenamt folgen.
+SUMMARY:Der Mord fällt aus - Ein Werkstattbericht der GEMA-Alternative C3S
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5382.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5382@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Am 6. November 2012 war der CCC vor dem Bundesverfassungsgerich
+ t zur Anhörung über die Antiterrordatei und die Grenzen polizeilicher Daten
+ verarbeitung geladen. Wir berichten über die Anhörung\, die dort vorgebrach
+ ten Argumente und die technische Konzeption der ATD. Und wir orakeln über e
+ in mögliches Urteil im nächsten Jahr.
+SUMMARY:Die Antiterrordatei
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5181.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5181@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In den vergangenen Jahren wurde vor allem die Sprache von Polit
+ ikern auf dem Congress beleuchtet. Aber die schwurbelnde Politiker sind noc
+ h nicht die ganze Wahrheit. Wir möchten das Ganze daher um den zweiten wich
+ tigen Mitspieler bei der Konstruktion von Realität ergänzen\, um die Presse
+ bzw. die Medien. Die Äußerungen von Politikern (zum Beispiel auf Pressekon
+ ferenzen) sollen dabei der Mediendarstellung gegenübergestellt werden. Dabe
+ i wird deutlich werden\, dass es zwischen Politikern und Medien Rückkopplun
+ gseffekte gibt.
+SUMMARY:Die Wahrheit\, was wirklich passierte und was in der Zeitung stand
+ - Wie Medien unsere Wahrnehmung beeinflussen
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5338.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5338@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:With the post 9/11 rise of the leviathan national security stat
+ e\, the rule of law in the United States under the Constitution is increasi
+ ngly rule by secrecy\, surveillance and executive fiat.
+SUMMARY:Enemies of the State: What Happens When Telling the Truth about Sec
+ ret US Government Power Becomes a Crime - Blowing the Whistle on Spying\, L
+ ying & Illegalities in the Digital Era
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5104.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5104@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This presentation will cover a demonstration of the new version
+ of the Canape protocol analysis tool being released for Ruxcon. During the
+ course of the presentation various attack scenarios against the VMWare ESX
+ i binary protocol will be demonstrated using Canape.
+SUMMARY:ESXi Beast - Exploiting VMWARE ESXi Binary Protocols Using CANAPE
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5077.en.html
+DTSTART;TZID=Europe/Berlin:20121229T131500
+UID:5077@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Recently\, several research papers in the area of computer secu
+ rity were published that may or may not be considered unethical. Looking at
+ these borderline cases is relevant as today’s research papers will influen
+ ce how young researchers conduct their research. In our talk we address var
+ ious cases and papers and highlight emerging issues for ethic committees\,
+ internal review boards (IRBs) and senior researchers to evaluate research p
+ roposals and to finally decide where they see a line that should not be cro
+ ssed.
+SUMMARY:Ethics in Security Research
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5085.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5085@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We know\, that cooking is an art. Selecting the ingredients\, c
+ arefully washing\, pealingand cutting them before you put them into the rig
+ ht dish at the right time with the right heat.Watching the food change his
+ color\, form and consistency\, seasoning it to develop it'sflavors and serv
+ ing it on beautiful plates is a pleasure.For some\, but not for all.Those
+ who love cooking can spend hours at the stove andrelax while preparing deli
+ cious meals. For others cooking is pure stress. What is the difference betw
+ een orange and yellowcarrots? Did I forget something? Is the pan hot enough
+ ? Or too hot? How long after thepasta do I start cooking the steak? Will it
+ be healthy? Is it sustainable?So many questionsappear if one starts to thi
+ nk about food. The answers are complicatedand ambiguous. They require resea
+ rch and analyzing. Many have stopped thinkingabout food. They just believe
+ what is written on thepackage.I can't cookis such an easy answer. And it is
+ accepted in our society. Nobody isashamed of it. This gives more and more
+ control tomultinational corporations. Through precookedfood and shiny comme
+ rcials they calm our conscience and stimulate our laziness.The consequences
+ are dramatic!The profit-focused approach of multinationalcorporations have
+ led to things like:• Patented genetically modified seeds. Lawyers suing fa
+ rmers for copyrights.• Destruction of South-American jungle to make soya to
+ feed European cows so theymake more milk. Although a cow as never born to
+ eat proteins.• Chickens that can't stand on their own feet due to the weigh
+ t of their breasts. Theywill never see soil\, worms or even sunlight.• Oran
+ -Utangs losing their homes for palm oil• Vegetables getting grown in the de
+ sert\, wasting huge amounts of drinking water.Conclusions:• We must know mo
+ re about our food• We have to cook more ourselves• So we will recover some
+ control over what we eat
+SUMMARY:EveryCook - Cooking gets digital
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5275.en.html
+DTSTART;TZID=Europe/Berlin:20121228T183000
+UID:5275@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:RSA is the dominant public-key cryptosystem on the Internet. Th
+ is talk will explain the state of the art in techniques for the attacker to
+ figure out your secret RSA keys.
+SUMMARY:FactHacks - RSA factorization in the real world
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5198.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5198@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Neues Jahr\, neue Fnords :-)
+SUMMARY:Fnord-Jahresrückblick - Diesmal mit noch mehr Eurozonen-Spaltung!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5226.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5226@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The calypso baseband and its companion chips are used on the Mo
+ torola C123 among other and are now well known for being supported by the O
+ smocom-BB open source GSM baseband implementation. A couple years ago\, it
+ was hacked a little further by using it as a raw bits capture device allowi
+ ng the interception of GSM traffic very cheaply.
+SUMMARY:Further hacks on the Calypso platform - or how to turn a phone into
+ a BTS
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5250.en.html
+DTSTART;TZID=Europe/Berlin:20121228T001500
+UID:5250@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Beim Googlequiz treten Teams gegeneinander an\, die *ohne Inter
+ net* Aufgaben zu Googlesuchen und Suchergebnissen raten.
+SUMMARY:Googlequiz - Wie man (spaßorientiert) mehr als 5% seines Googleverm
+ ögens trainiert
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5309.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5309@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Hacker Jeopardy - Zahlenraten für Geeks
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5024.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5024@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hackers are a high-risk population. This talk will provide hack
+ ers with tools to reduce the risk to themselves and their communities using
+ harm reduction methodology.
+SUMMARY:Hackers As A High-Risk Population - Harm Reduction Methodology
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5400.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5400@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We discuss a set of 0-day kernel vulnerabilities in CNU (Cisco
+ NativeUnix)\, the operating system that powers all Cisco TNP IP phones. Wed
+ emonstrate the reliable exploitation of all Cisco TNP phones viamultiple vu
+ lnerabilities found in the CNU kernel. We demonstratepractical covert surve
+ illance using constant\, stealthy exfiltration ofmicrophone data via a numb
+ er of covert channels. We also demonstrate theworm-like propagation of our
+ CNU malware\, which can quickly compromiseall vulnerable Cisco phones on th
+ e network. We discuss the feasibilityof our attacks given physical access\,
+ internal network access and remoteaccess across the internet. Lastly\, we
+ built on last year's presentationby discussing the feasibility of exploitin
+ g Cisco phones fromcompromised HP printers and vice versa.
+SUMMARY:Hacking Cisco Phones - Just because you are paranoid doesn't mean y
+ our phone isn't listening to everything you say
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5179.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5179@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir sehen in der digitalen Technik großes Potential zur Demokra
+ tisierung und Befreiung der Menschen. Doch machen wir uns nichts vor. Techn
+ ik kann genausogut der Entmündigung von Menschen dienen. Je komplexer sie w
+ ird\, desto mehr sind wir von Vereinfachung abhängig und desto weniger Einf
+ luss können wir selber auf die Technik nehmen.
+SUMMARY:Hacking Philosophy - Digitale Mündigkeit\, Technikpaternalismus und
+ warum wir Netzphilosophie brauchen
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5270.en.html
+DTSTART;TZID=Europe/Berlin:20121229T001500
+UID:5270@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This is fun stuff for the late night program\, not a serious ta
+ lk.Is it possible to read sb. others mind? In the late 1920ies/early 1930ie
+ s Berlin was excited by the famous mindreader and fortune teller Erik Jan H
+ anussen who performed his strange abilities on stage. His act was so convin
+ cing that leading nazis beleaved in his powers and wanted him for advice -
+ until they decided to murder him.
+SUMMARY:Hanussen's mindreading - Experiment's of the historical psychic
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5152@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:At 28C3\, Klink and Waelde showed that a number of technologies
+ (PHP\, ASP.NET\,Ruby\, Java\, Python\, etc.) were vulnerable to the decade
+ -old hash-flooding DoSattacks. The vulnerability was then often fixed by ad
+ opting stronger hashfunctions and "randomizing" them.
+SUMMARY:Hash-flooding DoS reloaded: attacks and defenses
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5287.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5287@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:NSU-Untersuchungsausschuss in Thüringen und NSU-Untersuchungsau
+ sschuss des Bundestages\, über die Mordserie des NSU\, das System der V-Leu
+ te und die Rolle des Verfassungsschutzes.Zwölf Jahre lang konnte der „Natio
+ nalsozialistische Untergrund“ (NSU) unerkannt in Deutschland eine rassistis
+ che Mordserie an neun migrantischen Gewerbetreibenden\, zwei Bombenanschläg
+ e mit mehr als zwanzig Verletzten\, den Mord an einer jungen Polizistin sow
+ ie ein Dutzend Banküberfälle verüben.
+SUMMARY:Hinter den Kulissen: Der NSU und das V-Leute-System
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5219.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5219@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:An approach to the problem of fuzzing proprietary protocols wil
+ l be shown\, focusing on network protocols and native software. In the cour
+ se of this talk I will combine several methods in order to force the client
+ software to work as a “double agent” against the server.
+SUMMARY:"How I met your pointer" - Hijacking client software for fuzz and p
+ rofit
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5395.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5395@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Legal systems have a huge impact on what we do as hackers\, but
+ also on internet users in general. Laws can restrict our freedom to use th
+ e internet in ways we deem to be natural and it can impede the tools which
+ we hackers use on a daily basis. Which is not to say that laws cannot also
+ protect our freedom and ensure that all bits are treated equally. Most impo
+ rtantly\, these laws can be hacked and tweaked to fit our needs - like most
+ things in this world.
+SUMMARY:HOWTO Hack the law
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5368.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5368@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Sechs Jahre nach seinem Inkrafttreten wurde das Informationsfre
+ iheitsgesetz (IFG) des Bundes für den Deutschen Bundestag evaluiert. Auch a
+ us einzelnen Bundesländern liegen zwischenzeitlich wissenschaftlich unterma
+ uerte Erkenntnisse zum Stand oder Nichtstand der Informationsfreiheit in De
+ utschland vor.
+SUMMARY:IFG: Chance oder Bürgerbluff? - Informationsfreiheit in Deutschland
+ . Ein Sachstand.
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5397.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5397@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:INFECT: "Bei der Forschung an unserem neuen Killervirus hat uns
+ ere Ethikkommission penibelst darauf geachtet\, dass niemand der Forscher s
+ ich ansteckt."
+SUMMARY:INDECT\, Verhaltenserkennung & Co - automatisierte staatliche Verdä
+ chtigung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5112.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5112@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk is aimed to give an insight into CPE WAN Management P
+ rotocol (CWMP) and its GPLv2 implementations that were developed in the pas
+ t year.
+SUMMARY:ISP's black box - provisioning behind the scenes
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5216.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5216@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the last years\, mobile security and specifically GSM has be
+ en attacked in many different ways. It was demonstrated how to sniff and cr
+ ack traffic\, how to impersonate a subscriber by placing a fake call and th
+ e general security characteristics of this mobile protocol stack have been
+ evaluated.In this presentation\, we will check out a part of the protocol p
+ rocedures that hasn't been looked at yet\, specifically Mobile Terminated s
+ ervices.
+SUMMARY:Let Me Answer That for You - adventures in mobile paging
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5316.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5316@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 1 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5383.en.html
+DTSTART;TZID=Europe/Berlin:20121229T124500
+UID:5383@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 2 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5384.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5384@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 3 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5305.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5305@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We're winning! The future looks like network politics!Wait\, w
+ hat the hell are network politics and how do they work? Is that like the P
+ irate Party\, or the IETF\, or Anonymous?
+SUMMARY:Long live the protocoletariat!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5124.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5124@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Security is moving deeper into hardware and so should security
+ research. This talks introduces microprobing\, an old technique for snoopin
+ g on data inside chips\, and details a low-cost probing setup.
+SUMMARY:Low-Cost Chip Microprobing
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5088.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5088@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:You might remember Tamagotchi virtual pets from the 1990's. The
+ se toys are still around and just as demanding as ever! This talk covers my
+ attempts to hack the latest Tamagotchis. Starting with the IR interface\,
+ and moving down into the hardware\, this presentation will discuss techniqu
+ es for reverse engineering a device with limited inputs\, computing power a
+ nd debugging capabilities.
+SUMMARY:Many Tamagotchis Were Harmed in the Making of this Presentation
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5180.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5180@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Autonomer Drumroboter\, robotisches Glockenspiel oder klingende
+ Installation: Musikinstrumente zu modifizieren und selbstzubauen bietet mu
+ sik- und technikaffinen Geeks die Möglichkeit\, vorgefertigten Klang-Setups
+ etwas eigenständiges entgegenzusetzen. Drumroboter und Klanginstallationen
+ üben dabei sowohl physisch als auch optisch einen besonderen Reiz aus: die
+ Quelle des Klangs wird entdeckt.
+SUMMARY:Marvin und der Blues - Wie Roboterinstrumente zum Musik machen benu
+ tzt werden können
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5282.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5282@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Mit RFID-Lesegeräten Menschen tracken - keine Zukunftsvision.
+SUMMARY:Meine Kleidung funkt - Tracking von Menschen durch in Kleidung inte
+ grierte RFID-Chips
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5289.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5289@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Meldegesetz und der erfolgreiche Protest dagegen.
+SUMMARY:Meldegesetz - Was aus dem 57-Sekunden-Gesetz wurde
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5285.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5285@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Unsichere Studierenden- und Mensakarten. Eine wissenschaftliche
+ Auswertung.
+SUMMARY:Men who stare at bits - RFID-Studierendenkarten mit Fehlern
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5393.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5393@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Contactless smartcards have become widespread for applications
+ such as ticketing\, access control\, identification and payments. Side-chan
+ nel analysis (SCA) is a powerful type of passive implementation attack that
+ enables to extract the secret keys of cryptographic devices. At the exampl
+ e of NXP's Mifare DESfire MF3ICD40 smartcards we demonstrate that SCA attac
+ ks can be applied to cryptographic RFID devices: By exploiting the electro-
+ magnetic information leakage of the cards\, its cryptographic keys are reve
+ aled.We introduce our open-source tools for analyzing contactless smartcard
+ s\, i.e.\, an ISO 14443 RFID reader (http://sourceforge.net/projects/reader
+ 14443) and the card emulator Chameleon (http://sourceforge.net/projects/cha
+ meleon14443). We then present the probably worst realization of a commercia
+ l contactless payment system ever and detail on various real-world attacks
+ on this widespread (in Germany) system\, e.g.\, how to 'milk the digital ca
+ sh cow' by modifying the credit balance and convert zeros and ones into rea
+ l money. The content of the talk is joint work with Ingo von Maurich\, Davi
+ d Oswald and Christof Paar.
+SUMMARY:Milking the Digital Cash Cow - Extracting Secret Keys of Contactles
+ s Smartcards
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5280.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5280@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Massive open online courses are the vogue of the season when it
+ comes to discussing the future of university-level education. But we’re on
+ ly starting to see what education at this scope means and how it can be sup
+ ported best\, in terms of both didactics and technology. This talk is an in
+ side report by two instructors who have delved into the experience of teach
+ ing large audiences online. We share the lessons that we have learned: how
+ to spark student interest\, how to put intuition before formal theories\, h
+ ow to streamline production and much more. And we point out what needs to b
+ e done to truly democratize education from the viewpoint of both the studen
+ ts and the instructors.
+SUMMARY:Millions of Lessons Learned on Electronic Napkins - On the way to f
+ ree(ing) education
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5102.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5102@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In den letzten Jahren haben sich netzpolitische Kräfteverhältni
+ sse auf interessante Weise verschoben. Neue Allianzen bilden sich sowohl ge
+ gen\, als auch für das freie Internet – und dennoch bleibt der Aktivismus w
+ eit hinter seinem Potential zurück.
+SUMMARY:Netzaktivsten! Ist das alles\, was wir drauf haben? - Eine subjekti
+ ve Bestandsaufnahme
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5134.en.html
+DTSTART;TZID=Europe/Berlin:20121227T214500
+UID:5134@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Human interface design for musical instruments presents unique
+ challenges and vast new possibilities. The proliferation of low cost rapid
+ -prototyping tools has put the means of fabricating instruments within reac
+ h of the performing musician. In this talk\, I'll go through the design pr
+ ocess for my main performance controller (The Mojo)\, my multiplayer instru
+ ments (aka Jamboxes) and my new RoboCaster guitar-controller.
+SUMMARY:New Human Interfaces for Music - DIY MIDI Controllers
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5404.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5404@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:NOC Review - NOC Review about the 29C3
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5385.en.html
+DTSTART;TZID=Europe/Berlin:20121227T113000
+UID:5385@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:On the topic of resistance.
+SUMMARY:Not my department
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5037.en.html
+DTSTART;TZID=Europe/Berlin:20121228T001500
+UID:5037@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Gut gereift und mit verbesserter Rezeptur.Aber immer noch:Zwei
+ sich auf Couchen fläzende Teams gehirnwinden\, spitzfinden und assoziieren
+ gegeneinander an\, um Bilderrätsel aus den Gefilden IT\, Netzgesellschaft u
+ nd Informatik zu entwirren.(Hashtag: #Nougatbytes)
+SUMMARY:Nougatbytes 10 - Gebilde(r)ter Hirnsalat – die rhekkcüЯ der Bilderr
+ ätsel
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5203.en.html
+DTSTART;TZID=Europe/Berlin:20121228T143000
+UID:5203@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Polish government decided in favour of open-licensed e-textbook
+ s. This is not to liking of big textbook publishers\, reaping in profits ha
+ nd over fist. While their black PR campaign focuses on technicalities\, it
+ seems obvious that their real beef is with the liberal licensing.
+SUMMARY:OMG! OER! - How big business fights open education in Poland\, and
+ how open education fights back!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5210.en.html
+DTSTART;TZID=Europe/Berlin:20121229T140000
+UID:5210@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Security Assertion Markup Language (SAML) is a widely adopt
+ ed language for making security statements about subjects. It is a critical
+ component for the development of federated identity deployments and Single
+ Sign-On scenarios. In order to protect integrity and authenticity of the e
+ xchanged SAML assertions\, the XML Signature standard is applied. However\,
+ the signature verification algorithm is much more complex than in traditio
+ nal signature formats like PKCS#7. The integrity protection can thus be suc
+ cessfully circumvented by application of different XML Signature specific a
+ ttacks\, under a weak adversarial model.
+SUMMARY:On Breaking SAML - Be Whoever You Want to Be
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5399.en.html
+DTSTART;TZID=Europe/Berlin:20121227T110000
+UID:5399@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Opening Event
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5308.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5308@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Was bedeutet das Zeitalter offener Designs für die Sicherheit v
+ on Schlössern? Zum Beispiel solchen\, die auf eine geringe Verbreitung eine
+ s Schlüssels setzen? Ein Beispiel sind die sogenannten Hochsicherheitsversi
+ onen von Polizeihandschellen. Der Talk zeigt was (und wie) sich in diesem B
+ ereich mit Lasercuttern und 3D Druckern erreichen lässt - sowie welche komp
+ lexeren Angriffsziele noch warten. Als Ausweg aus der Problematik kopierbar
+ er Schlüssel gelten digitale Schlösser\, aber sie kranken anders an offenen
+ Quellen: sie haben keine! Im Rahmen eines Open Source Lock Projektes haben
+ wir uns daher ein reflashbares Vorhängeschloss angesehen\, doch noch ehe w
+ ir den Programmieradapter angeschlossen hatten fanden wir eine Schwachstell
+ e der Hardware... Leider kein Einzelfall!
+SUMMARY:Open Source Schlüssel und Schlösser - Offene Quellen zum Bösen und
+ Guten: von downloadbaren Handschellenschlüsseln zu sicheren elektronischen
+ Schlössern
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5265.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5265@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:x86 processors contain a surprising amount of built-in memory t
+ ranslation logic\, which is driven by various data tables with intricate en
+ try formats\, and can produce various kinds of traps and other interesting
+ computational effects. These features are mostly relics of earlier\, more c
+ ivilized times\, when Jedi Knights tried to protect the Old Republic OSes w
+ ith segmentation\, supervisor bits\, and hardware task support\, but were d
+ efeated by processor de-optimizations and performance concerns and left unu
+ sed by both Windows and UNIX systems – and explored only by hackers. For th
+ e rest of the world\, an x86 PC was a "von Neumann architecture" with most
+ of its strangeness unused.
+SUMMARY:Page Fault Liberation Army or Gained in Translation - a history of
+ creative x86 virtual memory uses
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5323.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5323@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Vortrag handelt über Getreidezüchtung. Am Beispiel von Weiz
+ en soll der langjährige Prozess beschrieben werden\, den es benötigt\, um
+ eine neue Sorte auf den Markt zu bringen. Es sollen die biologischen Grundl
+ agen sowie die benötigte Technik vorgestellt werden. Außerdem wird auf die
+ Problematik eingegangen\, die die Konzentration des Marktes auf wenige groß
+ e Konzerne mit sich bringt.
+SUMMARY:Pflanzenhacken richtig - Einblicke in die Weizenzüchtung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5095.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5095@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:To date\, remote vehicle communications have provided little in
+ the way of privacy. Much information and misinformation has been spread on
+ what the system is and can do\, especially within the information security
+ community. The recent field trial in the US of a connected vehicle infrast
+ ructure raises the level of concern amongst all who are aware of existing p
+ rivacy issues.
+SUMMARY:Privacy and the Car of the Future - Considerations for the Connecte
+ d Vehicle
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5101.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5101@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:ACTA war das beherrschende Thema des zweiten Halbjahres. Mit AC
+ TA sollte der Weg einer Privatisierung der Rechtsdurchsetzung weiter gegang
+ en werden. Was das konkret bedeutet\, können wir bereits im Ausland sehen:
+ Netzsperren\, 3-Strikes-Systeme und eine Echtzeit-Überwachung des Datenverk
+ ehrs zur Bekämpfung von Urheberrechtsverletzungen. Existierende Modelle in
+ anderen europäischen Staaten zeigen\, dass diese Maßnahmen erhebliche grund
+ - und datenschutzrechtliche Probleme aufwerfen.
+SUMMARY:Privatisierung der Rechtsdurchsetzung - Von ACTA\, IPRED und Freund
+ en
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5266.en.html
+DTSTART;TZID=Europe/Berlin:20121230T140000
+UID:5266@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Zensur im Internet betrifft immer mehr Nutzer. Wir kennen Tools
+ wie Proxies\, VPNs oder Tor Bridges. Doch welche weiteren Werkzeuge unters
+ tützen die Nutzer vor Ort? Wo sind die Stärken und Schwächen? Der Vortrag s
+ tellt einige von diesen vor und zeigt die Stärken und Schwächen.
+SUMMARY:Proximax\, Telex\, Flashproxy oder Tor Bridges - Übersicht über akt
+ uelle Zensurumgehungssoftware
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5374.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5374@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION: This talk will give an overview of the ongoing work by the W3C
+ on a controversial general purpose Javascript cryptography API in context
+ of the larger desire to create trusted and encrypted cloud services with ri
+ ch web applications. Today\, cryptography is difficult to use and the Web i
+ s an insecure environment at best\, but can this situation be improved and
+ cryptography be put in the hands of ordinary developers and users? The W3C
+ specification\, currently under development\, will be described\, as well a
+ s its interaction with other parts of the emerging Web Security Model at th
+ e W3C and IETF such as Content Security Policy\, HTTP Strict Transport Secu
+ rity\, and Certificate Transparency. A number of use-cases\, ranging from d
+ ecentralized identity systems to secure cloud services for activists\, will
+ be detailed. As the specification will be under active development until a
+ utumn 2013\, feedback from the hacker community is needed!
+SUMMARY:Re-igniting the Crypto Wars on the Web
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5138.en.html
+DTSTART;TZID=Europe/Berlin:20121228T131500
+UID:5138@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In 1791\, the political reformer Jeremy Bentham theorized the P
+ anopticon\, whose design promised to allow a single Inspector to surveil (e
+ xercise "inspective force" over) large numbers of criminals or workers. In
+ recent years\, the advent of a suitable technical apparatus – CCTV\, ISP ta
+ ps (network traffic interception)\, data banks\, and so on – has extended t
+ he proposed 30m circumference of Bentham’s structure to\, and beyond\, the
+ physical boundaries of entire countries. While total surveillance is often
+ perceived as a feature of modernity\, its conceptual and epistemological fr
+ amework is rooted in the Romantic period\, moreover at a key juncture in th
+ e history of ideas concerning individual subjectivity\, rights and freedoms
+ . David Barnard-Wills refers to inspective culture as a "nexus of surveilla
+ nce\, identity and language" (2012). In this talk\, we examine this nexus i
+ n the historical period that first\, and so powerfully\, imagined the fully
+ surveilled world.
+SUMMARY:Romantic Hackers - Keats\, Wordsworth and Total Surveillance
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5402.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5402@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Privacy International\, Agentura.Ru\, the Russian secret servic
+ es watchdog\, and Citizen Lab have joined forces to launch a new project en
+ titled 'Russia’s Surveillance State'. The aims of the project are to undert
+ ake research and investigation into surveillance practices in Russia\, incl
+ uding the trade in and use of surveillance technologies\, and to publicise
+ research and investigative findings to improve national and international a
+ wareness of surveillance and secrecy practices in Russia. The project is m
+ ade possible with support from the Canada Centre for Global Security Studie
+ s\, Munk School of Global Affairs\, at the University of Toronto.
+SUMMARY:Russia’s Surveillance State
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5140.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5140@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The triple meltdown of the Fukushima Dai-Ichi nuclear power pla
+ nt in March last year and the release of radioactive material that has ensu
+ ed have left a good part of Northern Japan contaminated with unknown amount
+ of radioactivity. An outstanding lack of transparency from both the govern
+ ment and the power utility then resulted in a near total lack of informatio
+ n concerning the levels of radiation in the\, yet unknown\, contaminated ar
+ eas. As a response\, concerned citizen have started to take upon themselves
+ this challenging task. However it quickly became clear that handheld measu
+ rements wouldn't scale up to the full magnitude of the area to cover. New m
+ eans of measuring radiation accurately\, quickly and cheaply were needed.
+SUMMARY:Safecast: DIY and citizen-sensing of radiation - Empowering citizen
+ in the wake of Fukushima triple-meltdown disaster
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5059.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5059@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Modern civilization unconditionally depends on information syst
+ ems. It is paradoxical but true that ICS/SCADA systems are the most insecur
+ e systems in the world. From network to application\, SCADA is full of conf
+ iguration issues and vulnerabilities.
+SUMMARY:SCADA Strangelove - or: How I Learned to Start Worrying and Love Nu
+ clear Plants
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5177.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5177@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk will go into some of challenges\, solutions\, and sto
+ ries from securing a campaign for the 2012 US presidential election.
+SUMMARY:Securing the Campaign - Security and the 2012 US Presidential Elect
+ ion
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5225.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5225@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In this talk we will survey some 30 recent attacks on the Russi
+ an GOST block cipher.Background: GOST cipher is the official encryption sta
+ ndard of the Russian federation\, and also has special versions for the mos
+ t important Russian banks. Until 2012 there was no attack on GOST when it i
+ s used in encryption with random keys. I have developed more than 30 differ
+ ent academic attacks on GOST the fastest has complexity of 2^118 to recover
+ some but not all 256-bit keys generated at random\, which will be presente
+ d for the first time at CCC conference. It happens only once per decade tha
+ t a government standard is broken while it is still an official government
+ standard (happened for DES and AES\, no other cases known). All these are b
+ roken only in academic sense\, for GOST most recent attacks are sliding int
+ o maybe arguably practical in 30 years from now instead of 200 years... Our
+ earlier results were instrumental at ISO for rejecting GOST as an internat
+ ional encryption standard last year. Not more than 5+ block cihers have eve
+ r achieved this level of ISO standardisation in 25 years and it NEVER happe
+ nded in history of ISO that a cipher got broken during the standardization
+ process. Two main papers with 70+30 pages respectively which are http://epr
+ int.iacr.org/2011/626 and http://eprint.iacr.org/2012/138. Two other papers
+ have been already published in Cryptologia journal which specializes in se
+ rious military and government crypto. The talk will cover three main famili
+ es of attacks on GOST: high-level transformations\, low- level inversion/MI
+ TM/guess-then-software/algebraic attacks and advanced truncated differentia
+ l cryptanalysis of GOST.
+SUMMARY:Security Evaluation of Russian GOST Cipher - Survey of All Known At
+ tacks on Russian Government Encryption Standard
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5244.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5244@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Was hat sich im letzten Jahr im Bereich IT-Sicherheit getan? We
+ lche neuen Entwicklungen haben sich ergeben? Welche neuen Buzzwords und Tre
+ nds waren zu sehen?
+SUMMARY:Security Nightmares - Damit Sie auch morgen schlecht von Ihrem Comp
+ uter träumen.
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5167.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5167@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In The Netherlands\, this year the community-driven mobile telc
+ o Limesco has started operations. We're providing voice\, SMS and data serv
+ ices to dozens of hackers in our country.One of the founders of Limesco wil
+ l give a lecture about mobile telephony in The Netherlands\, encompassing t
+ opics like what companies are involved in the system\, how tariffs are cons
+ tructed and the role of government regulations.
+SUMMARY:Setting mobile phones free - An overview of a mobile telephony mark
+ et and how a community-driven operator is born
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5164.en.html
+DTSTART;TZID=Europe/Berlin:20121228T160000
+UID:5164@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Betrieb von WLAN-Funk-Netzen und auch von offenen oder frei
+ en Netzen ist heute weit verbreitet und Teil der Diskussion um die "Culture
+ s of Sharing". Der Vortrag soll die Grundlagen der Haftung für offene Netze
+ und die Entwicklung der Rechtsprechung vom Landgericht Hamburg ("gestern")
+ zum BGH-Urteil "Sommer unseres Lebens" und den Einfluss aktueller Rechtspr
+ echung des Europäischen Gerichtshofs\, des Bundesgerichtshofs und der Insta
+ nzgerichte darstellen ("heute"). Ein Ausblick auf die Folgen dieser neuen\,
+ teilweise abweichenden Rechtsprechung und auf die Gesetzesinitiativen der
+ SPD und der Linken ("morgen") soll den Vortrag abrunden.
+SUMMARY:Sharing Access – Risiken beim Betrieb offener (WLAN-)Netze - Stand
+ gestern\, heute und morgen
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5127.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5127@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Eid des Hippokrates\, der das Handeln von Ärzten ethisch le
+ iten soll\, ist zwischen 2.500 und 2.000 Jahre alt und tatsächlich wohl die
+ erste 'Datenschutz-Vorschrift' überhaupt. So heißt es: "Was ich bei der Be
+ handlung oder auch außerhalb meiner Praxis im Umgange mit Menschen sehe un
+ d höre\, das man nicht weiterreden darf\, werde ich verschweigen und als Ge
+ heimnis bewahren." [1]
+SUMMARY:Siechtum und Sterben der ärztlichen Schweigepflicht
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5121.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5121@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Green-IT kennen wir inzwischen zur Genüge. Computer können aber
+ nicht nur nicht "green" sein\, sondern auch unfair und unsozial\, von der
+ Rohstoffgewinnung bis zur Verschrottung. Unfair spart nämlich Geld. Der Ged
+ anke\, faire Produkte anzubieten und zu kaufen\, ist inzwischen weit verbre
+ itet\, allerdings eher bei Kaffee oder Kleidung. Ein Angebot an fairer IT f
+ ehlt. Die Industrie hat sich noch nicht auf den Weg gemacht\, faire Compute
+ r herzustellen. Wir Nutzer haben kaum die Wahl – verändern können wir aber
+ durchaus etwas. Der Vortrag erklärt\, was und wie.
+SUMMARY:Sind faire Computer möglich?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5123.en.html
+DTSTART;TZID=Europe/Berlin:20121229T143000
+UID:5123@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The lecture would address topics related to reverse engineering
+ for mobile platforms\, especially from the Android point of view. The main
+ aspects of the presentation is a new approach to reverse engineering side
+ effects problem: some low footprint inspection techniques that grant analys
+ ts with the ability to access the program memory without altering its behav
+ ior. One technique is presented in particular - Android service injection -
+ and is demonstrated.
+SUMMARY:Small footprint inspection techniques for Android - Reverse enginee
+ ring on Android platforms
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5239.en.html
+DTSTART;TZID=Europe/Berlin:20121228T183000
+UID:5239@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk will give an overview on the technology\, the laws an
+ d the technical guidelines of the smartMeter roll-out in Germany.
+SUMMARY:SmartMeter - A technological overview of the German roll-out
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5336.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5336@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Forderungen nach einer gerechten Sprache (also einer Sprache fr
+ ei von Rassismus\, Sexismus und anderen menschenfeindlichen Ideologien) sto
+ ßen häufig auf Unverständnis und Ablehnung. Unverständnis\, weil statt der
+ sozialen Wirklichkeit die Sprache kritisiert wird\, mit der sie beschrieben
+ wird. Ablehnung\, weil Sprachkritik häufig als Sprechverbot empfunden wird
+ .
+SUMMARY:Sprache\, Ungleichheit und Unfreiheit
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5378.en.html
+DTSTART;TZID=Europe/Berlin:20121229T124500
+UID:5378@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Stabilitätsanker & Wachstumslokomotive geben als politische Met
+ aphern ungewollt Auskunft über das Ausmaß der europäischen Wirtschafts- und
+ Finanzkrise. Wie kommt so ein Begriff in Verkehr? Wer gebraucht ihn? Zu we
+ lchem Zweck? Was fördert die Analyse der Metaphern zutage?
+SUMMARY:Stabilitätsanker & Wachstumslokomotive
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5230.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5230@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Stylometry uses linguistic information found in a document to p
+ erform authorship recognition. In this talk\, we will present how stylometr
+ y can be used to deanonymize users in multilingual underground forums. Our
+ initial result shows that in spite of differences in languages and text len
+ gths\, regular stylometric methods perform well in identifying users in thi
+ s context. We will also present the improved version of Anonymouth\, a tool
+ to anonymize written document\, with user studies.
+SUMMARY:Stylometry and Online Underground Markets
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5390.en.html
+DTSTART;TZID=Europe/Berlin:20121228T140000
+UID:5390@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Don't call us if your campaign does not work! And worse\, every
+ one's been harassed or arrested.
+SUMMARY:Tactical Tech - Bridging the Gap
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5228.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5228@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Role of Technology in Post-Revolution Tunisia & Egypt: Inte
+ rnet activists have embarked on many online projects to empower citizens wi
+ th necessary information about their elected officials.
+SUMMARY:Technology in Post-Revolution Tunisia and Egypt
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5195.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5195@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Executable and Linkable Format (ELF) is omnipresent\; relat
+ ed OS and library code is run whenever processes are set up and serviced (e
+ .g.\, dynamically linked). The loader is the stage manager for every execut
+ able. Hardly anyone appreciates the work that the ELF backstage crew (inclu
+ ding the linker and the loader) puts in to make an executable run smoothly.
+SUMMARY:The Care and Feeding of Weird Machines Found in Executable Metadata
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5206.en.html
+DTSTART;TZID=Europe/Berlin:20121227T214500
+UID:5206@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the world of digital activism\, distributed denial of servic
+ e attacks present relatively low barriers to popular participation\, have a
+ high potential for attracting large numbers of first-time and repeat parti
+ cipants\, and can attract large amounts of media attention. But though suc
+ h actions popular\, are they ethical? In this talk I will be presenting an
+ ethical framework for the analysis of activist DDOS actions. The framework
+ is grounded in a historical analysis of various activist DDOS actions\, suc
+ h as the IGC attacks in Spain in the late 90s\, Electronic Disturbance Thea
+ ter actions in the early 2000s\, and the Anonymous-led Operation Payback at
+ tacks in 2010. Each historical case study presents a unique confluence of
+ technological\, political\, legal and operational factors allowing for a fu
+ ll spectrum of ethical analysis.
+SUMMARY:The Ethics of Activist DDOS Actions - A Historical Analysis
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5256.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5256@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Have you ever been staring for nights at binary or hexadecimal
+ data flows extracted from an USB channel? Don't you remember yourself searc
+ hing for some patterns and similarities in this fuc***g mess of zeros and o
+ nes grabbed from a binary configuration file? How long did it take you to f
+ ind an 16 bits decimal size field last time you reversed an IPC communicati
+ on protocol?Did you know you were not alone and that among them\, Rob Savoy
+ e (@ FOSDEM-08) and Drew Fisher (@ 28C3) have already reported the main dif
+ ficulties of the RE operations. Both of them called for the creation of a t
+ ool which would help experts in their work.
+SUMMARY:The future of protocol reversing and simulation applied on ZeroAcce
+ ss botnet - Mapping your enemy Botnet with Netzob
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5274.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5274@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The current European data protection directive is from 1995\, w
+ hich was when the internet had not hit Brussels' decision-makers yet. Now\,
+ 17 years later\, it is being completely re-writen. Will it meet the challe
+ nges of the age of big data? Will it have any effect on non-EU data hoarder
+ s? How will it deal with user-generated consent? What is this strange new "
+ right to be forgotten"? And what about privacy by design?
+SUMMARY:The Grand EU Data Protection Reform - A latest battle report by so
+ me key actors from Brussels
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5306.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5306@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:At the very beginning\, Tor was just a socks proxy that protect
+ ed the origin and/or destination of your TCP flows. Now the broader Tor eco
+ system includes a diverse set of projects -- browser extensions to patch Fi
+ refox and Thunderbird's privacy issues\, Tor controller libraries to let yo
+ u interface with the Tor client in your favorite language\, network scanner
+ s to measure relay performance and look for misbehaving exit relays\, LiveC
+ Ds\, support for the way Android applications expect Tor to behave\, full-n
+ etwork simulators and testing frameworks\, plugins to make Tor's traffic lo
+ ok like Skype or other protocols\, and metrics and measurement tools to kee
+ p track of how well everything's working. Many of these tools aim to be use
+ ful beyond Tor: making them modular means they're reusable for other anonym
+ ity and security projects as well. In this talk\, Roger and Jake will walk
+ you through all the tools that make up the Tor software world\, and give yo
+ u a better understanding of which ones need love and how you can help.
+SUMMARY:The Tor software ecosystem
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5178.en.html
+DTSTART;TZID=Europe/Berlin:20121230T140000
+UID:5178@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Galaksija was to be in Yugoslavia what Commodore and Sinclair w
+ ere in the west. Whether it succeeded or not\, its deceptively simple desig
+ n can still teach us a lot of interesting tricks on how to make a usable co
+ mputer and operating system with as few transistors and bits as possible.
+SUMMARY:The ultimate Galaksija talk - Everything about a Yugoslavian microc
+ omputer halfway between a TRS-80 and a ZX 80
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5044.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5044@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In this year’s talk\, I tie on my 28c3 talk and present timing
+ side channels from a defending viewpoint: How can one mitigate timing side
+ channels? Aren’t random delays sufficient to prevent timing side channels i
+ n practice? What is the minimum size of random delays to be effective? Are
+ there other delay strategies besides random delays that are more effective
+ and efficient?
+SUMMARY:Time is NOT on your Side - Mitigating Timing Side Channels on the W
+ eb
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5380.en.html
+DTSTART;TZID=Europe/Berlin:20121228T140000
+UID:5380@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir wissen seit ein paar Jahren\, dass der Staat technisch in d
+ er Lage ist\, die Computer einiger seiner Bürger zu infiltrieren. Aber soll
+ er das auch dürfen? Was hat sich in den letzten Monaten beim Staatstrojane
+ r getan?
+SUMMARY:Trojaner-Blindflug - Spionage-Software von Staats wegen
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5091.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5091@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hardware-basierte Festplattenvollverschlüsselungen in Form soge
+ nannter SEDs (Self-Encrypting Drives) werden gemeinhin als sichere und perf
+ ormante Alternative zu Software-basierter Verschlüsselung wie BitLocker und
+ TrueCrypt gesehen. Während der Performance-Gewinn und die Benutzerfreundli
+ chkeit von SEDs\, bspw. Intel's SSD 320 bzw. SSD 520\, außer Frage stehen\,
+ ist der Sicherheits-Gewinn deutlich geringer als bisher angenommen. Teilwe
+ ise sind Systeme die auf SEDs basieren gar schwächer als vergleichbare Syst
+ eme die auf Software-Verschlüsselung basieren.
+SUMMARY:(Un)Sicherheit Hardware-basierter Festplattenverschlüsselung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5396.en.html
+DTSTART;TZID=Europe/Berlin:20121228T160000
+UID:5396@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Weltbilder der Informatik sind in mancher Hinsicht denen in der
+ Hacker- und Hackerinnen-Community nicht unähnlich.
+SUMMARY:Was ist\, was kann\, was soll Gender Studies Informatik?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5160.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5160@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the Free City of Hamburg\, which is one of 16 German states\
+ , a coalition of hackers\, activists and other players of civil society hav
+ e drafted the most revolutionary Freedom of information law in the world. T
+ he law obliges the state to proactively publish all important public inform
+ ation (such as contracts\, studies\, construction permits) in an OpenData f
+ ormat on the Internet. After the start of a referendum campaign\, the law w
+ as passed unanimously by the state parliament in June 2012 to avoid a publi
+ c vote on it.
+SUMMARY:We are all lawmakers! - How to further transparency by law – the Ha
+ mburg example and beyond
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5208.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5208@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Accessibility of digital content is a hugely misunderstood issu
+ e. Programmers and content developers tend to view it as a distraction or a
+ special interest concern. Accessibility advocates fail to describe it in t
+ erms that would put it in the proper place for other technologists\, in par
+ ticular security practitioners.
+ We argue that if a format or a document has
+ systemic accessibility problems\, then accessibility is likely to be the l
+ east of its problems\; that accessibility only collapses first\, like a can
+ ary in a mine\, and security is next to follow. We argue that many accessib
+ ility problems\, just like many security problems\, stem from documents bei
+ ng hard to parse or containing executable content\, and that the accessibil
+ ity community is only the first to suffer\, due to not having the manpower
+ to make extremely complicated formats to almost work almost always. It's an
+ arms race tougher than the security patching cycle\, made worse by there b
+ eing no common model for what accessibility properties should look like.
+SUMMARY:What accessibility has to do with security
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5283.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5283@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:After the political and legislative failure of the blocking and
+ filtering proposals in Germany (#Zensursula) and the EU (Child Protection
+ Directive) several players stepped up to implement the measures that previo
+ usly have been envisioned as compulsory but now on a "self-regulatory" basi
+ s.
+SUMMARY:White IT\, Clean IT & CEO Coalition - How the government tries to e
+ ncourage privatized policy inforcement and thereby bypasses and circumvents
+ democratic processes
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5327@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This action-packed lecture presents the inner workings of the a
+ uthor's from-scratch implementation of a USB Mass Storage disk in user-land
+ Python\, along with some embarrassing bugs in operating systems that suppo
+ rt such disks. The lecture concludes with an introduction to Active Antifo
+ rensics\, in which a thumbdrive's own firmware can recognize and defend its
+ elf against disk imaging and other forensic tools.
+SUMMARY:Writing a Thumbdrive from Scratch - Prototyping Active Disk Antifor
+ ensics
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5262.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5262@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Seit anderthalb Jahren begleitet FragDenStaat.de die deutsche I
+ nformationsfreiheit in der Praxis und dokumentiert die Korrespondenz zwisch
+ en Anfragestellenden und Behörden. Welche Informationen gibt der Staat prei
+ s\, und gegen welche Veröffentlichungen kämpft er sogar bis vor Gericht? Di
+ e interessantesten Fälle werden genauer beleuchtet und eine Bewertung zur L
+ age der staatlichen Information in Deutschland abgegeben.
+SUMMARY:Zur Lage der Information - 1.5 Jahre FragDenStaat.de
+STATUS:CONFIRMED
+END:VEVENT
+END:VCALENDAR
(DIR) diff --git a/examples/schedule.en.produced.ics b/examples/schedule.en.produced.ics
@@ -0,0 +1,1828 @@
+BEGIN:VCALENDAR
+VERSION:2.0
+CALSCALE:GREGORIAN
+PRODID:-//Pentabarf//Schedule//EN
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5333.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5333@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Did you notice 262 42 in your mobile phone network search lis
+ t at the last CCC events? Did you and your friends buy SIM cards at the
+ PoC and help test the network by calling each other\, or by calling thro
+ ugh the bridge to the DECT network services? Did you ever wonder about t
+ he details of this open source test network\, set up by a team of volunt
+ eers in the middle of the city? We would like to tell you all the detail
+ s of the cell phone network we operate at 29C3\, and show you some fancy
+ graphs based on the network activity!
+SUMMARY:29C3 GSM: Cell phone network review - 262 42 - The full spectrum
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5205.en.html
+DTSTART;TZID=Europe/Berlin:20121229T140000
+UID:5205@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:There are hundreds\, if not thousands\, of news articles and
+ blog posts about the BlackHole Exploit Kit. Usually\, each story covers
+ only a very narrow part of the subject matter. This talk will summarize
+ the history of the BlackHole Exploit Kit into one easy to follow story.
+ There will be diagrams and flow-charts for explaining code\, rather than
+ a giant blob of illegible Javascript\, PHP\, or x86 Assembly.
+SUMMARY:Analytical Summary of the BlackHole Exploit Kit - Almost Everythi
+ ng You Ever Wanted To Know About The BlackHole Exploit Kit stor!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5146.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5146@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:There's about 100 top-level domains signed with DNSSEC and .n
+ l recently hit 1M second-level domains. At this occasion\, we take a loo
+ k at the goods and the bads of DNSSEC deployment\, including amplificati
+ on attacks\, Zensursula-like DNS redirects\, China DNS injection and NAS
+ A key rollover mistakes. We will find out what DNSCurve and Namecoin pro
+ mise to make better and what Zooko's triangle has all to do with this.
+SUMMARY:An Overview of Secure Name Resolution - DNSSEC\, DNSCurve and Nam
+ ecoin
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5237.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5237@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:With Visa and Mastercard pushing for EMV (http://www.emvco.co
+ m\, aka “chip and pin”) rollout in the United States\, the uptake of
+ contactless payment and the use of mobile NFC wallets\, the chipcard se
+ curity community will soon be getting more eyes to analyze the protocols
+ in use with chip and contactless credit card transactions.
+SUMMARY:A Rambling Walk Through an EMV Transaction
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5299.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5299@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Verfassungsschutzskandale gibt es nicht erst seit der Entdeck
+ ung des NSU vor einem Jahr. Vorgestellt werden: sie Affaire Traube\, der
+ Schmücker-Prozess\, das Celler Loch\, die Vulkan-Affaire\, der Anschla
+ gsversuch auf das Jüdische Gemeindehaus West-Berlin\, vier Jahrzehnte B
+ eobachtung von Rolf Gössner. Vielleicht sind aber gar nicht die Pannen
+ der Skandal\, sondern vielmehr der ganz gewöhnliche Alltag des Verfassu
+ ngsschutzes.
+SUMMARY:Best of ... Verfassungsschutz - Der Verfassungsschutz schützt di
+ e Verfassung so wie Zitronenfalter Zitronen falten. Affaire Tra!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5379.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5379@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir schauen nicht zurück im Zorn\, aber jetzt auch nicht gra
+ de mit Euphorie. Im CCC-Jahresrückblick präsentieren wir Euch einige d
+ er hacktivistischen Themen des vergangenen Jahres\, an denen der CCC gea
+ rbeitet oder sich abgearbeitet hat. Diesmal mit schönen neuen Gesetzen\
+ , Hacker-Humor\, versäumten Gerichtsterminen\, bunten Blinkenlichtern u
+ nd Iggy Pop. Wir haben uns wirklich das ganze Jahr bemüht\, nur in begr
+ enztem Umfange zu prokrastinieren.
+SUMMARY:CCC-Jahresrückblick
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5319@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hypertext Transfer Protocol Secure (HTTPS) has evolved into t
+ he de facto standard for secure web browsing. But in the security commun
+ ity\, it has long been known that HTTPS is fundamentally broken\, and th
+ is has been confirmed by alarming hacks and security breaches at several
+ Certificate Authorities (CAs). To tackle the global collapse of trust i
+ n these central mediators of HTTPS communications and to augment HTTPS s
+ ecurity\, the EU has launched a proposal for strict regulation. Will the
+ se efforts succeed?
+SUMMARY:Certificate Authority Collapse - Will the EU Succeed in Regulatin
+ g HTTPS?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5263.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5263@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir brauchen ein maschinenlesbares und -schreibbares Gesetzge
+ bungsverfahren\, in dem jede Änderung transparent diskutiert und beschl
+ ossen wird. Der Bundestag öffnet und digitalisiert sich eher langsam un
+ d widerwillig\, dennoch kann man schon heute anfangen\, die Werkzeuge de
+ r parlamentarischen Zukunft in Deutschland zu gestalten und auszuprobier
+ en. Dazu stellen wir die Projekte OffenesParlament.de und das Bundes-Git
+ vor und zeigen\, wie es in Zukunft weitergehen könnte.
+SUMMARY:chmod o+rw bundestag - Mehr Transparenz und Teilhabe im Gesetzgeb
+ ungsprozess
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5398.en.html
+DTSTART;TZID=Europe/Berlin:20121230T183000
+UID:5398@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Some facts and stats about Congress\, plus stories and legend
+ s.
+SUMMARY:Closing Event
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5221.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5221@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir sind Zeugen eines seit einigen Jahren stattfindenden Wett
+ rüstens im Cyberspace. Immer mehr Staaten bauen militärische Cyberware
+ Einheiten auf\, die aus IT Spezialisten bestehen und dem Zweck dienen
+ \, bestenfalls IT Systeme abzusichern oder schlechterdings Systeme von
+ „Feinden“ anzugreifen.
+SUMMARY:Cyberpeace statt Cyberwar
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5301.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5301@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Aside from further development of traditional forensic techni
+ ques which involve post-mortem hard disk analysis\, in the last couple o
+ f years the field of computer forensics has been marked by significant d
+ evelopment of live forensic techniques and tools.Memory forensics is com
+ posed of two main activities: memory aquisition/capture and analysis. Th
+ is presentation will give an overview of the memory acquisition and anal
+ ysis techniques and tools on the Windows operating systems. The main par
+ t of the presentation will cover current exploitation techniques and met
+ hods for defeating bothq acquisition and analysis phase of the memory f
+ orensics\, as well as present a new approach for hiding specific artifac
+ ts from forensic tools. Based on the covered exploitation techniques\, s
+ ome suggestions and improvements of the current tools will be given.
+SUMMARY:Defeating Windows memory forensics
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5159.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5159@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Over the years we learned impressively how to oppose bad legi
+ slation hurting our freedoms online. We are now facing an even bigger ch
+ allenge: how to guarantee that a Free\, open\, decentralized Internet wi
+ ll be protected in the long run? In 2012 The Internetz won major battles
+ against SOPA/PIPA in the US\, and against ACTA in the EU. Yet\, we know
+ that the powerful industries and governments behind these projects will
+ never stop. They have an incentive to gain control of the Internet\, at
+ tacking fundamental rights and promoting technologies like "Deep Packet
+ Inspection"\, now being deployed in each and every corner of the Net\,
+ and used indifferently to break Net neutrality\, to filter\, block and
+ censor communications or to inspect citizens traffic.How to push for pro
+ posals that will ensure that the sharing of knowledge and culture\, citi
+ zens freedoms\, and access to an open infrastructure will be guaranteed
+ in the future public policies? How to become as successful in propositio
+ n as we are now in opposition?(Hint: it's political\, stupid!)
+SUMMARY:Defend your Freedoms Online: It's Political\, Stupid! - A Positiv
+ e agenda against the next ACTA\, SOPA\, and suchfacing an even !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5401.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5401@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Die Debatte um die Tarifreform der GEMA war eines der großen
+ Themen des Jahres 2012: Die Verwertungsgesellschaft geriet quer durch a
+ lle politischen Lager und gesellschaftlichen Schichten in die Kritik\, d
+ ie Warnungen vor einem großen Clubsterben wurden von Tausenden auf die
+ Straße getragen. Dies steigerte auch das Interesse an der »Cultural Co
+ mmons Collecting Society« (C3S)\, einem Graswurzelprojekt zur Gründung
+ einer neuen\, modernen1 und internetverstehenden Verwertungsgesellscha
+ ft\, die u. a. auch vollen Support für Creative-Commons-Lizenzen bieten
+ soll. 2012 war daher auch ein ereignisreiches Jahr für dieses Projekt\
+ , und 2013 sollen nach Plan die Gründung als Europäische Genossenschaf
+ t und die Antragsstellung beim Deutschen Patent- und Markenamt folgen.
+SUMMARY:Der Mord fällt aus - Ein Werkstattbericht der GEMA-Alternative C
+ 3S
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5382.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5382@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Am 6. November 2012 war der CCC vor dem Bundesverfassungsgeri
+ cht zur Anhörung über die Antiterrordatei und die Grenzen polizeiliche
+ r Datenverarbeitung geladen. Wir berichten über die Anhörung\, die d
+ ort vorgebrachten Argumente und die technische Konzeption der ATD. Und w
+ ir orakeln über ein mögliches Urteil im nächsten Jahr.
+SUMMARY:Die Antiterrordatei
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5181.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5181@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In den vergangenen Jahren wurde vor allem die Sprache von Pol
+ itikern auf dem Congress beleuchtet. Aber die schwurbelnde Politiker sin
+ d noch nicht die ganze Wahrheit. Wir möchten das Ganze daher um den zwe
+ iten wichtigen Mitspieler bei der Konstruktion von Realität ergänzen\,
+ um die Presse bzw. die Medien. Die Äußerungen von Politikern (zum Bei
+ spiel auf Pressekonferenzen) sollen dabei der Mediendarstellung gegenüb
+ ergestellt werden. Dabe}i wird deutlich werden\, dass es zwischen Polit
+ ikern und Medien Rückkopplungseffekte gibt.
+SUMMARY:Die Wahrheit\, was wirklich passierte und was in der Zeitung stan
+ d - Wie Medien unsere Wahrnehmung beeinflussens!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5338.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5338@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:With the post 9/11 rise of the leviathan national security st
+ ate\, the rule of law in the United States under the Constitution is inc
+ reasingly rule by secrecy\, surveillance and executive fiat.
+SUMMARY:Enemies of the State: What Happens When Telling the Truth about S
+ ecret US Government Power Becomes a Crime - Blowing the Whistle on Spyin
+ g\, LngAying & Illegalities in the Digital Eraxecutive fiat.
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5104.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5104@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This presentation will cover a demonstration of the new versi
+ on of the Canape protocol analysis tool being released for Ruxcon. Durin
+ g the course of the presentation various attack scenarios against the VM
+ Ware ESXi binary protocol will be demonstrated using Canape.
+SUMMARY:ESXi Beast - Exploiting VMWARE ESXi Binary Protocols Using CANAPE
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5077.en.html
+DTSTART;TZID=Europe/Berlin:20121229T131500
+UID:5077@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Recently\, several research papers in the area of computer se
+ curity were published that may or may not be considered unethical. Looki
+ ng at these borderline cases is relevant as today’s research papers wi
+ ll influence how young researchers conduct their research. In our talk w
+ e address various cases and papers and highlight emerging issues for eth
+ ic committees\, internal review boards (IRBs) and senior researchers to
+ evaluate research proposals and to finally decide where they see a line
+ that should not be crossed.
+SUMMARY:Ethics in Security Research
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5085.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5085@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We know\, that cooking is an art. Selecting the ingredients\,
+ carefully washing\, pealingand cutting them before you put them into th
+ e right dish at the right time with the right heat.Watching the food cha
+ nge his color\, form and consistency\, seasoning it to develop it'sflavo
+ rs and serving it on beautiful plates is a pleasure.For some\, but not
+ for all.Those who love cooking can spend hours at the stove andrelax whi
+ le preparing delicious meals. For others cooking is pure stress. What is
+ the difference between orange and yellowcarrots? Did I forget something
+ ? Is the pan hot enoughq_? Or too hot? How long after thepasta do I star
+ t cooking the steak? Will it be healthy? Is it sustainable?So many quest
+ ionsappear if one starts to think about food. The answers are complicate
+ dand ambiguous. They require research and analyzing. Many have stopped t
+ hinkingabout food. They just believe what is written on thepackage.I can
+ 't cookis such an easy answer. And it is accepted in our society. Nobody
+ isashamed of it. This gives more and more control tomultinational corpo
+ rations. Through precookedfood and shiny commercials they calm our consc
+ ience and stimulate our laziness.The consequences are dramatic!The profi
+ t-focused approach of multinationalcorporations have led to things like:
+ • Patented genetically modified seeds. Lawyers suing farmers for copyr
+ ights.• Destruction of South-American jungle to make soya to feed Euro
+ pean cows so theymake more milk. Although a cow as never born to eat pro
+ teins.• Chickens that can't stand on their own feet due to the weight
+ of their breasts. Theywill never see soil\, worms or even sunlight.• O
+ ran-Utangs losing their homes for palm oil• Vegetables getting grown i
+ n the desert\, wasting huge amounts of drinking water.Conclusions:• We
+ must know more about our food• We have to cook more ourselves• So w
+ e will recover some control over what we eat
+SUMMARY:EveryCook - Cooking gets digital
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5275.en.html
+DTSTART;TZID=Europe/Berlin:20121228T183000
+UID:5275@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:RSA is the dominant public-key cryptosystem on the Internet.
+ This talk will explain the state of the art in techniques for the attack
+ er toh- figure out your secret RSA keys.d European co1
+SUMMARY:FactHacks - RSA factorization in the real world
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5198.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5198@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Neues Jahr\, neue Fnords :-)
+SUMMARY:Fnord-Jahresrückblick - Diesmal mit noch mehr Eurozonen-Spaltung
+ !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5226.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5226@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The calypso baseband and its companion chips are used on the
+ Motorola C123 among other and are now well known for being supported by
+ the Osmocom-BB open source GSM baseband implementation. A couple years a
+ go\, it was hacked a little further by using it as a raw bits capture de
+ vice allowing the interception of GSM traffic very cheaply.
+SUMMARY:Further hacks on the Calypso platform - or how to turn a phone in
+ to a BTSience a1
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5250.en.html
+DTSTART;TZID=Europe/Berlin:20121228T001500
+UID:5250@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Beim Googlequiz treten Teams gegeneinander an\, die *ohne Int
+ ernet* Aufgaben zu Googlesuchen und Suchergebnissen raten.
+SUMMARY:Googlequiz - Wie man (spaßorientiert) mehr als 5% seines Googlev
+ ermögens trainiertGooglesuchen!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5309.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5309@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Hacker Jeopardy - Zahlenraten für Geeks
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5024.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5024@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hackers are a high-risk population. This talk will provide ha
+ ckers with tools to reduce the risk to themselves and their communities
+ using harm reduction methodology.
+SUMMARY:Hackers As A High-Risk Population - Harm Reduction Methodology
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5400.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5400@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We discuss a set of 0-day kernel vulnerabilities in CNU (Cisc
+ o NativeUnix)\, the operating system that powers all Cisco TNP IP phones
+ . Wedemonstrate the reliable exploitation of all Cisco TNP phones viamul
+ tiple vulnerabilities found in the CNU kernel. We demonstratepractical c
+ overt surveillance using constant\, stealthy exfiltration ofmicrophone d
+ ata via a number of covert channels. We also demonstrate theworm-like pr
+ opagation of our CNU malware\, which can quickly compromiseall vulnerabl
+ e Cisco phones on the network. We discuss the feasibilityof our attacks
+ given physical access\,A- internal network access and remoteaccess acros
+ s the internet. Lastly\, we built on last year's presentationby discussi
+ ng the feasibility of exploiting Cisco phones fromcompromised HP printer
+ s and vice versa.
+SUMMARY:Hacking Cisco Phones - Just because you are paranoid doesn't mean
+ your phone isn't listening to everything you sayall Cisco TNP !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5179.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5179@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir sehen in der digitalen Technik großes Potential zur Demo
+ kratisierung und Befreiung der Menschen. Doch machen wir uns nichts vor.
+ Technik kann genausogut der Entmündigung von Menschen dienen. Je kompl
+ exer sie wird\, desto mehr sind wir von Vereinfachung abhängig und dest
+ o weniger Einfluss können wir selber auf die Technik nehmen.
+SUMMARY:Hacking Philosophy - Digitale Mündigkeit\, Technikpaternalismus
+ und warum wir Netzphilosophie brauchenn. Doch m!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5270.en.html
+DTSTART;TZID=Europe/Berlin:20121229T001500
+UID:5270@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This is fun stuff for the late night program\, not a serious
+ talk.Is it possible to read sb. others mind? In the late 1920ies/early 1
+ 930ies Berlin was excited by the famous mindreader and fortune teller Er
+ ik Jan Hanussen who performed his strange abilities on stage. His act wa
+ s so convincing that leading nazis beleaved in his powers and wanted him
+ for advice - until they decided to murder him.
+SUMMARY:Hanussen's mindreading - Experiment's of the historical psychic
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5152@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:At 28C3\, Klink and Waelde showed that a number of technologi
+ es (PHP\, ASP.NET\,Ruby\, Java\, Python\, etc.) were vulnerable to the d
+ ecade-old hash-flooding DoSattacks. The vulnerability was then often fix
+ ed by adopting stronger hashfunctions and "randomizing" them.
+SUMMARY:Hash-flooding DoS reloaded: attacks and defenses
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5287.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5287@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:NSU-Untersuchungsausschuss in Thüringen und NSU-Untersuchung
+ sausschuss des Bundestages\, über die Mordserie des NSU\, das System de
+ r V-Leute und die Rolle des Verfassungsschutzes.Zwölf Jahre lang konn
+ te der „Natio1nalsozialistische Untergrund“ (NSU) unerkannt in Deut
+ schland eine rassistische Mordserie an neun migrantischen Gewerbetreiben
+ den\, zwei Bombenanschläge mit mehr als zwanzig Verletzten\, den Mord a
+ n einer jungen Polizistin sowie ein Dutzend Banküberfälle verüben.
+SUMMARY:Hinter den Kulissen: Der NSU und das V-Leute-System
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5219.en.html
+DTSTART;TZID=Europe/Berlin:20121228T203000
+UID:5219@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:An approach to the problem of fuzzing proprietary protocols w
+ ill be shown\, focusing on network protocols and native software. In the
+ course of this talk I will combine several methods in order to force th
+ e client software to work as a “double agent” against the server.
+SUMMARY:"How I met your pointer" - Hijacking client software for fuzz and
+ profitSience a1
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5395.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5395@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Legal systems have a huge impact on what we do as hackers\, b
+ ut also on internet users in general. Laws can restrict our freedom to u
+ se the internet in ways we deem to be natural and it can impede the tool
+ s which we hackers use on a daily basis. Which is not to say that laws c
+ annot also protect our freedom and ensure that all bits are treated equa
+ lly. Most importantly\, these laws can be hacked and tweaked to fit our
+ needs - like most things in this world.1
+SUMMARY:HOWTO Hack the law
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5368.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5368@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Sechs Jahre nach seinem Inkrafttreten wurde das Informationsf
+ reiheitsgesetz (IFG) des Bundes für den Deutschen Bundestag evaluiert.
+ Auch aus einzelnen Bundesländern liegen zwischenzeitlich wissenschaftli
+ ch untermauerte Erkenntnisse zum Stand oder Nichtstand der Informationsf
+ reiheit in Deutschland vor.
+SUMMARY:IFG: Chance oder Bürgerbluff? - Informationsfreiheit in Deutschl
+ and. Ein Sachstand.) des Bundes!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5397.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5397@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:INFECT: "Bei der Forschung an unserem neuen Killervirus hat u
+ nsere Ethikkommission penibelst darauf geachtet\, dass niemand der Forsc
+ her sich ansteckt."
+SUMMARY:INDECT\, Verhaltenserkennung & Co - automatisierte staatliche Ver
+ dächtigung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5112.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5112@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk is aimed to give an insight into CPE WAN Management
+ Protocol (CWMP) and its GPLv2 implementations that were developed in th
+ e past year.
+SUMMARY:ISP's black box - provisioning behind the scenes
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5216.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5216@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the last years\, mobile security and specifically GSM has
+ been attacked in many different ways. It was demonstrated how to sniff a
+ nd crack traffic\, how to impersonate a subscriber by placing a fake cal
+ l and the general security characteristics of this mobile protocol stack
+ have been evaluated.In this presentation\, we will check out a part of
+ the protocol procedures that hasn't been looked at yet\, specifically Mo
+ bile Terminated services.
+SUMMARY:Let Me Answer That for You - adventures in mobile paging
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5316.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5316@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 1 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5383.en.html
+DTSTART;TZID=Europe/Berlin:20121229T124500
+UID:5383@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 2 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT2H15M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5384.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5384@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Lightning Talks 3 - 5 Minutes of Fame
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5305.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5305@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:We're winning! The future looks like network politics!Wait\,
+ what the hell are network politics and how do they work? Is that like
+ the Pirate Party\, or the IETF\, or Anonymous?
+SUMMARY:Long live the protocoletariat!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5124.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5124@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Security is moving deeper into hardware and so should securit
+ y research. This talks introduces microprobing\, an old technique for sn
+ ooping on data inside chips\, and details a low-cost probing setup.
+SUMMARY:Low-Cost Chip Microprobing
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5088.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5088@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:You might remember Tamagotchi virtual pets from the 1990's. T
+ hese toys are still around and just as demanding as ever! This talk cove
+ rs my attempts to hack the latest Tamagotchis. Starting with the IR inte
+ rface\, and moving down into the hardware\, this presentation will discu
+ ss techniques for reverse engineering a device with limited inputs\, com
+ puting power and debugging capabilities.
+SUMMARY:Many Tamagotchis Were Harmed in the Making of this Presentation
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5180.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5180@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Autonomer Drumroboter\, robotisches Glockenspiel oder klingen
+ de Installation: Musikinstrumente zu modifizieren und selbstzubauen biet
+ et musik- und technikaffinen Geeks die Möglichkeit\, vorgefertigten Kla
+ ng-Setups etwas eigenständiges entgegenzusetzen. Drumroboter und Klangi
+ nstallationen üben dabei sowohl physisch als auch optisch einen besonde
+ ren Reiz aus: die Quelle des Klangs wird entdeckt.
+SUMMARY:Marvin und der Blues - Wie Roboterinstrumente zum Musik machen be
+ nutzt werden können des Bundes!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5282.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5282@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Mit RFID-Lesegeräten Menschen tracken - keine Zukunftsvision
+ .
+SUMMARY:Meine Kleidung funkt - Tracking von Menschen durch in Kleidung in
+ tegrierte RFID-Chips des Bundes!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5289.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5289@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Meldegesetz und der erfolgreiche Protest dagegen.
+SUMMARY:Meldegesetz - Was aus dem 57-Sekunden-Gesetz wurde
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5285.en.html
+DTSTART;TZID=Europe/Berlin:20121229T214500
+UID:5285@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Unsichere Studierenden- und Mensakarten. Eine wissenschaftlic
+ he Auswertung.
+SUMMARY:Men who stare at bits - RFID-Studierendenkarten mit Fehlern
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5393.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5393@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Contactless smartcards have become widespread for application
+ s such as ticketing\, access control\, identification and payments. Side
+ -channel analysis (SCA) is a powerful type of passive implementation att
+ ack that enables to extract the secret keys of cryptographic devices. At
+ the example of NXP's Mifare DESfire MF3ICD40 smartcards we demonstrate
+ that SCA attacks can be applied to cryptographic RFID devices: By exploi
+ ting the electro-magnetic information leakage of the cards\, its cryptog
+ raphic keys are revealed.We introduce our open-source tools for analyzin
+ g contactless smartcardqs\, i.e.\, an ISO 14443 RFID reader (http://so
+ urceforge.net/projects/reader14443) and the card emulator Chameleon (htt
+ p://sourceforge.net/projects/chameleon14443). We then present the probab
+ ly worst realization of a commercial contactless payment system ever and
+ detail on various real-world attacks on this widespread (in Germany) sy
+ stem\, e.g.\, how to 'milk the digital cash cow' by modifying the credit
+ balance and convert zeros and ones into real money. The content of the
+ talk is joint work with Ingo von Maurich\, Daviad Oswald and Christof
+ Paar.
+SUMMARY:Milking the Digital Cash Cow - Extracting Secret Keys of Contactl
+ ess Smartcards
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5280.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5280@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Massive open online courses are the vogue of the season when
+ it comes to discussing the future of university-level education. But we
+ re onQly starting to see what education at this scope means and how
+ it can be supported best\, in terms of both didactics and technology. Th
+ is talk is an inside report by two instructors who have delved into the
+ experience of teaching large audiences online. We share the lessons that
+ we have learned: how to spark student interest\, how to put intuition b
+ efore formal theories\, how to streamline production and much more. And
+ we point out what needs to be done to truly democratize education from t
+ he viewpoint of both the studenAts and the instructors.
+SUMMARY:Millions of Lessons Learned on Electronic Napkins - On the way to
+ free(ing) educationng the futu!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5102.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5102@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In den letzten Jahren haben sich netzpolitische Kräfteverhä
+ ltnisse auf interessante Weise verschoben. Neue Allianzen bilden sich so
+ wohl geqgen\, als auch für das freie Internet – und dennoch bleibt
+ der Aktivismus weit hinter seinem Potential zurück.
+SUMMARY:Netzaktivsten! Ist das alles\, was wir drauf haben? - Eine subjek
+ tive Bestandsaufnahmeg the futu!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5134.en.html
+DTSTART;TZID=Europe/Berlin:20121227T214500
+UID:5134@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Human interface design for musical instruments presents uniqu
+ e challenges and vast new possibilities. The proliferation of low cost
+ rapid-prototyping tools has put the means of fabricating instruments wit
+ hin reach of the performing musician. In this talk\, I'll go through th
+ e design process for my main performance controller (The Mojo)\, my mult
+ iplayer instruments (aka Jamboxes) and my new RoboCaster guitar-controll
+ er.
+SUMMARY:New Human Interfaces for Music - DIY MIDI Controllers
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5404.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5404@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:NOC Review - NOC Review about the 29C3
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5385.en.html
+DTSTART;TZID=Europe/Berlin:20121227T113000
+UID:5385@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:On the topic of resistance.
+SUMMARY:Not my department
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5037.en.html
+DTSTART;TZID=Europe/Berlin:20121228T001500
+UID:5037@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Gut gereift und mit verbesserter Rezeptur.Aber immer noch:Zwe
+ i sich auf Couchen fläzende Teams gehirnwinden\, spitzfinden und assozi
+ ieren gegeneinander an\, um Bilderrätsel aus den Gefilden IT\, Netzgese
+ llschaft und Informatik zu entwirren.(Hashtag: #Nougatbytes)
+SUMMARY:Nougatbytes 10 - Gebilde(r)ter Hirnsalat – die rhekkcüЯ der B
+ ilderrätselds
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5203.en.html
+DTSTART;TZID=Europe/Berlin:20121228T143000
+UID:5203@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Polish government decided in favour of open-licensed e-textbo
+ oks. This is not to liking of big textbook publishers\, reaping in profi
+ ts hand over fist. While their black PR campaign focuses on technicaliti
+ es\, it seems obvious that their real beef is with the liberal licensing
+ .
+SUMMARY:OMG! OER! - How big business fights open education in Poland\, an
+ d how open education fights back! textbook publ!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5210.en.html
+DTSTART;TZID=Europe/Berlin:20121229T140000
+UID:5210@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Security Assertion Markup Language (SAML) is a widely ado
+ pted language for making security statements about subjects. It is a cri
+ tical component for the development of federated identity deployments an
+ d Single Sign-On scenarios. In order to protect integrity and authentici
+ ty of the exchanged SAML assertions\, the XML Signature standard is appl
+ ied. However\, the signature verification algorithm is much more complex
+ than in traditional signature formats like PKCS#7. The integrity protec
+ tion can thus be successfully circumvented by application of different X
+ ML Signature specific aawttacks\, under a weak adversarial model.
+SUMMARY:On Breaking SAML - Be Whoever You Want to Be
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H15M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5399.en.html
+DTSTART;TZID=Europe/Berlin:20121227T110000
+UID:5399@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:
+SUMMARY:Opening Event
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5308.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5308@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Was bedeutet das Zeitalter offener Designs für die Sicherhei
+ t von Schlössern? Zum Beispiel solchen\, die auf eine geringe Verbreitu
+ ng eineks Schlüssels setzen? Ein Beispiel sind die sogenannten Hochsi
+ cherheitsversionen von Polizeihandschellen. Der Talk zeigt was (und wie)
+ sich in diesem Bereich mit Lasercuttern und 3D Druckern erreichen läss
+ t - sowie welche komplexeren Angriffsziele noch warten. Als Ausweg aus d
+ er Problematik kopierbarer Schlüssel gelten digitale Schlösser\, aber
+ sie kranken anders an offenen Quellen: sie haben keine! Im Rahmen eines
+ Open Source Lock Projektes haben wir uns daher ein reflashbares Vorhäng
+ eschloss angesehen\, doch noch ehe wir den Programmieradapter angeschlos
+ sen hatten fanden wir eine SchwachstellAie der Hardware... Leider kein
+ Einzelfall!
+SUMMARY:Open Source Schlüssel und Schlösser - Offene Quellen zum Bösen
+ und Guten: von downloadbaren Handschellenschlüsseln zu sicheren elektr
+ onischen s SchlüsselsSchlössern
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5265.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5265@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:x86 processors contain a surprising amount of built-in memory
+ translation logic\, which is driven by various data tables with intrica
+ te entry formats\, and can produce various kinds of traps and other inte
+ resting computational effects. These features are mostly relics of earli
+ er\, more civilized times\, when Jedi Knights tried to protect the Old R
+ epublic OSes with segmentation\, supervisor bits\, and hardware task sup
+ port\, but were defeated by processor de-optimizations and performance c
+ oncerns and left unused by both Windows and UNIX systems – and explore
+ d only by hackers. For the rest of the world\, an x86 PC was a "von Neum
+ ann architecture" with most of its strangeness unused.
+SUMMARY:Page Fault Liberation Army or Gained in Translation - a history o
+ f creative x86 virtual memory usestextbook publ!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5323.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5323@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Vortrag handelt über Getreidezüchtung. Am Beispiel von
+ Weizen soll der langjährige Prozess beschrieben werden\, den es benöti
+ gt\, um eine neue Sorte auf den Markt zu bringen. Es sollen die biologi
+ schen Grundlagen sowie die benötigte Technik vorgestellt werden. Außer
+ dem wird auf die Problematik eingegangen\, die die Konzentration des Mar
+ ktes auf wenige große Konzerne mit sich bringt.
+SUMMARY:Pflanzenhacken richtig - Einblicke in die Weizenzüchtung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5095.en.html
+DTSTART;TZID=Europe/Berlin:20121227T183000
+UID:5095@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:To date\, remote vehicle communications have provided little
+ in the way of privacy. Much information and misinformation has been spre
+ ad on what the system is and can do\, especially within the information
+ security community. The recent field trial in the US of a connected vehi
+ cle infrastructure raises the level of concern amongst all who are aware
+ of existing privacy issues.
+SUMMARY:Privacy and the Car of the Future - Considerations for the Connec
+ ted Vehiclelds
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5101.en.html
+DTSTART;TZID=Europe/Berlin:20121229T160000
+UID:5101@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:ACTA war das beherrschende Thema des zweiten Halbjahres. Mit
+ ACTA sollte der Weg einer Privatisierung der Rechtsdurchsetzung weiter g
+ egangen werden. Was das konkret bedeutet\, können wir bereits im Auslan
+ d sehen: Netzsperren\, 3-Strikes-Systeme und eine Echtzeit-Überwachung
+ des Datenverkehrs zur Bekämpfung von Urheberrechtsverletzungen. Existie
+ rende Modelle in anderen europäischen Staaten zeigen\, dass diese Maßn
+ ahmen erhebliche grund- und datenschutzrechtliche Probleme aufwerfen.
+SUMMARY:Privatisierung der Rechtsdurchsetzung - Von ACTA\, IPRED und Freu
+ ndenVehiclelds
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5266.en.html
+DTSTART;TZID=Europe/Berlin:20121230T140000
+UID:5266@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Zensur im Internet betrifft immer mehr Nutzer. Wir kennen Too
+ ls wie Proxies\, VPNs oder Tor Bridges. Doch welche weiteren Werkzeuge u
+ nterstützen die Nutzer vor Ort? Wo sind die Stärken und Schwächen? De
+ r Vortrag stellt einige von diesen vor und zeigt die Stärken und Schwä
+ chen.
+SUMMARY:Proximax\, Telex\, Flashproxy oder Tor Bridges - Übersicht über
+ aktuelle Zensurumgehungssoftwarestextbook publ!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5374.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5374@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION: This talk will give an overview of the ongoing work by the W
+ 3C on a controversial general purpose Javascript cryptography API in con
+ text of the larger desire to create trusted and encrypted cloud services
+ with rich web applications. Today\, cryptography is difficult to use an
+ d the Web is an insecure environment at best\, but can this situation be
+ improved and cryptography be put in the hands of ordinary developers an
+ d users? The W3C specification\, currently under development\, will be d
+ escribed\, as well as its interaction with other parts of the emerging W
+ eb Security Model at th:e W3C and IETF such as Content Security Policy
+ \, HTTP Strict Transport Security\, and Certificate Transparency. A numb
+ er of use-cases\, ranging from decentralized identity systems to secure
+ cloud services for activists\, will be detailed. As the specification wi
+ ll be under active development until autumn 2013\, feedback from the hac
+ ker community is needed!
+SUMMARY:Re-igniting the Crypto Wars on the Web
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5138.en.html
+DTSTART;TZID=Europe/Berlin:20121228T131500
+UID:5138@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In 1791\, the political reformer Jeremy Bentham theorized the
+ Panopticon\, whose design promised to allow a single Inspector to surve
+ il (exercise "inspective force" over) large numbers of criminals or work
+ ers. In recent years\, the advent of a suitable technical apparatus –
+ CCTV\, ISP taps (network traffic interception)\, data banks\, and so on
+ – has extended the proposed 30m circumference of Bentham’s structure
+ to\, and beyond\, the A2physical boundaries of entire countries. While
+ total surveillance is often perceived as a feature of modernity\, its c
+ onceptual and epistemological framework is rooted in the Romantic period
+ \, moreover at a key juncture in the history of ideas concerning individ
+ ual subjectivity\, rights and freedoms. David Barnard-Wills refers to in
+ spective culture as a "nexus of surveillance\, identity and language" (2
+ 012). In this talk\, we examine this nexus in the historical period that
+ first\, and so powerfully\, imagined the fully10 surveilled world.
+SUMMARY:Romantic Hackers - Keats\, Wordsworth and Total Surveillance
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5402.en.html
+DTSTART;TZID=Europe/Berlin:20121229T183000
+UID:5402@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Privacy International\, Agentura.Ru\, the Russian secret serv
+ ices watchdog\, and Citizen Lab have joined forces to launch a new proje
+ ct entitled 'Russia’s Surveillance State'. The aims of the project are
+ to undertake research and investigation into surveillance practices in
+ Russia\, including the trade in and use of surveillance technologies\, a
+ nd to publicise research and investigative findings to improve national
+ and international awareness of surveillance and secrecy practices in Rus
+ sia. The project is made possible with support from the Canada Centre f
+ or Global Security Studies\, Munk School of Global Affairs\, at the Univ
+ ersity of Toronto.
+SUMMARY:Russia’s Surveillance State
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5140.en.html
+DTSTART;TZID=Europe/Berlin:20121228T214500
+UID:5140@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The triple meltdown of the Fukushima Dai-Ichi nuclear power p
+ lant in March last year and the release of radioactive material that has
+ ensued have left a good part of Northern Japan contaminated with unknow
+ n amount of radioactivity. An outstanding lack of transparency from both
+ the government and the power utility then resulted in a near total lack
+ of information concerning the levels of radiation in the\, yet unknown\
+ , contaminated areas. As a response\, concerned citizen have started to
+ take upon themselves this challenging task. However it quickly became cl
+ ear that handheld measu! rements wouldn't scale up to the full magnitud
+ e of the area to cover. New means of measuring radiation accurately\, qu
+ ickly and cheaply were needed.
+SUMMARY:Safecast: DIY and citizen-sensing of radiation - Empowering citiz
+ en in the wake of Fukushima triple-meltdown disasterve material!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5059.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5059@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Modern civilization unconditionally depends on information sy
+ stems. It is paradoxical but true that ICS/SCADA systems are the most in
+ secure systems in the world. From network to application\, SCADA is full
+ of configuration issues and vulnerabilities.
+SUMMARY:SCADA Strangelove - or: How I Learned to Start Worrying and Love
+ Nuclear Plants
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5177.en.html
+DTSTART;TZID=Europe/Berlin:20121229T113000
+UID:5177@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk will go into some of challenges\, solutions\, and s
+ tories from securing a campaign for the 2012 US presidential election.
+SUMMARY:Securing the Campaign - Security and the 2012 US Presidential Ele
+ ctionar Plants
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5225.en.html
+DTSTART;TZID=Europe/Berlin:20121229T203000
+UID:5225@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In this talk we will survey some 30 recent attacks on the Rus
+ sian GOST block cipher.Background: GOST cipher is the official encryptio
+ n standard of the Russian federation\, and also has special versions for
+ the most important Russian banks. Until 2012 there was no attack on GOS
+ T when it is used in encryption with random keys. I have developed more
+ than 30 different academic attacks on GOST the fastest has complexity of
+ 2^118 to recover some but not all 256-bit keys generated at random\, wh
+ ich will be presented for the first time at CCC conference. It happens o
+ nly once per decade tha
+t a government standard is broken while it is
+ still an official government standard (happened for DES and AES\, no oth
+ er cases known). All these are broken only in academic sense\, for GOST
+ most recent attacks are sliding into maybe arguably practical in 30 year
+ s from now instead of 200 years... Our earlier results were instrumental
+ at ISO for rejecting GOST as an international encryption standard last
+ year. Not more than 5+ block cihers have ever achieved this level of ISO
+ standardisation in 25 years and it NEVER happeqnded in history of ISO
+ that a cipher got broken during the standardization process. Two main p
+ apers with 70+30 pages respectively which are http://eprint.iacr.org/201
+ 1/626 and http://eprint.iacr.org/2012/138. Two other papers have been al
+ ready published in Cryptologia journal which specializes in serious mili
+ tary and government crypto. The talk will cover three main families of a
+ ttacks on GOST: high-level transformations\, low- level inversion/MITM/g
+ uess-then-software/algebraic attacks and advanced truncated differentiaa
+ l cryptanalysis of GOST.
+SUMMARY:Security Evaluation of Russian GOST Cipher - Survey of All Known
+ Attacks on Russian Government Encryption Standard the official !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5244.en.html
+DTSTART;TZID=Europe/Berlin:20121230T171500
+UID:5244@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Was hat sich im letzten Jahr im Bereich IT-Sicherheit getan?
+ Welche neuen Entwicklungen haben sich ergeben? Welche neuen Buzzwords un
+ d Treed1nds waren zu sehen?
+SUMMARY:Security Nightmares - Damit Sie auch morgen schlecht von Ihrem Co
+ mputer träumen.wicklungen habe!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5167.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5167@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In The Netherlands\, this year the community-driven mobile te
+ lco Limesco has started operations. We're providing voice\, SMS and data
+ services to dozens of hackers in our country.One of the founders of Lim
+ esco will give a lecture about mobile telephony in The Netherlands\, enc
+ ompassing topics like what companies are involved in the system\, how ta
+ riffs are constructed and the role of government regulations.
+SUMMARY:Setting mobile phones free - An overview of a mobile telephony ma
+ rket and how a community-driven operator is borning voice\, SMS!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5164.en.html
+DTSTART;TZID=Europe/Berlin:20121228T160000
+UID:5164@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Betrieb von WLAN-Funk-Netzen und auch von offenen oder fr
+ eien Netzen ist heute weit verbreitet und Teil der Diskussion um die "Cu
+ ltures of Sharing". Der Vortrag soll die Grundlagen der Haftung für off
+ ene Netze und die Entwicklung der Rechtsprechung vom Landgericht Hamburg
+ ("gestern") zum BGH-Urteil "Sommer unseres Lebens" und den Einfluss akt
+ ueller Rechtsprqechung des Europäischen Gerichtshofs\, des Bundesgeric
+ htshofs und der Instanzgerichte darstellen ("heute"). Ein Ausblick auf d
+ ie Folgen dieser neuen\, teilweise abweichenden Rechtsprechung und auf d
+ ie Gesetzesinitiativen der SPD und der Linken ("morgen") soll den Vortra
+ g abrunden.
+SUMMARY:Sharing Access – Risiken beim Betrieb offener (WLAN-)Netze - St
+ and gestern\, heute und morgen eitet und Teil !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5127.en.html
+DTSTART;TZID=Europe/Berlin:20121227T124500
+UID:5127@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Der Eid des Hippokrates\, der das Handeln von Ärzten ethisch
+ leiten soll\, ist zwischen 2.500 und 2.000 Jahre alt und tatsächlich w
+ ohl diea erste 'Datenschutz-Vorschrift' überhaupt. So heißt es: "Was
+ ich bei der Behandlung oder auch außerhalb meiner Praxis im Umgange mi
+ t Menschen sehe und höre\, das man nicht weiterreden darf\, werde ich v
+ erschweigen und als Geheimnis bewahren." [1]
+SUMMARY:Siechtum und Sterben der ärztlichen Schweigepflicht
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5121.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5121@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Green-IT kennen wir inzwischen zur Genüge. Computer können
+ aber nicht nur nicht "green" sein\, sondern auch unfair und unsozial\, v
+ on der 1Rohstoffgewinnung bis zur Verschrottung. Unfair spart nämlich
+ Geld. Der Gedanke\, faire Produkte anzubieten und zu kaufen\, ist inzwis
+ chen weit verbreitet\, allerdings eher bei Kaffee oder Kleidung. Ein Ang
+ ebot an fairer IT fehlt. Die Industrie hat sich noch nicht auf den Weg g
+ emacht\, faire Computer herzustellen. Wir Nutzer haben kaum die Wahl –
+ verändern können wir aber durchaus etwas. Der Vortrag erklärt\, was
+ und wie.
+SUMMARY:Sind faire Computer möglich?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5123.en.html
+DTSTART;TZID=Europe/Berlin:20121229T143000
+UID:5123@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The lecture would address topics related to reverse engineeri
+ ng for mobile platforms\, especially from the Android point of view. The
+ main aspects of the presentation is a new approach to reverse engineeri
+ ng side effects problem: some low footprint inspection techniques that g
+ rant analysts with the ability to access the program memory without alte
+ ring its behavior. One technique is presented in particular - Android se
+ rvice injection - and is demonstrated.
+SUMMARY:Small footprint inspection techniques for Android - Reverse engin
+ eering on Android platformshabe!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5239.en.html
+DTSTART;TZID=Europe/Berlin:20121228T183000
+UID:5239@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This talk will give an overview on the technology\, the laws
+ and the technical guidelines of the smartMeter roll-out in Germany.
+SUMMARY:SmartMeter - A technological overview of the German roll-out
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5336.en.html
+DTSTART;TZID=Europe/Berlin:20121230T113000
+UID:5336@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Forderungen nach einer gerechten Sprache (also einer Sprache
+ frei von Rassismus\, Sexismus und anderen menschenfeindlichen Ideologien
+ ) stoßen häufig auf Unverständnis und Ablehnung. Unverständnis\, wei
+ l statt der sozialen Wirklichkeit die Sprache kritisiert wird\, mit der
+ sie beschrieben wird. Ablehnung\, weil Sprachkritik häufig als Sprechve
+ rbot empfunden wird.
+SUMMARY:Sprache\, Ungleichheit und Unfreiheit
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5378.en.html
+DTSTART;TZID=Europe/Berlin:20121229T124500
+UID:5378@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Stabilitätsanker & Wachstumslokomotive geben als politische
+ Metaphern ungewollt Auskunft über das Ausmaß der europäischen Wirtsch
+ afts- und Finanzkrise. Wie kommt so ein Begriff in Verkehr? Wer gebrauch
+ t ihn? Zu welchem Zweck? Was fördert die Analyse der Metaphern zutage?
+SUMMARY:Stabilitätsanker & Wachstumslokomotive
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5230.en.html
+DTSTART;TZID=Europe/Berlin:20121228T230000
+UID:5230@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Stylometry uses linguistic information found in a document to
+ perform authorship recognition. In this talk\, we will present how styl
+ ometry can be used to deanonymize users in multilingual underground foru
+ ms. Our initial result shows that in spite of differences in languages a
+ nd text lengths\, regular stylometric methods perform well in identifyin
+ g users in this context. We will also present the improved version of An
+ onymouth\, a tool to anonymize written document\, with user studies.
+SUMMARY:Stylometry and Online Underground Markets
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5390.en.html
+DTSTART;TZID=Europe/Berlin:20121228T140000
+UID:5390@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Don't call us if your campaign does not work! And worse\, eve
+ ryone's been harassed or arrested.tet und Teil !
+SUMMARY:Tactical Tech - Bridging the Gap
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5228.en.html
+DTSTART;TZID=Europe/Berlin:20121230T124500
+UID:5228@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Role of Technology in Post-Revolution Tunisia & Egypt: In
+ ternet activists have embarked on many online projects to empower citize
+ ns with necessary information about their elected officials.
+SUMMARY:Technology in Post-Revolution Tunisia and Egypt
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5195.en.html
+DTSTART;TZID=Europe/Berlin:20121230T160000
+UID:5195@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The Executable and Linkable Format (ELF) is omnipresent\; rel
+ ated OS and library code is run whenever processes are set up and servic
+ ed (e.g.\, dynamically linked). The loader is the stage manager for ever
+ y executable. Hardly anyone appreciates the work that the ELF backstage
+ crew (including the linker and the loader) puts in to make an executable
+ run smoothly.
+SUMMARY:The Care and Feeding of Weird Machines Found in Executable Metada
+ ta
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5206.en.html
+DTSTART;TZID=Europe/Berlin:20121227T214500
+UID:5206@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the world of digital activism\, distributed denial of serv
+ ice attacks present relatively low barriers to popular participation\, h
+ ave a high potential for attracting large numbers of first-time and repe
+ at participants\, and can attract large amounts of media attention. But
+ though such actions popular\, are they ethical? In this talk I will be
+ presenting an ethical framework for the analysis of activist DDOS action
+ s. The framework is grounded in a historical analysis of various activis
+ t DDOS actions\, such as the IGC attacks in Spain in the late 90s\, Elec
+ tronic Disturbance Theater actions in the early 2000s\, and the Anonym
+ ous-led Operation Payback attacks in 2010. Each historical case study p
+ resents a unique confluence of technological\, political\, legal and ope
+ rational factors allowing for a full spectrum of ethical analysis.
+SUMMARY:The Ethics of Activist DDOS Actions - A Historical Analysis
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5256.en.html
+DTSTART;TZID=Europe/Berlin:20121229T230000
+UID:5256@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Have you ever been staring for nights at binary or hexadecima
+ l data flows extracted from an USB channel? Don't you remember yourself
+ searching for some patterns and similarities in this fuc***g mess of zer
+ os and ones grabbed from a binary configuration file? How long did it ta
+ ke you to find an 16 bits decimal size field last time you reversed an I
+ PC communication protocol?Did you know you were not alone and that among
+ them\, Rob Savoye (@ FOSDEM-08) and Drew Fisher (@ 28C3) have already r
+ eported the main difficulties of the RE operations. Both of them called
+ for the creation of a tool which would help experts in their work.
+SUMMARY:The future of protocol reversing and simulation applied on ZeroAc
+ cess botnet - Mapping your enemy Botnet with Netzobou remember !
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5274.en.html
+DTSTART;TZID=Europe/Berlin:20121227T171500
+UID:5274@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:The current European data protection directive is from 1995\,
+ which was when the internet had not hit Brussels' decision-makers yet.
+ Now\, 17 years later\, it is being completely re-writen. Will it meet th
+ e challenges of the age of big data? Will it have any effect on non-EU d
+ ata hoarders? How will it deal with user-generated consent? What is this
+ strange new "right to be forgotten"? And what about privacy by design?
+SUMMARY:The Grand EU Data Protection Reform - A latest battle report by
+ some key actors from Brusselsbe!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5306.en.html
+DTSTART;TZID=Europe/Berlin:20121228T171500
+UID:5306@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:At the very beginning\, Tor was just a socks proxy that prote
+ cted the origin and/or destination of your TCP flows. Now the broader To
+ r ecosystem includes a diverse set of projects -- browser extensions to
+ patch Firefox and Thunderbird's privacy issues\, Tor controller librarie
+ s to let you interface with the Tor client in your favorite language\, n
+ etwork scanners to measure relay performance and look for misbehaving ex
+ it relays\, LiveCDs\, support for the way Android applications expect To
+ r to behave\, full-network simulators and testing frameworks\, plugins t
+ o make Tor's traffic look like Skype or other protocols\, and metrics
+ and measurement tools to keep track of how well everything's working. Ma
+ ny of these tools aim to be useful beyond Tor: making them modular means
+ they're reusable for other anonymity and security projects as well. In
+ this talk\, Roger and Jake will walk you through all the tools that make
+ up the Tor software world\, and give you a better understanding of whic
+ h ones need love and how you can help.
+SUMMARY:The Tor software ecosystem
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5178.en.html
+DTSTART;TZID=Europe/Berlin:20121230T140000
+UID:5178@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Galaksija was to be in Yugoslavia what Commodore and Sinclair
+ were in the west. Whether it succeeded or not\, its deceptively simple
+ design can still teach us a lot of interesting tricks on how to make a u
+ sable computer and operating system with as few transistors and bits as
+ possible.
+SUMMARY:The ultimate Galaksija talk - Everything about a Yugoslavian micr
+ ocomputer halfway between a TRS-80 and a ZX 80\!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 4
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5044.en.html
+DTSTART;TZID=Europe/Berlin:20121227T230000
+UID:5044@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In this year’s talk\, I tie on my 28c3 talk and present tim
+ ing side channels from a defending viewpoint: How can one mitigate timin
+ g side A{channels? Aren’t random delays sufficient to prevent timing s
+ ide channels in practice? What is the minimum size of random delays to b
+ e effective? Are there other delay strategies besides random delays that
+ are more effective and efficient?
+SUMMARY:Time is NOT on your Side - Mitigating Timing Side Channels on the
+ Web
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5380.en.html
+DTSTART;TZID=Europe/Berlin:20121228T140000
+UID:5380@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Wir wissen seit ein paar Jahren\, dass der Staat technisch in
+ der Lage ist\, die Computer einiger seiner Bürger zu infiltrieren. Abe
+ r soll er das auch dürfen? Was hat sich in den letzten Monaten beim Sta
+ atstrojaner getan?
+SUMMARY:Trojaner-Blindflug - Spionage-Software von Staats wegen
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT0H30M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5091.en.html
+DTSTART;TZID=Europe/Berlin:20121228T124500
+UID:5091@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Hardware-basierte Festplattenvollverschlüsselungen in Form s
+ ogenannter SEDs (Self-Encrypting Drives) werden gemeinhin als sichere un
+ d performante Alternative zu Software-basierter Verschlüsselung wie Bit
+ Locker und TrueCrypt gesehen. Während der Performance-Gewinn und die Be
+ nutzerfreundlichkeit von SEDs\, bspw. Intel's SSD 320 bzw. SSD 520\, au
+ er Frage stehen\, ist der Sicherheits-Gewinn deutlich geringer als bish
+ er angenommen. Teilweise sind Systeme die auf SEDs basieren gar schwäch
+ er als vergleichbare Systeme die auf Software-Verschlüsselung basieren.
+SUMMARY:(Un)Sicherheit Hardware-basierter Festplattenverschlüsselung
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5396.en.html
+DTSTART;TZID=Europe/Berlin:20121228T160000
+UID:5396@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Weltbilder der Informatik sind in mancher Hinsicht denen in d
+ er Hacker- und Hackerinnen-Community nicht unähnlich.
+SUMMARY:Was ist\, was kann\, was soll Gender Studies Informatik?
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5160.en.html
+DTSTART;TZID=Europe/Berlin:20121228T113000
+UID:5160@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:In the Free City of Hamburg\, which is one of 16 German state
+ s\, a coalition of hackers\, activists and other players of civil societ
+ y have drafted the most revolutionary Freedom of information law in the
+ world. The law obliges the state to proactively publish all important pu
+ blic information (such as contracts\, studies\, construction permits) in
+ an OpenData format on the Internet. After the start of a referendum cam
+ paign\, the law was passed unanimously by the state parliament in June 2
+ 012 to avoid a public vote on it.
+SUMMARY:We are all lawmakers! - How to further transparency by law – th
+ e Hamburg example and beyond ac!
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5208.en.html
+DTSTART;TZID=Europe/Berlin:20121227T160000
+UID:5208@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Accessibility of digital content is a hugely misunderstood is
+ sue. Programmers and content developers tend to view it as a distraction
+ or a special interest concern. Accessibility advocates fail to describe
+ it in terms that would put it in the proper place for other technologis
+ ts\, in particular security practitioners.
+ We argue that if a format
+ or a document has systemic accessibility problems\, then accessibility i
+ s likely to be the least of its problems\; that accessibility only colla
+ pses first\, like a canAVary in a mine\, and security is next to follow.
+ We argue that many accessibility problems\, just like many security pro
+ blems\, stem from documents being hard to parse or containing executable
+ content\, and that the accessibility community is only the first to suf
+ fer\, due to not having the manpower to make extremely complicated forma
+ ts to almost work almost always. It's an arms race tougher than the secu
+ rity patching cycle\, made worse by there being no common model for what
+ accessibility properties should look like.
+SUMMARY:What accessibility has to do with security
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 6
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5283.en.html
+DTSTART;TZID=Europe/Berlin:20121227T203000
+UID:5283@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:After the political and legislative failure of the blocking a
+ nd filtering proposals in Germany (#Zensursula) and the EU (Child Protec
+ tion Directive) several players stepped up to implement the measures tha
+ t previously have been envisioned as compulsory but now on a "self-regul
+ atory" basis.
+SUMMARY:White IT\, Clean IT & CEO Coalition - How the government tries to
+ encourage privatized policy inforcement and thereby bypasses and circum
+ ventsDi democratic processes
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5327.en.html
+DTSTART;TZID=Europe/Berlin:20121229T171500
+UID:5327@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:This action-packed lecture presents the inner workings of the
+ author's from-scratch implementation of a USB Mass Storage disk in user
+ -land Python\, along with some embarrassing bugs in operating systems th
+ at support such disks. The lecture concludes with an introduction to Ac
+ tive Antiforensics\, in which a thumbdrive's own firmware can recognize
+ and defend itself against disk imaging and other forensic tools.
+SUMMARY:Writing a Thumbdrive from Scratch - Prototyping Active Disk Antif
+ orensics
+STATUS:CONFIRMED
+END:VEVENT
+BEGIN:VEVENT
+DURATION:PT1H00M
+LOCATION:Saal 1
+SEQUENCE:0
+URL:http://events.ccc.de/congress/2012/Fahrplan/events/5262.en.html
+DTSTART;TZID=Europe/Berlin:20121227T140000
+UID:5262@29C3@pentabarf.org
+DTSTAMP:20121226T143018
+CATEGORIES:Lecture
+DESCRIPTION:Seit anderthalb Jahren begleitet FragDenStaat.de die deutsche
+ Informationsfreiheit in der Praxis und dokumentiert die Korrespondenz z
+ wischen Anfragestellenden und Behörden. Welche Informationen gibt der S
+ taat preis\, und gegen welche Veröffentlichungen kämpft er sogar bis v
+ or Gericht? Die interessantesten Fälle werden genauer beleuchtet und ei
+ ne Bewertung zur Lage der staatlichen Information in Deutschland abgegeb
+ en.
+SUMMARY:Zur Lage der Information - 1.5 Jahre FragDenStaat.de
+STATUS:CONFIRMED
+END:VEVENT
+END:VCALENDAR
(DIR) diff --git a/ical.c b/ical.c
@@ -0,0 +1,327 @@
+/*
+ * Copy me if you can.
+ * by 20h
+ */
+
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <strings.h>
+#include <string.h>
+
+#include "ind.h"
+#include "ical.h"
+
+vitemprop_t *
+vitemprop_new(void)
+{
+ vitemprop_t *ret;
+
+ ret = mallocz(sizeof(vitemprop_t), 2);
+
+ return ret;
+}
+
+void
+vitemprop_free(vitemprop_t *prop)
+{
+ if (prop->name != NULL)
+ free(prop->name);
+ if (prop->params != NULL)
+ free(prop->params);
+ if (prop->value != NULL)
+ free(prop->value);
+
+ free(prop);
+}
+
+void
+vitemprop_print(vitemprop_t *prop)
+{
+ char *line, *lp, *cp;
+ int llen;
+
+ line = smprintf("%s%s%s:%s", prop->name,
+ (prop->params)? ";" : "",
+ (prop->params)? prop->params : "",
+ prop->value);
+ llen = strlen(line);
+ if (llen <= 73) {
+ printf("%s\r\n", line);
+ free(line);
+ return;
+ }
+
+ cp = memdupz(line, 73);
+ printf("%s\r\n", cp);
+ free(cp);
+ lp = line + 73;
+ llen -= 73;
+
+ for (; llen > 0;) {
+ cp = memdupz(lp, 72);
+ printf(" %s\r\n", cp);
+ free(cp);
+ lp += 72;
+ llen -= 72;
+ }
+ free(line);
+}
+
+vitem_t *
+vitem_new(void)
+{
+ vitem_t *ret;
+
+ ret = mallocz(sizeof(vitem_t), 2);
+
+ return ret;
+}
+
+void
+vitem_free(vitem_t *item)
+{
+ vitemprop_t *cur, *next;
+
+ for (cur = item->props; cur; cur = next) {
+ next = cur->next;
+
+ vitemprop_free(cur);
+ }
+
+ if (item->type != NULL)
+ free(item->type);
+
+ free(item);
+}
+
+void
+vitem_addprop(vitem_t *item, vitemprop_t *prop)
+{
+ if (item->props == NULL) {
+ item->props = prop;
+ item->lastp = prop;
+ } else {
+ item->lastp->next = prop;
+ prop->prev = item->lastp;
+ item->lastp = prop;
+ }
+ item->nprops++;
+}
+
+void
+vitem_print(vitem_t *item)
+{
+ vitemprop_t *elem;
+
+ printf("BEGIN:%s\n", item->type);
+ forlist(item->props, elem)
+ vitemprop_print(elem);
+ printf("END:%s\n", item->type);
+}
+
+vitems_t *
+vitems_new(void)
+{
+ vitems_t *ret;
+
+ ret = mallocz(sizeof(vitems_t), 2);
+
+ return ret;
+}
+
+void
+vitems_free(vitems_t *items)
+{
+ vitem_t *cur, *next;
+ vitemprop_t *pcur, *pnext;
+
+ for (cur = items->first; cur; cur = next) {
+ next = cur->next;
+ vitem_free(cur);
+ }
+
+ for (pcur = items->headers; pcur; pcur = pnext) {
+ pnext = pcur->next;
+ vitemprop_free(pcur);
+ }
+
+ free(items);
+}
+
+void
+vitems_addhdr(vitems_t *items, vitemprop_t *hdr)
+{
+ if (items->headers == NULL) {
+ items->headers = hdr;
+ items->lasth = hdr;
+ } else {
+ items->lasth->next = hdr;
+ hdr->prev = items->lasth;
+ items->lasth = hdr;
+ }
+ items->nheaders++;
+}
+
+void
+vitems_additem(vitems_t *items, vitem_t *item)
+{
+ if (items->first == NULL) {
+ items->first = item;
+ items->last = item;
+ } else {
+ items->last->next = item;
+ item->prev = items->last;
+ items->last = item;
+ }
+ items->nitems++;
+}
+
+void
+vitems_print(vitems_t *items)
+{
+ vitemprop_t *pelem;
+ vitem_t *ielem;
+
+ printf("BEGIN:VCALENDAR\r\n");
+ forlist(items->headers, pelem)
+ vitemprop_print(pelem);
+
+ forlist(items->first, ielem)
+ vitem_print(ielem);
+ printf("END:VCALENDAR\r\n");
+}
+
+enum {
+ STATE_INIT = 0x00,
+ STATE_VCALBEGIN,
+ STATE_VITEMBEGIN,
+ STATE_VCALEND
+};
+
+vitems_t *
+vitems_read(int fd)
+{
+ vitems_t *items;
+ vitem_t *item;
+ vitemprop_t *itemprop;
+ char *filebuf, *rp, *p, *sepp, *paramsp, buf[1024], *pbuf, *line,
+ *oline;
+ int len, state, blen;
+
+ filebuf = readtoeoffd(fd, &len);
+ if (filebuf == NULL)
+ return NULL;
+
+ state = STATE_INIT;
+ items = vitems_new();
+ item = NULL;
+
+ rp = filebuf;
+ p = filebuf;
+ line = NULL;
+ for (;;) {
+ if (line != NULL)
+ free(line);
+ line = NULL;
+ if (oline != NULL)
+ line = oline;
+
+ if (rp == NULL || state == STATE_VCALEND)
+ break;
+
+ for (; (rp = sgets(buf, sizeof(buf)-1, &p));) {
+ blen = strlen(buf);
+ if (buf[blen-1] == '\r') {
+ buf[blen-1] = '\0';
+ blen--;
+ }
+
+ pbuf = NULL;
+ switch (buf[0]) {
+ case '\t':
+ case ' ':
+ line = memdupcat(line, strlen(line),
+ &buf[1], blen-1);
+ pbuf = line;
+ break;
+ default:
+ break;
+ }
+
+ if (pbuf == NULL) {
+ if (line != NULL) {
+ oline = memdupz(buf, blen);
+ break;
+ } else {
+ line = memdupz(buf, blen);
+ }
+ }
+
+ }
+ if (line == NULL)
+ break;
+
+ sepp = strchr(line, ':');
+ if (sepp == NULL)
+ die("Syntax error.\n");
+
+ sepp[0] = '\0';
+ sepp++;
+
+ if (!strcasecmp(line, "BEGIN")) {
+ if (!strcasecmp(sepp, "VCALENDAR")) {
+ state = STATE_VCALBEGIN;
+ continue;
+ } else {
+ state = STATE_VITEMBEGIN;
+
+ item = vitem_new();
+ item->type = memdupz(sepp,
+ strlen(sepp));
+ continue;
+ }
+ } else if (!strcasecmp(line, "END")) {
+ if (!strcasecmp(sepp, "VCALENDAR")) {
+ state = STATE_VCALEND;
+ } else {
+ if (item == NULL)
+ die("item == NULL\n");
+ vitems_additem(items, item);
+ item = NULL;
+ }
+ continue;
+ }
+
+ paramsp = strchr(line, ';');
+ if (paramsp != NULL) {
+ paramsp[0] = '\0';
+ paramsp++;
+ }
+
+ itemprop = vitemprop_new();
+ itemprop->name = memdupz(line, strlen(line));
+ if (paramsp != NULL) {
+ itemprop->params = memdupz(paramsp,
+ strlen(paramsp));
+ }
+ itemprop->value = memdupz(sepp,
+ strlen(sepp));
+
+ if (state == STATE_VCALBEGIN) {
+ vitems_addhdr(items, itemprop);
+ } else if (state == STATE_VITEMBEGIN) {
+ vitem_addprop(item, itemprop);
+ }
+ }
+
+ free(filebuf);
+
+ if (items->nitems < 1) {
+ vitems_free(items);
+ return NULL;
+ }
+
+ return items;
+}
+
(DIR) diff --git a/ical.h b/ical.h
@@ -0,0 +1,63 @@
+/*
+ * Copy me if you can.
+ * by 20h
+ */
+
+#ifndef __ICAL_H__
+#define __ICAL_H__
+
+ttypedef struct vitemprop_t vitemprop_t;
+struct vitemprop_t {
+ vitemprop_t *next;
+ vitemprop_t *prev;
+
+ char *name;
+ char *params;
+ char *value;
+};
+
+ttypedef struct vitem_t vitem_t;
+struct vitem_t {
+ vitem_t *next;
+ vitem_t *prev;
+
+ char *type;
+
+ vitemprop_t *props;
+ vitemprop_t *lastp;
+ int nprops;
+};
+
+ttypedef struct vitems_t vitems_t;
+struct vitems_t {
+ vitem_t *first;
+ vitem_t *last;
+ int nitems;
+
+ vitemprop_t *headers;
+ vitemprop_t *lasth;
+ int nheaders;
+};
+
+vitemprop_t *vitemprop_new(void);
+void vitemprop_free(vitemprop_t *prop);
+void vitemprop_print(vitemprop_t *prop);
+
+vitem_t *vitem_new(void);
+void vitem_free(vitem_t *item);
+void vitem_addprop(vitem_t *item, vitemprop_t *prop);
+void vitem_print(vitem_t *item);
+
+vitems_t *vitems_new(void);
+void vitems_free(vitems_t *vitems);
+void vitems_addhdr(vitems_t *items, vitemprop_t *hdr);
+void vitems_additem(vitems_t *items, vitem_t *item);
+void vitems_print(vitems_t *items);
+
+vitems_t *vitems_read(int fd);
+
+#define forlist(first, elem) for (elem = first;\
+ elem; elem = elem->next)
+
+#endif
+
(DIR) diff --git a/icaltest.c b/icaltest.c
@@ -0,0 +1,38 @@
+/*
+ * Copy me if you can.
+ * by 20h
+ */
+
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+
+#include "ind.h"
+#include "ical.h"
+
+int
+main(int argc, char *argv[])
+{
+ int fd;
+ vitems_t *items;
+
+ if (argc < 2) {
+ fprintf(stderr, "usage: %s file.ics\n", argv[0]);
+ return 1;
+ }
+
+ fd = open(argv[1], O_RDONLY);
+ items = vitems_read(fd);
+ if (items == NULL)
+ die("vitems_read failed\n");
+
+ vitems_print(items);
+
+ vitems_free(items);
+
+ return 0;
+}
+
(DIR) diff --git a/ind.c b/ind.c
@@ -0,0 +1,182 @@
+/*
+ * Copy me if you can.
+ * by 20h
+ */
+
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <fcntl.h>
+#include <string.h>
+#include <strings.h>
+#include <errno.h>
+#include <ctype.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <time.h>
+
+#include "ind.h"
+
+void
+edie(char *fmt, ...)
+{
+ va_list fmtargs;
+
+ va_start(fmtargs, fmt);
+ vfprintf(stderr, fmt, fmtargs);
+ va_end(fmtargs);
+ fprintf(stderr, ": ");
+
+ perror(NULL);
+
+ exit(1);
+}
+
+void
+die(char *fmt, ...)
+{
+ va_list fmtargs;
+
+ va_start(fmtargs, fmt);
+ vfprintf(stderr, fmt, fmtargs);
+ va_end(fmtargs);
+
+ exit(1);
+}
+
+void *
+reallocz(void *p, int l, int z)
+{
+ p = realloc(p, l);
+ if(p == NULL)
+ edie("realloc");
+ if(z)
+ memset(p, 0, l);
+
+ return p;
+}
+
+void *
+mallocz(int l, int z)
+{
+ return reallocz(NULL, l, z);
+}
+
+void *
+memdup(void *p, int l)
+{
+ char *ret;
+
+ ret = reallocz(NULL, l, 2);
+ memmove(ret, p, l);
+
+ return (void *)ret;
+}
+
+void *
+memdupz(void *p, int l)
+{
+ char *ret;
+
+ ret = reallocz(NULL, l+1, 2);
+ memmove(ret, p, l);
+
+ return (void *)ret;
+}
+
+void *
+memdupcat(void *p, int lp, void *c, int lc)
+{
+ p = reallocz(p, lp+lc, 0);
+ memset(&((char *)p)[lp], 0, lc);
+
+ memmove(&((char *)p)[lp], c, lc);
+
+ return p;
+}
+
+char *
+vsmprintf(char *fmt, va_list fmtargs, int size)
+{
+ char *ret;
+
+ ret = reallocz(NULL, ++size, 2);
+ vsnprintf(ret, size, fmt, fmtargs);
+
+ return ret;
+}
+
+char *
+smprintf(char *fmt, ...)
+{
+ va_list fmtargs;
+ char *ret;
+ int len;
+
+ va_start(fmtargs, fmt);
+ len = vsnprintf(NULL, 0, fmt, fmtargs);
+ va_end(fmtargs);
+
+ va_start(fmtargs, fmt);
+ ret = vsmprintf(fmt, fmtargs, len);
+ va_end(fmtargs);
+
+ return ret;
+}
+
+char *
+readtoeoffd(int fd, int *len)
+{
+ char *ret, buf[4096];
+ int olen, nlen, rl;
+
+ for (nlen = 0, olen = 0, ret = NULL;
+ (rl = read(fd, buf, sizeof(buf))); olen = nlen) {
+ if (rl > 0) {
+ nlen += rl;
+ ret = reallocz(ret, nlen+1, 0);
+ ret[nlen] = '\0';
+
+ memmove(&ret[olen], buf, rl);
+ }
+ }
+
+ *len = nlen;
+ return ret;
+}
+
+char *
+sgets(char *s, int size, char **p)
+{
+ char *np;
+ int cl;
+
+ if (*p == NULL)
+ return NULL;
+
+ np = strchr(*p, '\n');
+ if (np == NULL) {
+ cl = strlen(*p);
+ if (cl < 1) {
+ *p = NULL;
+ return NULL;
+ }
+ } else {
+ cl = np - *p;
+ }
+
+ if (cl >= size)
+ cl = size - 1;
+ memmove(s, *p, cl);
+ s[cl] = '\0';
+
+ if (np == NULL) {
+ *p = NULL;
+ } else {
+ *p = np+1;
+ }
+
+ return s;
+}
+
(DIR) diff --git a/ind.h b/ind.h
@@ -0,0 +1,28 @@
+/*
+ * Copy me if you can.
+ * by 20h
+ */
+
+#ifndef __IND_H__
+#define __IND_H__
+
+#include <stdio.h>
+#include <stdarg.h>
+#include <time.h>
+
+void die(char *fmt, ...);
+void edie(char *fmt, ...);
+void *reallocz(void *p, int l, int z);
+void *mallocz(int l, int z);
+void *memdup(void *p, int l);
+void *memdupz(void *p, int l);
+void *memdupcat(void *p, int lp, void *c, int lc);
+char *vsmprintf(char *fmt, va_list fmtargs, int size);
+char *smprintf(char *fmt, ...);
+
+char *readtoeoffd(int fd, int *len);
+
+char *sgets(char *s, int size, char **p);
+
+#endif
+
(DIR) diff --git a/rfc/rfc2445.txt b/rfc/rfc2445.txt
@@ -0,0 +1,8291 @@
+
+
+
+
+
+
+Network Working Group F. Dawson
+Request for Comments: 2445 Lotus
+Category: Standards Track D. Stenerson
+ Microsoft
+ November 1998
+
+
+ Internet Calendaring and Scheduling Core Object Specification
+ (iCalendar)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ There is a clear need to provide and deploy interoperable calendaring
+ and scheduling services for the Internet. Current group scheduling
+ and Personal Information Management (PIM) products are being extended
+ for use across the Internet, today, in proprietary ways. This memo
+ has been defined to provide the definition of a common format for
+ openly exchanging calendaring and scheduling information across the
+ Internet.
+
+ This memo is formatted as a registration for a MIME media type per
+ [RFC 2048]. However, the format in this memo is equally applicable
+ for use outside of a MIME message content type.
+
+ The proposed media type value is 'text/calendar'. This string would
+ label a media type containing calendaring and scheduling information
+ encoded as text characters formatted in a manner outlined below.
+
+ This MIME media type provides a standard content type for capturing
+ calendar event, to-do and journal entry information. It also can be
+ used to convey free/busy time information. The content type is
+ suitable as a MIME message entity that can be transferred over MIME
+ based email systems, using HTTP or some other Internet transport. In
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 1]
+
+RFC 2445 iCalendar November 1998
+
+
+ addition, the content type is useful as an object for interactions
+ between desktop applications using the operating system clipboard,
+ drag/drop or file systems capabilities.
+
+ This memo is based on the earlier work of the vCalendar specification
+ for the exchange of personal calendaring and scheduling information.
+ In order to avoid confusion with this referenced work, this memo is
+ to be known as the iCalendar specification.
+
+ This memo defines the format for specifying iCalendar object methods.
+ An iCalendar object method is a set of usage constraints for the
+ iCalendar object. For example, these methods might define scheduling
+ messages that request an event be scheduled, reply to an event
+ request, send a cancellation notice for an event, modify or replace
+ the definition of an event, provide a counter proposal for an
+ original event request, delegate an event request to another
+ individual, request free or busy time, reply to a free or busy time
+ request, or provide similar scheduling messages for a to-do or
+ journal entry calendar component. The iCalendar Transport-indendent
+ Interoperability Protocol (iTIP) defined in [ITIP] is one such
+ scheduling protocol.
+
+Table of Contents
+
+ 1 Introduction.....................................................5
+ 2 Basic Grammar and Conventions....................................6
+ 2.1 Formatting Conventions .......................................7
+ 2.2 Related Memos ................................................8
+ 2.3 International Considerations .................................8
+ 3 Registration Information.........................................8
+ 3.1 Content Type .................................................8
+ 3.2 Parameters ...................................................9
+ 3.3 Content Header Fields .......................................10
+ 3.4 Encoding Considerations .....................................10
+ 3.5 Security Considerations .....................................10
+ 3.6 Interoperability Considerations .............................11
+ 3.7 Applications Which Use This Media Type ......................11
+ 3.8 Additional Information ......................................11
+ 3.9 Magic Numbers ...............................................11
+ 3.10 File Extensions ............................................11
+ 3.11 Contact for Further Information: ...........................12
+ 3.12 Intended Usage .............................................12
+ 3.13 Authors/Change Controllers .................................12
+ 4 iCalendar Object Specification..................................13
+ 4.1 Content Lines ...............................................13
+ 4.1.1 List and Field Separators ................................16
+ 4.1.2 Multiple Values ..........................................16
+ 4.1.3 Binary Content ...........................................16
+
+
+
+Dawson & Stenerson Standards Track [Page 2]
+
+RFC 2445 iCalendar November 1998
+
+
+ 4.1.4 Character Set ............................................17
+ 4.2 Property Parameters .........................................17
+ 4.2.1 Alternate Text Representation ............................18
+ 4.2.2 Common Name ..............................................19
+ 4.2.3 Calendar User Type .......................................20
+ 4.2.4 Delegators ...............................................20
+ 4.2.5 Delegatees ...............................................21
+ 4.2.6 Directory Entry Reference ................................21
+ 4.2.7 Inline Encoding ..........................................22
+ 4.2.8 Format Type ..............................................23
+ 4.2.9 Free/Busy Time Type ......................................23
+ 4.2.10 Language ................................................24
+ 4.2.11 Group or List Membership ................................25
+ 4.2.12 Participation Status ....................................25
+ 4.2.13 Recurrence Identifier Range .............................27
+ 4.2.14 Alarm Trigger Relationship ..............................27
+ 4.2.15 Relationship Type .......................................28
+ 4.2.16 Participation Role ......................................29
+ 4.2.17 RSVP Expectation ........................................29
+ 4.2.18 Sent By .................................................30
+ 4.2.19 Time Zone Identifier ....................................30
+ 4.2.20 Value Data Types ........................................32
+ 4.3 Property Value Data Types ...................................32
+ 4.3.1 Binary ...................................................33
+ 4.3.2 Boolean ..................................................33
+ 4.3.3 Calendar User Address ....................................34
+ 4.3.4 Date .....................................................34
+ 4.3.5 Date-Time ................................................35
+ 4.3.6 Duration .................................................37
+ 4.3.7 Float ....................................................38
+ 4.3.8 Integer ..................................................38
+ 4.3.9 Period of Time ...........................................39
+ 4.3.10 Recurrence Rule .........................................40
+ 4.3.11 Text ....................................................45
+ 4.3.12 Time ....................................................47
+ 4.3.13 URI .....................................................49
+ 4.3.14 UTC Offset ..............................................49
+ 4.4 iCalendar Object ............................................50
+ 4.5 Property ....................................................51
+ 4.6 Calendar Components .........................................51
+ 4.6.1 Event Component ..........................................52
+ 4.6.2 To-do Component ..........................................55
+ 4.6.3 Journal Component ........................................56
+ 4.6.4 Free/Busy Component ......................................58
+ 4.6.5 Time Zone Component ......................................60
+ 4.6.6 Alarm Component ..........................................67
+ 4.7 Calendar Properties .........................................73
+ 4.7.1 Calendar Scale ...........................................73
+
+
+
+Dawson & Stenerson Standards Track [Page 3]
+
+RFC 2445 iCalendar November 1998
+
+
+ 4.7.2 Method ...................................................74
+ 4.7.3 Product Identifier .......................................75
+ 4.7.4 Version ..................................................76
+ 4.8 Component Properties ........................................77
+ 4.8.1 Descriptive Component Properties .........................77
+ 4.8.1.1 Attachment ...........................................77
+ 4.8.1.2 Categories ...........................................78
+ 4.8.1.3 Classification .......................................79
+ 4.8.1.4 Comment ..............................................80
+ 4.8.1.5 Description ..........................................81
+ 4.8.1.6 Geographic Position ..................................82
+ 4.8.1.7 Location .............................................84
+ 4.8.1.8 Percent Complete .....................................85
+ 4.8.1.9 Priority .............................................85
+ 4.8.1.10 Resources ...........................................87
+ 4.8.1.11 Status ..............................................88
+ 4.8.1.12 Summary .............................................89
+ 4.8.2 Date and Time Component Properties .......................90
+ 4.8.2.1 Date/Time Completed ..................................90
+ 4.8.2.2 Date/Time End ........................................91
+ 4.8.2.3 Date/Time Due ........................................92
+ 4.8.2.4 Date/Time Start ......................................93
+ 4.8.2.5 Duration .............................................94
+ 4.8.2.6 Free/Busy Time .......................................95
+ 4.8.2.7 Time Transparency ....................................96
+ 4.8.3 Time Zone Component Properties ...........................97
+ 4.8.3.1 Time Zone Identifier .................................97
+ 4.8.3.2 Time Zone Name .......................................98
+ 4.8.3.3 Time Zone Offset From ................................99
+ 4.8.3.4 Time Zone Offset To .................................100
+ 4.8.3.5 Time Zone URL .......................................101
+ 4.8.4 Relationship Component Properties .......................102
+ 4.8.4.1 Attendee ............................................102
+ 4.8.4.2 Contact .............................................104
+ 4.8.4.3 Organizer ...........................................106
+ 4.8.4.4 Recurrence ID .......................................107
+ 4.8.4.5 Related To ..........................................109
+ 4.8.4.6 Uniform Resource Locator ............................110
+ 4.8.4.7 Unique Identifier ...................................111
+ 4.8.5 Recurrence Component Properties .........................112
+ 4.8.5.1 Exception Date/Times ................................112
+ 4.8.5.2 Exception Rule ......................................114
+ 4.8.5.3 Recurrence Date/Times ...............................115
+ 4.8.5.4 Recurrence Rule .....................................117
+ 4.8.6 Alarm Component Properties ..............................126
+ 4.8.6.1 Action ..............................................126
+ 4.8.6.2 Repeat Count ........................................126
+ 4.8.6.3 Trigger .............................................127
+
+
+
+Dawson & Stenerson Standards Track [Page 4]
+
+RFC 2445 iCalendar November 1998
+
+
+ 4.8.7 Change Management Component Properties ..................129
+ 4.8.7.1 Date/Time Created ...................................129
+ 4.8.7.2 Date/Time Stamp .....................................130
+ 4.8.7.3 Last Modified .......................................131
+ 4.8.7.4 Sequence Number .....................................131
+ 4.8.8 Miscellaneous Component Properties ......................133
+ 4.8.8.1 Non-standard Properties .............................133
+ 4.8.8.2 Request Status ......................................134
+ 5 iCalendar Object Examples......................................136
+ 6 Recommended Practices..........................................140
+ 7 Registration of Content Type Elements..........................141
+ 7.1 Registration of New and Modified iCalendar Object Methods ..141
+ 7.2 Registration of New Properties .............................141
+ 7.2.1 Define the property .....................................142
+ 7.2.2 Post the Property definition ............................143
+ 7.2.3 Allow a comment period ..................................143
+ 7.2.4 Submit the property for approval ........................143
+ 7.3 Property Change Control ....................................143
+ 8 References.....................................................144
+ 9 Acknowledgments................................................145
+ 10 Authors' and Chairs' Addresses................................146
+ 11 Full Copyright Statement......................................148
+
+1 Introduction
+
+ The use of calendaring and scheduling has grown considerably in the
+ last decade. Enterprise and inter-enterprise business has become
+ dependent on rapid scheduling of events and actions using this
+ information technology. However, the longer term growth of
+ calendaring and scheduling, is currently limited by the lack of
+ Internet standards for the message content types that are central to
+ these knowledgeware applications. This memo is intended to progress
+ the level of interoperability possible between dissimilar calendaring
+ and scheduling applications. This memo defines a MIME content type
+ for exchanging electronic calendaring and scheduling information. The
+ Internet Calendaring and Scheduling Core Object Specification, or
+ iCalendar, allows for the capture and exchange of information
+ normally stored within a calendaring and scheduling application; such
+ as a Personal Information Manager (PIM) or a Group Scheduling
+ product.
+
+ The iCalendar format is suitable as an exchange format between
+ applications or systems. The format is defined in terms of a MIME
+ content type. This will enable the object to be exchanged using
+ several transports, including but not limited to SMTP, HTTP, a file
+ system, desktop interactive protocols such as the use of a memory-
+ based clipboard or drag/drop interactions, point-to-point
+ asynchronous communication, wired-network transport, or some form of
+
+
+
+Dawson & Stenerson Standards Track [Page 5]
+
+RFC 2445 iCalendar November 1998
+
+
+ unwired transport such as infrared might also be used.
+
+ The memo also provides for the definition of iCalendar object methods
+ that will map this content type to a set of messages for supporting
+ calendaring and scheduling operations such as requesting, replying
+ to, modifying, and canceling meetings or appointments, to-dos and
+ journal entries. The iCalendar object methods can be used to define
+ other calendaring and scheduling operations such a requesting for and
+ replying with free/busy time data. Such a scheduling protocol is
+ defined in the iCalendar Transport-independent Interoperability
+ Protocol (iTIP) defined in [ITIP].
+
+ The memo also includes a formal grammar for the content type based on
+ the Internet ABNF defined in [RFC 2234]. This ABNF is required for
+ the implementation of parsers and to serve as the definitive
+ reference when ambiguities or questions arise in interpreting the
+ descriptive prose definition of the memo.
+
+2 Basic Grammar and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
+ "OPTIONAL" in this document are to be interoperated as described in
+ [RFC 2119].
+
+ This memo makes use of both a descriptive prose and a more formal
+ notation for defining the calendaring and scheduling format.
+
+ The notation used in this memo is the ABNF notation of [RFC 2234].
+ Readers intending on implementing this format defined in this memo
+ should be familiar with this notation in order to properly interpret
+ the specifications of this memo.
+
+ All numeric and hexadecimal values used in this memo are given in
+ decimal notation.
+
+ All names of properties, property parameters, enumerated property
+ values and property parameter values are case-insensitive. However,
+ all other property values are case-sensitive, unless otherwise
+ stated.
+
+ Note: All indented editorial notes, such as this one, are
+ intended to provide the reader with additional information. The
+ information is not essential to the building of an
+ implementation conformant with this memo. The information is
+ provided to highlight a particular feature or characteristic of
+ the memo.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 6]
+
+RFC 2445 iCalendar November 1998
+
+
+ The format for the iCalendar object is based on the syntax of the
+ [RFC 2425] content type. While the iCalendar object is not a profile
+ of the [RFC 2425] content type, it does reuse a number of the
+ elements from the [RFC 2425] specification.
+
+2.1 Formatting Conventions
+
+ The mechanisms defined in this memo are defined in prose. Many of the
+ terms used to describe these have common usage that is different than
+ the standards usage of this memo. In order to reference within this
+ memo elements of the calendaring and scheduling model, core object
+ (this memo) or interoperability protocol [ITIP] some formatting
+ conventions have been used. Calendaring and scheduling roles are
+ referred to in quoted-strings of text with the first character of
+ each word in upper case. For example, "Organizer" refers to a role of
+ a "Calendar User" within the scheduling protocol defined by [ITIP].
+ Calendar components defined by this memo are referred to with
+ capitalized, quoted-strings of text. All calendar components start
+ with the letter "V". For example, "VEVENT" refers to the event
+ calendar component, "VTODO" refers to the to-do calendar component
+ and "VJOURNAL" refers to the daily journal calendar component.
+ Scheduling methods defined by [ITIP] are referred to with
+ capitalized, quoted-strings of text. For example, "REQUEST" refers to
+ the method for requesting a scheduling calendar component be created
+ or modified, "REPLY" refers to the method a recipient of a request
+ uses to update their status with the "Organizer" of the calendar
+ component.
+
+ The properties defined by this memo are referred to with capitalized,
+ quoted-strings of text, followed by the word "property". For example,
+ "ATTENDEE" property refers to the iCalendar property used to convey
+ the calendar address of a calendar user. Property parameters defined
+ by this memo are referred to with lowercase, quoted-strings of text,
+ followed by the word "parameter". For example, "value" parameter
+ refers to the iCalendar property parameter used to override the
+ default data type for a property value. Enumerated values defined by
+ this memo are referred to with capitalized text, either alone or
+ followed by the word "value". For example, the "MINUTELY" value can
+ be used with the "FREQ" component of the "RECUR" data type to specify
+ repeating components based on an interval of one minute or more.
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 7]
+
+RFC 2445 iCalendar November 1998
+
+
+2.2 Related Memos
+
+ Implementers will need to be familiar with several other memos that,
+ along with this memo, form a framework for Internet calendaring and
+ scheduling standards. This memo, [ICAL], specifies a core
+ specification of objects, data types, properties and property
+ parameters.
+
+ [ITIP] - specifies an interoperability protocol for scheduling
+ between different implementations;
+
+ [IMIP] specifies an Internet email binding for [ITIP].
+
+ This memo does not attempt to repeat the specification of concepts or
+ definitions from these other memos. Where possible, references are
+ made to the memo that provides for the specification of these
+ concepts or definitions.
+
+2.3 International Considerations
+
+ In the rest of this document, descriptions of characters are of the
+ form "character name (codepoint)", where "codepoint" is from the US-
+ ASCII character set. The "character name" is the authoritative
+ description; (codepoint) is a reference to that character in US-ASCII
+ or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
+ 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
+ is used, appropriate code-point from that character set MUST be
+ chosen instead. Use of non-US-ASCII-compatible character sets is NOT
+ recommended.
+
+3 Registration Information
+
+ The Calendaring and Scheduling Core Object Specification is intended
+ for use as a MIME content type. However, the implementation of the
+ memo is in no way limited solely as a MIME content type.
+
+3.1 Content Type
+
+ The following text is intended to register this memo as the MIME
+ content type "text/calendar".
+
+ To: ietf-types@uninett.no
+
+ Subject: Registration of MIME content type text/calendar.
+
+ MIME media type name: text
+
+ MIME subtype name: calendar
+
+
+
+Dawson & Stenerson Standards Track [Page 8]
+
+RFC 2445 iCalendar November 1998
+
+
+3.2 Parameters
+
+ Required parameters: none
+
+ Optional parameters: charset, method, component and optinfo
+
+ The "charset" parameter is defined in [RFC 2046] for other body
+ parts. It is used to identify the default character set used within
+ the body part.
+
+ The "method" parameter is used to convey the iCalendar object method
+ or transaction semantics for the calendaring and scheduling
+ information. It also is an identifier for the restricted set of
+ properties and values that the iCalendar object consists of. The
+ parameter is to be used as a guide for applications interpreting the
+ information contained within the body part. It SHOULD NOT be used to
+ exclude or require particular pieces of information unless the
+ identified method definition specifically calls for this behavior.
+ Unless specifically forbidden by a particular method definition, a
+ text/calendar content type can contain any set of properties
+ permitted by the Calendaring and Scheduling Core Object
+ Specification. The "method" parameter MUST be the same value as that
+ specified in the "METHOD" component property in the iCalendar object.
+ If one is present, the other MUST also be present.
+
+ The value for the "method" parameter is defined as follows:
+
+ method = 1*(ALPHA / DIGIT / "-")
+ ; IANA registered iCalendar object method
+
+ The "component" parameter conveys the type of iCalendar calendar
+ component within the body part. If the iCalendar object contains more
+ than one calendar component type, then multiple component parameters
+ MUST be specified.
+
+ The value for the "component" parameter is defined as follows:
+
+ component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
+ / "VTIMEZONE" / x-name / iana-token)
+
+ The "optinfo" parameter conveys optional information about the
+ iCalendar object within the body part. This parameter can only
+ specify semantics already specified by the iCalendar object and that
+ can be otherwise determined by parsing the body part. In addition,
+ the optional information specified by this parameter MUST be
+ consistent with that information specified by the iCalendar object.
+ For example, it can be used to convey the "Attendee" response status
+ to a meeting request. The parameter value consists of a string value.
+
+
+
+Dawson & Stenerson Standards Track [Page 9]
+
+RFC 2445 iCalendar November 1998
+
+
+ The parameter can be specified multiple times.
+
+ This parameter MAY only specify semantics already specified by the
+ iCalendar object and that can be otherwise determined by parsing the
+ body part.
+
+ The value for the "optinfo" parameter is defined as follows:
+
+ optinfo = infovalue / qinfovalue
+
+ infovalue = iana-token / x-name
+
+ qinfovalue = DQUOTE (infovalue) DQUOTE
+
+3.3 Content Header Fields
+
+ Optional content header fields: Any header fields defined by [RFC
+ 2045].
+
+3.4 Encoding Considerations
+
+ This MIME content type can contain 8bit characters, so the use of
+ quoted-printable or BASE64 MIME content-transfer-encodings might be
+ necessary when iCalendar objects are transferred across protocols
+ restricted to the 7bit repertoire. Note that a text valued property
+ in the content entity can also have content encoding of special
+ characters using a BACKSLASH character (US-ASCII decimal 92)
+ escapement technique. This means that content values can end up
+ encoded twice.
+
+3.5 Security Considerations
+
+ SPOOFING - - In this memo, the "Organizer" is the only person
+ authorized to make changes to an existing "VEVENT", "VTODO",
+ "VJOURNAL" calendar component and redistribute the updates to the
+ "Attendees". An iCalendar object that maliciously changes or cancels
+ an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
+ component might be constructed by someone other than the "Organizer"
+ and sent to the "Attendees". In addition in this memo, other than the
+ "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
+ calendar component is the only other person authorized to update any
+ parameter associated with their "ATTENDEE" property and send it to
+ the "Organizer". An iCalendar object that maliciously changes the
+ "ATTENDEE" parameters can be constructed by someone other than the
+ real "Attendee" and sent to the "Organizer".
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 10]
+
+RFC 2445 iCalendar November 1998
+
+
+ PROCEDURAL ALARMS - - An iCalendar object can be created that
+ contains a "VEVENT" and "VTODO" calendar component with "VALARM"
+ calendar components. The "VALARM" calendar component can be of type
+ PROCEDURE and can have an attachment containing some sort of
+ executable program. Implementations that incorporate these types of
+ alarms are subject to any virus or malicious attack that might occur
+ as a result of executing the attachment.
+
+ ATTACHMENTS - - An iCalendar object can include references to Uniform
+ Resource Locators that can be programmed resources.
+
+ Implementers and users of this memo should be aware of the network
+ security implications of accepting and parsing such information. In
+ addition, the security considerations observed by implementations of
+ electronic mail systems should be followed for this memo.
+
+3.6 Interoperability Considerations
+
+ This MIME content type is intended to define a common format for
+ conveying calendaring and scheduling information between different
+ systems. It is heavily based on the earlier [VCAL] industry
+ specification.
+
+3.7 Applications Which Use This Media Type
+
+ This content-type is designed for widespread use by Internet
+ calendaring and scheduling applications. In addition, applications in
+ the workflow and document management area might find this content-
+ type applicable. The [ITIP] and [IMIP] Internet protocols directly
+ use this content-type also. Future work on an Internet calendar
+ access protocol will utilize this content-type too.
+
+3.8 Additional Information
+
+ This memo defines this content-type.
+
+3.9 Magic Numbers
+
+ None.
+
+3.10 File Extensions
+
+ The file extension of "ics" is to be used to designate a file
+ containing (an arbitrary set of) calendaring and scheduling
+ information consistent with this MIME content type.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 11]
+
+RFC 2445 iCalendar November 1998
+
+
+ The file extension of "ifb" is to be used to designate a file
+ containing free or busy time information consistent with this MIME
+ content type.
+
+ Macintosh file type codes: The file type code of "iCal" is to be used
+ in Apple MacIntosh operating system environments to designate a file
+ containing calendaring and scheduling information consistent with
+ this MIME media type.
+
+ The file type code of "iFBf" is to be used in Apple MacIntosh
+ operating system environments to designate a file containing free or
+ busy time information consistent with this MIME media type.
+
+3.11 Contact for Further Information:
+
+ Frank Dawson
+ 6544 Battleford Drive
+ Raleigh, NC 27613-3502
+ 919-676-9515 (Telephone)
+ 919-676-9564 (Data/Facsimile)
+ Frank_Dawson@Lotus.com (Internet Mail)
+
+ Derik Stenerson
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ 425-936-5522 (Telephone)
+ 425-936-7329 (Facsimile)
+ deriks@microsoft.com (Internet Mail)
+
+3.12 Intended Usage
+
+ COMMON
+
+3.13 Authors/Change Controllers
+
+ Frank Dawson
+ 6544 Battleford Drive
+ Raleigh, NC 27613-3502
+ 919-676-9515 (Telephone)
+ 919-676-9564 (Data/Facsimile)
+ Frank_Dawson@Lotus.com (Internet Mail)
+
+ Derik Stenerson
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ 425-936-5522 (Telephone)
+ 425-936-7329 (Facsimile)
+ deriks@microsoft.com (Internet Mail)
+
+
+
+Dawson & Stenerson Standards Track [Page 12]
+
+RFC 2445 iCalendar November 1998
+
+
+4 iCalendar Object Specification
+
+ The following sections define the details of a Calendaring and
+ Scheduling Core Object Specification. This information is intended to
+ be an integral part of the MIME content type registration. In
+ addition, this information can be used independent of such content
+ registration. In particular, this memo has direct applicability for
+ use as a calendaring and scheduling exchange format in file-, memory-
+ or network-based transport mechanisms.
+
+4.1 Content Lines
+
+ The iCalendar object is organized into individual lines of text,
+ called content lines. Content lines are delimited by a line break,
+ which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
+ decimal 10).
+
+ Lines of text SHOULD NOT be longer than 75 octets, excluding the line
+ break. Long content lines SHOULD be split into a multiple line
+ representations using a line "folding" technique. That is, a long
+ line can be split between any two characters by inserting a CRLF
+ immediately followed by a single linear white space character (i.e.,
+ SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
+ of CRLF followed immediately by a single linear white space character
+ is ignored (i.e., removed) when processing the content type.
+
+ For example the line:
+
+ DESCRIPTION:This is a long description that exists on a long line.
+
+ Can be represented as:
+
+ DESCRIPTION:This is a lo
+ ng description
+ that exists on a long line.
+
+ The process of moving from this folded multiple line representation
+ to its single line representation is called "unfolding". Unfolding is
+ accomplished by removing the CRLF character and the linear white
+ space character that immediately follows.
+
+ When parsing a content line, folded lines MUST first be unfolded
+ according to the unfolding procedure described above. When generating
+ a content line, lines longer than 75 octets SHOULD be folded
+ according to the folding procedure described above.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 13]
+
+RFC 2445 iCalendar November 1998
+
+
+ The content information associated with an iCalendar object is
+ formatted using a syntax similar to that defined by [RFC 2425]. That
+ is, the content information consists of CRLF-separated content lines.
+
+ The following notation defines the lines of content in an iCalendar
+ object:
+
+ contentline = name *(";" param ) ":" value CRLF
+ ; This ABNF is just a general definition for an initial parsing
+ ; of the content line into its property name, parameter list,
+ ; and value string
+
+ ; When parsing a content line, folded lines MUST first
+ ; be unfolded according to the unfolding procedure
+ ; described above. When generating a content line, lines
+ ; longer than 75 octets SHOULD be folded according to
+ ; the folding procedure described above.
+
+ name = x-name / iana-token
+
+ iana-token = 1*(ALPHA / DIGIT / "-")
+ ; iCalendar identifier registered with IANA
+
+ x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
+ ; Reservered for experimental use. Not intended for use in
+ ; released products.
+
+ vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
+
+ param = param-name "=" param-value
+ *("," param-value)
+ ; Each property defines the specific ABNF for the parameters
+ ; allowed on the property. Refer to specific properties for
+ ; precise parameter ABNF.
+
+ param-name = iana-token / x-token
+
+ param-value = paramtext / quoted-string
+
+ paramtext = *SAFE-CHAR
+
+ value = *VALUE-CHAR
+
+ quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
+
+ NON-US-ASCII = %x80-F8
+ ; Use restricted by charset parameter
+ ; on outer MIME object (UTF-8 preferred)
+
+
+
+Dawson & Stenerson Standards Track [Page 14]
+
+RFC 2445 iCalendar November 1998
+
+
+ QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
+ ; Any character except CTLs and DQUOTE
+
+ SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
+ / NON-US-ASCII
+ ; Any character except CTLs, DQUOTE, ";", ":", ","
+
+ VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
+ ; Any textual character
+
+ CR = %x0D
+ ; carriage return
+
+ LF = %x0A
+ ; line feed
+
+ CRLF = CR LF
+ ; Internet standard newline
+
+ CTL = %x00-08 / %x0A-1F / %x7F
+ ; Controls
+
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+
+ DIGIT = %x30-39
+ ; 0-9
+
+ DQUOTE = %x22
+ ; Quotation Mark
+
+ WSP = SPACE / HTAB
+
+ SPACE = %x20
+
+ HTAB = %x09
+
+ The property value component of a content line has a format that is
+ property specific. Refer to the section describing each property for
+ a definition of this format.
+
+ All names of properties, property parameters, enumerated property
+ values and property parameter values are case-insensitive. However,
+ all other property values are case-sensitive, unless otherwise
+ stated.
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 15]
+
+RFC 2445 iCalendar November 1998
+
+
+4.1.1 List and Field Separators
+
+ Some properties and parameters allow a list of values. Values in a
+ list of values MUST be separated by a COMMA character (US-ASCII
+ decimal 44). There is no significance to the order of values in a
+ list. For those parameter values (such as those that specify URI
+ values) that are specified in quoted-strings, the individual quoted-
+ strings are separated by a COMMA character (US-ASCII decimal 44).
+
+ Some property values are defined in terms of multiple parts. These
+ structured property values MUST have their value parts separated by a
+ SEMICOLON character (US-ASCII decimal 59).
+
+ Some properties allow a list of parameters. Each property parameter
+ in a list of property parameters MUST be separated by a SEMICOLON
+ character (US-ASCII decimal 59).
+
+ Property parameters with values containing a COLON, a SEMICOLON or a
+ COMMA character MUST be placed in quoted text.
+
+ For example, in the following properties a SEMICOLON is used to
+ separate property parameters from each other, and a COMMA is used to
+ separate property values in a value list.
+
+ ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
+ jsmith@host.com
+
+ RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
+
+4.1.2 Multiple Values
+
+ Some properties defined in the iCalendar object can have multiple
+ values. The general rule for encoding multi-valued items is to simply
+ create a new content line for each value, including the property
+ name. However, it should be noted that some properties support
+ encoding multiple values in a single property by separating the
+ values with a COMMA character (US-ASCII decimal 44). Individual
+ property definitions should be consulted for determining whether a
+ specific property allows multiple values and in which of these two
+ forms.
+
+4.1.3 Binary Content
+
+ Binary content information in an iCalendar object SHOULD be
+ referenced using a URI within a property value. That is the binary
+ content information SHOULD be placed in an external MIME entity that
+ can be referenced by a URI from within the iCalendar object. In
+ applications where this is not feasible, binary content information
+
+
+
+Dawson & Stenerson Standards Track [Page 16]
+
+RFC 2445 iCalendar November 1998
+
+
+ can be included within an iCalendar object, but only after first
+ encoding it into text using the "BASE64" encoding method defined in
+ [RFC 2045]. Inline binary contact SHOULD only be used in applications
+ whose special circumstances demand that an iCalendar object be
+ expressed as a single entity. A property containing inline binary
+ content information MUST specify the "ENCODING" property parameter.
+ Binary content information placed external to the iCalendar object
+ MUST be referenced by a uniform resource identifier (URI).
+
+ The following example specifies an "ATTACH" property that references
+ an attachment external to the iCalendar object with a URI reference:
+
+ ATTACH:http://xyz.com/public/quarterly-report.doc
+
+ The following example specifies an "ATTACH" property with inline
+ binary encoded content information:
+
+ ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
+ MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
+ EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
+ <...remainder of "BASE64" encoded binary data...>
+
+4.1.4 Character Set
+
+ There is not a property parameter to declare the character set used
+ in a property value. The default character set for an iCalendar
+ object is UTF-8 as defined in [RFC 2279].
+
+ The "charset" Content-Type parameter can be used in MIME transports
+ to specify any other IANA registered character set.
+
+4.2 Property Parameters
+
+ A property can have attributes associated with it. These "property
+ parameters" contain meta-information about the property or the
+ property value. Property parameters are provided to specify such
+ information as the location of an alternate text representation for a
+ property value, the language of a text property value, the data type
+ of the property value and other attributes.
+
+ Property parameter values that contain the COLON (US-ASCII decimal
+ 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
+ character separators MUST be specified as quoted-string text values.
+ Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII
+ decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22)
+ character is used as a delimiter for parameter values that contain
+ restricted characters or URI text. For example:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 17]
+
+RFC 2445 iCalendar November 1998
+
+
+ DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
+ Conference - - Las Vegas, NV, USA
+
+ Property parameter values that are not in quoted strings are case
+ insensitive.
+
+ The general property parameters defined by this memo are defined by
+ the following notation:
+
+ parameter = altrepparam ; Alternate text representation
+ / cnparam ; Common name
+ / cutypeparam ; Calendar user type
+ / delfromparam ; Delegator
+ / deltoparam ; Delegatee
+ / dirparam ; Directory entry
+ / encodingparam ; Inline encoding
+ / fmttypeparam ; Format type
+ / fbtypeparam ; Free/busy time type
+ / languageparam ; Language for text
+ / memberparam ; Group or list membership
+ / partstatparam ; Participation status
+ / rangeparam ; Recurrence identifier range
+ / trigrelparam ; Alarm trigger relationship
+ / reltypeparam ; Relationship type
+ / roleparam ; Participation role
+ / rsvpparam ; RSVP expectation
+ / sentbyparam ; Sent by
+ / tzidparam ; Reference to time zone object
+ / valuetypeparam ; Property value data type
+ / ianaparam
+ ; Some other IANA registered iCalendar parameter.
+ / xparam
+ ; A non-standard, experimental parameter.
+
+ ianaparam = iana-token "=" param-value *("," param-value)
+
+ xparam =x-name "=" param-value *("," param-value)
+
+4.2.1 Alternate Text Representation
+
+ Parameter Name: ALTREP
+
+ Purpose: To specify an alternate text representation for the property
+ value.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 18]
+
+RFC 2445 iCalendar November 1998
+
+
+ altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE
+
+ Description: The parameter specifies a URI that points to an
+ alternate representation for a textual property value. A property
+ specifying this parameter MUST also include a value that reflects the
+ default representation of the text value. The individual URI
+ parameter values MUST each be specified in a quoted-string.
+
+ Example:
+
+ DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
+ XYZ Review Meeting will include the following agenda items: (a)
+ Market Overview, (b) Finances, (c) Project Management
+
+ The "ALTREP" property parameter value might point to a "text/html"
+ content portion.
+
+ Content-Type:text/html
+ Content-Id:<part3.msg.970415T083000@host.com>
+
+ <html><body>
+ <p><b>Project XYZ Review Meeting</b> will include the following
+ agenda items:<ol><li>Market
+ Overview</li><li>Finances</li><li>Project Management</li></ol></p>
+ </body></html>
+
+4.2.2 Common Name
+
+ Parameter Name: CN
+
+ Purpose: To specify the common name to be associated with the
+ calendar user specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ cnparam = "CN" "=" param-value
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter specifies the common name to be
+ associated with the calendar user specified by the property. The
+ parameter value is text. The parameter value can be used for display
+ text to be associated with the calendar address specified by the
+ property.
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 19]
+
+RFC 2445 iCalendar November 1998
+
+
+ Example:
+
+ ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com
+
+4.2.3 Calendar User Type
+
+ Parameter Name: CUTYPE
+
+ Purpose: To specify the type of calendar user specified by the
+ property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ cutypeparam = "CUTYPE" "="
+ ("INDIVIDUAL" ; An individual
+ / "GROUP" ; A group of individuals
+ / "RESOURCE" ; A physical resource
+ / "ROOM" ; A room resource
+ / "UNKNOWN" ; Otherwise not known
+ / x-name ; Experimental type
+ / iana-token) ; Other IANA registered
+ ; type
+ ; Default is INDIVIDUAL
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter identifies the type of calendar
+ user specified by the property. If not specified on a property that
+ allows this parameter, the default is INDIVIDUAL.
+
+ Example:
+
+ ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
+
+4.2.4 Delegators
+
+ Parameter Name: DELEGATED-FROM
+
+ Purpose: To specify the calendar users that have delegated their
+ participation to the calendar user specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE
+ *("," DQUOTE cal-address DQUOTE)
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 20]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. This parameter can be specified on a property
+ that has a value type of calendar address. This parameter specifies
+ those calendar uses that have delegated their participation in a
+ group scheduled event or to-do to the calendar user specified by the
+ property. The value MUST be a MAILTO URI as defined in [RFC 1738].
+ The individual calendar address parameter values MUST each be
+ specified in a quoted-string.
+
+ Example:
+
+ ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO:
+ jdoe@host.com
+
+4.2.5 Delegatees
+
+ Parameter Name: DELEGATED-TO
+
+ Purpose: To specify the calendar users to whom the calendar user
+ specified by the property has delegated participation.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
+ *("," DQUOTE cal-address DQUOTE)
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. This parameter specifies those calendar users
+ whom have been delegated participation in a group scheduled event or
+ to-do by the calendar user specified by the property. The value MUST
+ be a MAILTO URI as defined in [RFC 1738]. The individual calendar
+ address parameter values MUST each be specified in a quoted-string.
+
+ Example:
+
+ ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@
+ host.com":MAILTO:jsmith@host.com
+
+4.2.6 Directory Entry Reference
+
+ Parameter Name: DIR
+
+ Purpose: To specify reference to a directory entry associated with
+ the calendar user specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+
+
+Dawson & Stenerson Standards Track [Page 21]
+
+RFC 2445 iCalendar November 1998
+
+
+ dirparam = "DIR" "=" DQUOTE uri DQUOTE
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter specifies a reference to the
+ directory entry associated with the calendar user specified by the
+ property. The parameter value is a URI. The individual URI parameter
+ values MUST each be specified in a quoted-string.
+
+ Example:
+
+ ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS??
+ (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com
+
+4.2.7 Inline Encoding
+
+ Parameter Name: ENCODING
+
+ Purpose: To specify an alternate inline encoding for the property
+ value.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ encodingparam = "ENCODING" "="
+ ("8BIT"
+ ; "8bit" text encoding is defined in [RFC 2045]
+ / "BASE64"
+ ; "BASE64" binary encoding format is defined in [RFC 2045]
+ / iana-token
+ ; Some other IANA registered iCalendar encoding type
+ / x-name)
+ ; A non-standard, experimental encoding type
+
+ Description: The property parameter identifies the inline encoding
+ used in a property value. The default encoding is "8BIT",
+ corresponding to a property value consisting of text. The "BASE64"
+ encoding type corresponds to a property value encoded using the
+ "BASE64" encoding defined in [RFC 2045].
+
+ If the value type parameter is ";VALUE=BINARY", then the inline
+ encoding parameter MUST be specified with the value
+ ";ENCODING=BASE64".
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 22]
+
+RFC 2445 iCalendar November 1998
+
+
+ Example:
+
+ ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
+ CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
+ qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
+ <...remainder of "BASE64" encoded binary data...>
+
+4.2.8 Format Type
+
+ Parameter Name: FMTTYPE
+
+ Purpose: To specify the content type of a referenced object.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ fmttypeparam = "FMTTYPE" "=" iana-token
+ ; A IANA registered content type
+ / x-name
+ ; A non-standard content type
+
+ Description: This parameter can be specified on properties that are
+ used to reference an object. The parameter specifies the content type
+ of the referenced object. For example, on the "ATTACH" property, a
+ FTP type URI value does not, by itself, necessarily convey the type
+ of content associated with the resource. The parameter value MUST be
+ the TEXT for either an IANA registered content type or a non-standard
+ content type.
+
+ Example:
+
+ ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
+ agenda.doc
+
+4.2.9 Free/Busy Time Type
+
+ Parameter Name: FBTYPE
+
+ Purpose: To specify the free or busy time type.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY"
+ / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
+ / x-name
+ ; Some experimental iCalendar data type.
+ / iana-token)
+
+
+
+Dawson & Stenerson Standards Track [Page 23]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; Some other IANA registered iCalendar data type.
+
+ Description: The parameter specifies the free or busy time type. The
+ value FREE indicates that the time interval is free for scheduling.
+ The value BUSY indicates that the time interval is busy because one
+ or more events have been scheduled for that interval. The value
+ BUSY-UNAVAILABLE indicates that the time interval is busy and that
+ the interval can not be scheduled. The value BUSY-TENTATIVE indicates
+ that the time interval is busy because one or more events have been
+ tentatively scheduled for that interval. If not specified on a
+ property that allows this parameter, the default is BUSY.
+
+ Example: The following is an example of this parameter on a FREEBUSY
+ property.
+
+ FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
+
+4.2.10 Language
+
+ Parameter Name: LANGUAGE
+
+ Purpose: To specify the language for text values in a property or
+ property parameter.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ languageparam = "LANGUAGE" "=" language
+
+ language = <Text identifying a language, as defined in [RFC 1766]>
+
+ Description: This parameter can be specified on properties with a
+ text value type. The parameter identifies the language of the text in
+ the property or property parameter value. The value of the "language"
+ property parameter is that defined in [RFC 1766].
+
+ For transport in a MIME entity, the Content-Language header field can
+ be used to set the default language for the entire body part.
+ Otherwise, no default language is assumed.
+
+ Example:
+
+ SUMMARY;LANGUAGE=us-EN:Company Holiday Party
+
+ LOCATION;LANGUAGE=en:Germany
+ LOCATION;LANGUAGE=no:Tyskland
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 24]
+
+RFC 2445 iCalendar November 1998
+
+
+ The following example makes use of the Quoted-Printable encoding in
+ order to represent non-ASCII characters.
+
+ LOCATION;LANGUAGE=da:K=F8benhavn
+ LOCATION;LANGUAGE=en:Copenhagen
+
+4.2.11 Group or List Membership
+
+ Parameter Name: MEMBER
+
+ Purpose: To specify the group or list membership of the calendar user
+ specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE
+ *("," DQUOTE cal-address DQUOTE)
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter identifies the groups or list
+ membership for the calendar user specified by the property. The
+ parameter value either a single calendar address in a quoted-string
+ or a COMMA character (US-ASCII decimal 44) list of calendar
+ addresses, each in a quoted-string. The individual calendar address
+ parameter values MUST each be specified in a quoted-string.
+
+ Example:
+
+ ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com
+
+ ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host.
+ com":MAILTO:janedoe@host.com
+
+4.2.12 Participation Status
+
+ Parameter Name: PARTSTAT
+
+ Purpose: To specify the participation status for the calendar user
+ specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ partstatparam = "PARTSTAT" "="
+ ("NEEDS-ACTION" ; Event needs action
+ / "ACCEPTED" ; Event accepted
+ / "DECLINED" ; Event declined
+
+
+
+Dawson & Stenerson Standards Track [Page 25]
+
+RFC 2445 iCalendar November 1998
+
+
+ / "TENTATIVE" ; Event tentatively
+ ; accepted
+ / "DELEGATED" ; Event delegated
+ / x-name ; Experimental status
+ / iana-token) ; Other IANA registered
+ ; status
+ ; These are the participation statuses for a "VEVENT". Default is
+ ; NEEDS-ACTION
+ partstatparam /= "PARTSTAT" "="
+ ("NEEDS-ACTION" ; To-do needs action
+ / "ACCEPTED" ; To-do accepted
+ / "DECLINED" ; To-do declined
+ / "TENTATIVE" ; To-do tentatively
+ ; accepted
+ / "DELEGATED" ; To-do delegated
+ / "COMPLETED" ; To-do completed.
+ ; COMPLETED property has
+ ;date/time completed.
+ / "IN-PROCESS" ; To-do in process of
+ ; being completed
+ / x-name ; Experimental status
+ / iana-token) ; Other IANA registered
+ ; status
+ ; These are the participation statuses for a "VTODO". Default is
+ ; NEEDS-ACTION
+
+ partstatparam /= "PARTSTAT" "="
+ ("NEEDS-ACTION" ; Journal needs action
+ / "ACCEPTED" ; Journal accepted
+ / "DECLINED" ; Journal declined
+ / x-name ; Experimental status
+ / iana-token) ; Other IANA registered
+ ; status
+ ; These are the participation statuses for a "VJOURNAL". Default is
+ ; NEEDS-ACTION
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter identifies the participation
+ status for the calendar user specified by the property value. The
+ parameter values differ depending on whether they are associated with
+ a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST
+ match one of the values allowed for the given calendar component. If
+ not specified on a property that allows this parameter, the default
+ value is NEEDS-ACTION.
+
+ Example:
+
+ ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com
+
+
+
+Dawson & Stenerson Standards Track [Page 26]
+
+RFC 2445 iCalendar November 1998
+
+
+4.2.13 Recurrence Identifier Range
+
+ Parameter Name: RANGE
+
+ Purpose: To specify the effective range of recurrence instances from
+ the instance specified by the recurrence identifier specified by the
+ property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ rangeparam = "RANGE" "=" ("THISANDPRIOR"
+ ; To specify all instances prior to the recurrence identifier
+ / "THISANDFUTURE")
+ ; To specify the instance specified by the recurrence identifier
+ ; and all subsequent recurrence instances
+
+ Description: The parameter can be specified on a property that
+ specifies a recurrence identifier. The parameter specifies the
+ effective range of recurrence instances that is specified by the
+ property. The effective range is from the recurrence identified
+ specified by the property. If this parameter is not specified an
+ allowed property, then the default range is the single instance
+ specified by the recurrence identifier value of the property. The
+ parameter value can be "THISANDPRIOR" to indicate a range defined by
+ the recurrence identified value of the property and all prior
+ instances. The parameter value can also be "THISANDFUTURE" to
+ indicate a range defined by the recurrence identifier and all
+ subsequent instances.
+
+ Example:
+
+ RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
+
+4.2.14 Alarm Trigger Relationship
+
+ Parameter Name: RELATED
+
+ Purpose: To specify the relationship of the alarm trigger with
+ respect to the start or end of the calendar component.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ trigrelparam = "RELATED" "="
+ ("START" ; Trigger off of start
+ / "END") ; Trigger off of end
+
+
+
+
+Dawson & Stenerson Standards Track [Page 27]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: The parameter can be specified on properties that
+ specify an alarm trigger with a DURATION value type. The parameter
+ specifies whether the alarm will trigger relative to the start or end
+ of the calendar component. The parameter value START will set the
+ alarm to trigger off the start of the calendar component; the
+ parameter value END will set the alarm to trigger off the end of the
+ calendar component. If the parameter is not specified on an allowable
+ property, then the default is START.
+
+ Example:
+
+ TRIGGER;RELATED=END:PT5M
+
+4.2.15 Relationship Type
+
+ Parameter Name: RELTYPE
+
+ Purpose: To specify the type of hierarchical relationship associated
+ with the calendar component specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ reltypeparam = "RELTYPE" "="
+ ("PARENT" ; Parent relationship. Default.
+ / "CHILD" ; Child relationship
+ / "SIBLING ; Sibling relationship
+ / iana-token ; Some other IANA registered
+ ; iCalendar relationship type
+ / x-name) ; A non-standard, experimental
+ ; relationship type
+
+ Description: This parameter can be specified on a property that
+ references another related calendar. The parameter specifies the
+ hierarchical relationship type of the calendar component referenced
+ by the property. The parameter value can be PARENT, to indicate that
+ the referenced calendar component is a superior of calendar
+ component; CHILD to indicate that the referenced calendar component
+ is a subordinate of the calendar component; SIBLING to indicate that
+ the referenced calendar component is a peer of the calendar
+ component. If this parameter is not specified on an allowable
+ property, the default relationship type is PARENT.
+
+ Example:
+
+ RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com>
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 28]
+
+RFC 2445 iCalendar November 1998
+
+
+4.2.16 Participation Role
+
+ Parameter Name: ROLE
+
+ Purpose: To specify the participation role for the calendar user
+ specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ roleparam = "ROLE" "="
+ ("CHAIR" ; Indicates chair of the
+ ; calendar entity
+ / "REQ-PARTICIPANT" ; Indicates a participant whose
+ ; participation is required
+ / "OPT-PARTICIPANT" ; Indicates a participant whose
+ ; participation is optional
+ / "NON-PARTICIPANT" ; Indicates a participant who is
+ ; copied for information
+ ; purposes only
+ / x-name ; Experimental role
+ / iana-token) ; Other IANA role
+ ; Default is REQ-PARTICIPANT
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter specifies the participation
+ role for the calendar user specified by the property in the group
+ schedule calendar component. If not specified on a property that
+ allows this parameter, the default value is REQ-PARTICIPANT.
+
+ Example:
+
+ ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com
+
+4.2.17 RSVP Expectation
+
+ Parameter Name: RSVP
+
+ Purpose: To specify whether there is an expectation of a favor of a
+ reply from the calendar user specified by the property value.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
+ ; Default is FALSE
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 29]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter identifies the expectation of a
+ reply from the calendar user specified by the property value. This
+ parameter is used by the "Organizer" to request a participation
+ status reply from an "Attendee" of a group scheduled event or to-do.
+ If not specified on a property that allows this parameter, the
+ default value is FALSE.
+
+ Example:
+
+ ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com
+
+4.2.18 Sent By
+
+ Parameter Name: SENT-BY
+
+ Purpose: To specify the calendar user that is acting on behalf of the
+ calendar user specified by the property.
+
+ Format Definition: The property parameter is defined by the following
+ notation:
+
+ sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE
+
+ Description: This parameter can be specified on properties with a
+ CAL-ADDRESS value type. The parameter specifies the calendar user
+ that is acting on behalf of the calendar user specified by the
+ property. The parameter value MUST be a MAILTO URI as defined in [RFC
+ 1738]. The individual calendar address parameter values MUST each be
+ specified in a quoted-string.
+
+ Example:
+
+ ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
+
+4.2.19 Time Zone Identifier
+
+ Parameter Name: TZID
+
+ Purpose: To specify the identifier for the time zone definition for a
+ time component in the property value.
+
+ Format Definition: This property parameter is defined by the
+ following notation:
+
+ tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF
+
+ tzidprefix = "/"
+
+
+
+Dawson & Stenerson Standards Track [Page 30]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: The parameter MUST be specified on the "DTSTART",
+ "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
+ TIME or TIME value type is specified and when the value is not either
+ a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
+ definition for a description of UTC and "floating time" formats. This
+ property parameter specifies a text value which uniquely identifies
+ the "VTIMEZONE" calendar component to be used when evaluating the
+ time portion of the property. The value of the TZID property
+ parameter will be equal to the value of the TZID property for the
+ matching time zone definition. An individual "VTIMEZONE" calendar
+ component MUST be specified for each unique "TZID" parameter value
+ specified in the iCalendar object.
+
+ The parameter MUST be specified on properties with a DATE-TIME value
+ if the DATE-TIME is not either a UTC or a "floating" time.
+
+ The presence of the SOLIDUS character (US-ASCII decimal 47) as a
+ prefix, indicates that this TZID represents a unique ID in a globally
+ defined time zone registry (when such registry is defined).
+
+ Note: This document does not define a naming convention for time
+ zone identifiers. Implementers may want to use the naming
+ conventions defined in existing time zone specifications such as
+ the public-domain Olson database [TZ]. The specification of
+ globally unique time zone identifiers is not addressed by this
+ document and is left for future study.
+
+ The following are examples of this property parameter:
+
+ DTSTART;TZID=US-Eastern:19980119T020000
+
+ DTEND;TZID=US-Eastern:19980119T030000
+
+ The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
+ properties whose time values are specified in UTC.
+
+ The use of local time in a DATE-TIME or TIME value without the TZID
+ property parameter is to be interpreted as a local time value,
+ regardless of the existence of "VTIMEZONE" calendar components in the
+ iCalendar object.
+
+ For more information see the sections on the data types DATE-TIME and
+ TIME.
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 31]
+
+RFC 2445 iCalendar November 1998
+
+
+4.2.20 Value Data Types
+
+ Parameter Name: VALUE
+
+ Purpose: To explicitly specify the data type format for a property
+ value.
+
+ Format Definition: The "VALUE" property parameter is defined by the
+ following notation:
+
+ valuetypeparam = "VALUE" "=" valuetype
+
+ valuetype = ("BINARY"
+ / "BOOLEAN"
+ / "CAL-ADDRESS"
+ / "DATE"
+ / "DATE-TIME"
+ / "DURATION"
+ / "FLOAT"
+ / "INTEGER"
+ / "PERIOD"
+ / "RECUR"
+ / "TEXT"
+ / "TIME"
+ / "URI"
+ / "UTC-OFFSET"
+ / x-name
+ ; Some experimental iCalendar data type.
+ / iana-token)
+ ; Some other IANA registered iCalendar data type.
+
+ Description: The parameter specifies the data type and format of the
+ property value. The property values MUST be of a single value type.
+ For example, a "RDATE" property cannot have a combination of DATE-
+ TIME and TIME value types.
+
+ If the property's value is the default value type, then this
+ parameter need not be specified. However, if the property's default
+ value type is overridden by some other allowable value type, then
+ this parameter MUST be specified.
+
+4.3 Property Value Data Types
+
+ The properties in an iCalendar object are strongly typed. The
+ definition of each property restricts the value to be one of the
+ value data types, or simply value types, defined in this section. The
+ value type for a property will either be specified implicitly as the
+ default value type or will be explicitly specified with the "VALUE"
+
+
+
+Dawson & Stenerson Standards Track [Page 32]
+
+RFC 2445 iCalendar November 1998
+
+
+ parameter. If the value type of a property is one of the alternate
+ valid types, then it MUST be explicitly specified with the "VALUE"
+ parameter.
+
+4.3.1 Binary
+
+ Value Name: BINARY
+
+ Purpose: This value type is used to identify properties that contain
+ a character encoding of inline binary data. For example, an inline
+ attachment of an object code might be included in an iCalendar
+ object.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ binary = *(4b-char) [b-end]
+ ; A "BASE64" encoded character string, as defined by [RFC 2045].
+
+ b-end = (2b-char "==") / (3b-char "=")
+
+ b-char = ALPHA / DIGIT / "+" / "/"
+
+ Description: Property values with this value type MUST also include
+ the inline encoding parameter sequence of ";ENCODING=BASE64". That
+ is, all inline binary data MUST first be character encoded using the
+ "BASE64" encoding method defined in [RFC 2045]. No additional content
+ value encoding (i.e., BACKSLASH character encoding) is defined for
+ this value type.
+
+ Example: The following is an abridged example of a "BASE64" encoded
+ binary value data.
+
+ ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
+ JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
+ ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
+ <...remainder of "BASE64" encoded binary data...>
+
+4.3.2 Boolean
+
+ Value Name: BOOLEAN
+
+ Purpose: This value type is used to identify properties that contain
+ either a "TRUE" or "FALSE" Boolean value.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 33]
+
+RFC 2445 iCalendar November 1998
+
+
+ boolean = "TRUE" / "FALSE"
+
+ Description: These values are case insensitive text. No additional
+ content value encoding (i.e., BACKSLASH character encoding) is
+ defined for this value type.
+
+ Example: The following is an example of a hypothetical property that
+ has a BOOLEAN value type:
+
+ GIBBERISH:TRUE
+
+4.3.3 Calendar User Address
+
+ Value Name: CAL-ADDRESS
+
+ Purpose: This value type is used to identify properties that contain
+ a calendar user address.
+
+ Formal Definition: The value type is as defined by the following
+ notation:
+
+ cal-address = uri
+
+ Description: The value is a URI as defined by [RFC 1738] or any other
+ IANA registered form for a URI. When used to address an Internet
+ email transport address for a calendar user, the value MUST be a
+ MAILTO URI, as defined by [RFC 1738]. No additional content value
+ encoding (i.e., BACKSLASH character encoding) is defined for this
+ value type.
+
+ Example:
+
+ ATTENDEE:MAILTO:jane_doe@host.com
+
+4.3.4 Date
+
+ Value Name: DATE
+
+ Purpose: This value type is used to identify values that contain a
+ calendar date.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ date = date-value
+
+ date-value = date-fullyear date-month date-mday
+ date-fullyear = 4DIGIT
+
+
+
+Dawson & Stenerson Standards Track [Page 34]
+
+RFC 2445 iCalendar November 1998
+
+
+ date-month = 2DIGIT ;01-12
+ date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
+ ;based on month/year
+
+ Description: If the property permits, multiple "date" values are
+ specified as a COMMA character (US-ASCII decimal 44) separated list
+ of values. The format for the value type is expressed as the [ISO
+ 8601] complete representation, basic format for a calendar date. The
+ textual format specifies a four-digit year, two-digit month, and
+ two-digit day of the month. There are no separator characters between
+ the year, month and day component text.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example: The following represents July 14, 1997:
+
+ 19970714
+
+4.3.5 Date-Time
+
+ Value Name: DATE-TIME
+
+ Purpose: This value type is used to identify values that specify a
+ precise calendar date and time of day.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ date-time = date "T" time ;As specified in the date and time
+ ;value definitions
+
+ Description: If the property permits, multiple "date-time" values are
+ specified as a COMMA character (US-ASCII decimal 44) separated list
+ of values. No additional content value encoding (i.e., BACKSLASH
+ character encoding) is defined for this value type.
+
+ The "DATE-TIME" data type is used to identify values that contain a
+ precise calendar date and time of day. The format is based on the
+ [ISO 8601] complete representation, basic format for a calendar date
+ and time of day. The text format is a concatenation of the "date",
+ followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal
+ 84) time designator, followed by the "time" format.
+
+ The "DATE-TIME" data type expresses time values in three forms:
+
+ The form of date and time with UTC offset MUST NOT be used. For
+ example, the following is not valid for a date-time value:
+
+
+
+Dawson & Stenerson Standards Track [Page 35]
+
+RFC 2445 iCalendar November 1998
+
+
+ DTSTART:19980119T230000-0800 ;Invalid time format
+
+ FORM #1: DATE WITH LOCAL TIME
+
+ The date with local time form is simply a date-time value that does
+ not contain the UTC designator nor does it reference a time zone. For
+ example, the following represents Janurary 18, 1998, at 11 PM:
+
+ DTSTART:19980118T230000
+
+ Date-time values of this type are said to be "floating" and are not
+ bound to any time zone in particular. They are used to represent the
+ same hour, minute, and second value regardless of which time zone is
+ currently being observed. For example, an event can be defined that
+ indicates that an individual will be busy from 11:00 AM to 1:00 PM
+ every day, no matter which time zone the person is in. In these
+ cases, a local time can be specified. The recipient of an iCalendar
+ object with a property value consisting of a local time, without any
+ relative time zone information, SHOULD interpret the value as being
+ fixed to whatever time zone the ATTENDEE is in at any given moment.
+ This means that two ATTENDEEs, in different time zones, receiving the
+ same event definition as a floating time, may be participating in the
+ event at different actual times. Floating time SHOULD only be used
+ where that is the reasonable behavior.
+
+ In most cases, a fixed time is desired. To properly communicate a
+ fixed time in a property value, either UTC time or local time with
+ time zone reference MUST be specified.
+
+ The use of local time in a DATE-TIME value without the TZID property
+ parameter is to be interpreted as floating time, regardless of the
+ existence of "VTIMEZONE" calendar components in the iCalendar object.
+
+ FORM #2: DATE WITH UTC TIME
+
+ The date with UTC time, or absolute time, is identified by a LATIN
+ CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
+ designator, appended to the time value. For example, the following
+ represents January 19, 1998, at 0700 UTC:
+
+ DTSTART:19980119T070000Z
+
+ The TZID property parameter MUST NOT be applied to DATE-TIME
+ properties whose time values are specified in UTC.
+
+ FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 36]
+
+RFC 2445 iCalendar November 1998
+
+
+ The date and local time with reference to time zone information is
+ identified by the use the TZID property parameter to reference the
+ appropriate time zone definition. TZID is discussed in detail in the
+ section on Time Zone. For example, the following represents 2 AM in
+ New York on Janurary 19, 1998:
+
+ DTSTART;TZID=US-Eastern:19980119T020000
+
+ Example: The following represents July 14, 1997, at 1:30 PM in New
+ York City in each of the three time formats, using the "DTSTART"
+ property.
+
+ DTSTART:19970714T133000 ;Local time
+ DTSTART:19970714T173000Z ;UTC time
+ DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time
+ ; zone reference
+
+ A time value MUST ONLY specify 60 seconds when specifying the
+ periodic "leap second" in the time value. For example:
+
+ COMPLETED:19970630T235960Z
+
+4.3.6 Duration
+
+ Value Name: DURATION
+
+ Purpose: This value type is used to identify properties that contain
+ a duration of time.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
+
+ dur-date = dur-day [dur-time]
+ dur-time = "T" (dur-hour / dur-minute / dur-second)
+ dur-week = 1*DIGIT "W"
+ dur-hour = 1*DIGIT "H" [dur-minute]
+ dur-minute = 1*DIGIT "M" [dur-second]
+ dur-second = 1*DIGIT "S"
+ dur-day = 1*DIGIT "D"
+
+ Description: If the property permits, multiple "duration" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values. The format is expressed as the [ISO 8601] basic format for
+ the duration of time. The format can represent durations in terms of
+ weeks, days, hours, minutes, and seconds.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 37]
+
+RFC 2445 iCalendar November 1998
+
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) are defined for this value type.
+
+ Example: A duration of 15 days, 5 hours and 20 seconds would be:
+
+ P15DT5H0M20S
+
+ A duration of 7 weeks would be:
+
+ P7W
+
+4.3.7 Float
+
+ Value Name: FLOAT
+
+ Purpose: This value type is used to identify properties that contain
+ a real number value.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
+
+ Description: If the property permits, multiple "float" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example:
+
+ 1000000.0000001
+ 1.333
+ -3.14
+
+4.3.8 Integer
+
+ Value Name:INTEGER
+
+ Purpose: This value type is used to identify properties that contain
+ a signed integer value.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ integer = (["+"] / "-") 1*DIGIT
+
+
+
+
+Dawson & Stenerson Standards Track [Page 38]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: If the property permits, multiple "integer" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values. The valid range for "integer" is -2147483648 to
+ 2147483647. If the sign is not specified, then the value is assumed
+ to be positive.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example:
+
+ 1234567890
+ -1234567890
+ +1234567890
+ 432109876
+
+4.3.9 Period of Time
+
+ Value Name: PERIOD
+
+ Purpose: This value type is used to identify values that contain a
+ precise period of time.
+
+ Formal Definition: The data type is defined by the following
+ notation:
+
+ period = period-explicit / period-start
+
+ period-explicit = date-time "/" date-time
+ ; [ISO 8601] complete representation basic format for a period of
+ ; time consisting of a start and end. The start MUST be before the
+ ; end.
+
+ period-start = date-time "/" dur-value
+ ; [ISO 8601] complete representation basic format for a period of
+ ; time consisting of a start and positive duration of time.
+
+ Description: If the property permits, multiple "period" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values. There are two forms of a period of time. First, a period
+ of time is identified by its start and its end. This format is
+ expressed as the [ISO 8601] complete representation, basic format for
+ "DATE-TIME" start of the period, followed by a SOLIDUS character
+ (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the
+ period. The start of the period MUST be before the end of the period.
+ Second, a period of time can also be defined by a start and a
+ positive duration of time. The format is expressed as the [ISO 8601]
+ complete representation, basic format for the "DATE-TIME" start of
+
+
+
+Dawson & Stenerson Standards Track [Page 39]
+
+RFC 2445 iCalendar November 1998
+
+
+ the period, followed by a SOLIDUS character (US-ASCII decimal 47),
+ followed by the [ISO 8601] basic format for "DURATION" of the period.
+
+ Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
+ ending at 07:00:00 UTC on January 2, 1997 would be:
+
+ 19970101T180000Z/19970102T070000Z
+
+ The period start at 18:00:00 on January 1, 1997 and lasting 5 hours
+ and 30 minutes would be:
+
+ 19970101T180000Z/PT5H30M
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+4.3.10 Recurrence Rule
+
+ Value Name: RECUR
+
+ Purpose: This value type is used to identify properties that contain
+ a recurrence rule specification.
+
+ Formal Definition: The value type is defined by the following
+ notation:
+
+ recur = "FREQ"=freq *(
+
+ ; either UNTIL or COUNT may appear in a 'recur',
+ ; but UNTIL and COUNT MUST NOT occur in the same 'recur'
+
+ ( ";" "UNTIL" "=" enddate ) /
+ ( ";" "COUNT" "=" 1*DIGIT ) /
+
+ ; the rest of these keywords are optional,
+ ; but MUST NOT occur more than once
+
+ ( ";" "INTERVAL" "=" 1*DIGIT ) /
+ ( ";" "BYSECOND" "=" byseclist ) /
+ ( ";" "BYMINUTE" "=" byminlist ) /
+ ( ";" "BYHOUR" "=" byhrlist ) /
+ ( ";" "BYDAY" "=" bywdaylist ) /
+ ( ";" "BYMONTHDAY" "=" bymodaylist ) /
+ ( ";" "BYYEARDAY" "=" byyrdaylist ) /
+ ( ";" "BYWEEKNO" "=" bywknolist ) /
+ ( ";" "BYMONTH" "=" bymolist ) /
+ ( ";" "BYSETPOS" "=" bysplist ) /
+ ( ";" "WKST" "=" weekday ) /
+
+
+
+Dawson & Stenerson Standards Track [Page 40]
+
+RFC 2445 iCalendar November 1998
+
+
+ ( ";" x-name "=" text )
+ )
+
+ freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
+ / "WEEKLY" / "MONTHLY" / "YEARLY"
+
+ enddate = date
+ enddate =/ date-time ;An UTC value
+
+ byseclist = seconds / ( seconds *("," seconds) )
+
+ seconds = 1DIGIT / 2DIGIT ;0 to 59
+
+ byminlist = minutes / ( minutes *("," minutes) )
+
+ minutes = 1DIGIT / 2DIGIT ;0 to 59
+
+ byhrlist = hour / ( hour *("," hour) )
+
+ hour = 1DIGIT / 2DIGIT ;0 to 23
+
+ bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
+
+ weekdaynum = [([plus] ordwk / minus ordwk)] weekday
+
+ plus = "+"
+
+ minus = "-"
+
+ ordwk = 1DIGIT / 2DIGIT ;1 to 53
+
+ weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
+ ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
+ ;FRIDAY, SATURDAY and SUNDAY days of the week.
+
+ bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
+
+ monthdaynum = ([plus] ordmoday) / (minus ordmoday)
+
+ ordmoday = 1DIGIT / 2DIGIT ;1 to 31
+
+ byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
+
+ yeardaynum = ([plus] ordyrday) / (minus ordyrday)
+
+ ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366
+
+ bywknolist = weeknum / ( weeknum *("," weeknum) )
+
+
+
+Dawson & Stenerson Standards Track [Page 41]
+
+RFC 2445 iCalendar November 1998
+
+
+ weeknum = ([plus] ordwk) / (minus ordwk)
+
+ bymolist = monthnum / ( monthnum *("," monthnum) )
+
+ monthnum = 1DIGIT / 2DIGIT ;1 to 12
+
+ bysplist = setposday / ( setposday *("," setposday) )
+
+ setposday = yeardaynum
+
+ Description: If the property permits, multiple "recur" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values. The value type is a structured value consisting of a list
+ of one or more recurrence grammar parts. Each rule part is defined by
+ a NAME=VALUE pair. The rule parts are separated from each other by
+ the SEMICOLON character (US-ASCII decimal 59). The rule parts are not
+ ordered in any particular sequence. Individual rule parts MUST only
+ be specified once.
+
+ The FREQ rule part identifies the type of recurrence rule. This rule
+ part MUST be specified in the recurrence rule. Valid values include
+ SECONDLY, to specify repeating events based on an interval of a
+ second or more; MINUTELY, to specify repeating events based on an
+ interval of a minute or more; HOURLY, to specify repeating events
+ based on an interval of an hour or more; DAILY, to specify repeating
+ events based on an interval of a day or more; WEEKLY, to specify
+ repeating events based on an interval of a week or more; MONTHLY, to
+ specify repeating events based on an interval of a month or more; and
+ YEARLY, to specify repeating events based on an interval of a year or
+ more.
+
+ The INTERVAL rule part contains a positive integer representing how
+ often the recurrence rule repeats. The default value is "1", meaning
+ every second for a SECONDLY rule, or every minute for a MINUTELY
+ rule, every hour for an HOURLY rule, every day for a DAILY rule,
+ every week for a WEEKLY rule, every month for a MONTHLY rule and
+ every year for a YEARLY rule.
+
+ The UNTIL rule part defines a date-time value which bounds the
+ recurrence rule in an inclusive manner. If the value specified by
+ UNTIL is synchronized with the specified recurrence, this date or
+ date-time becomes the last instance of the recurrence. If specified
+ as a date-time value, then it MUST be specified in an UTC time
+ format. If not present, and the COUNT rule part is also not present,
+ the RRULE is considered to repeat forever.
+
+ The COUNT rule part defines the number of occurrences at which to
+ range-bound the recurrence. The "DTSTART" property value, if
+
+
+
+Dawson & Stenerson Standards Track [Page 42]
+
+RFC 2445 iCalendar November 1998
+
+
+ specified, counts as the first occurrence.
+
+ The BYSECOND rule part specifies a COMMA character (US-ASCII decimal
+ 44) separated list of seconds within a minute. Valid values are 0 to
+ 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII
+ decimal 44) separated list of minutes within an hour. Valid values
+ are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-
+ ASCII decimal 44) separated list of hours of the day. Valid values
+ are 0 to 23.
+
+ The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44)
+ separated list of days of the week; MO indicates Monday; TU indicates
+ Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates
+ Friday; SA indicates Saturday; SU indicates Sunday.
+
+ Each BYDAY value can also be preceded by a positive (+n) or negative
+ (-n) integer. If present, this indicates the nth occurrence of the
+ specific day within the MONTHLY or YEARLY RRULE. For example, within
+ a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
+ within the month, whereas -1MO represents the last Monday of the
+ month. If an integer modifier is not present, it means all days of
+ this type within the specified frequency. For example, within a
+ MONTHLY rule, MO represents all Mondays within the month.
+
+ The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal
+ 44) separated list of days of the month. Valid values are 1 to 31 or
+ -31 to -1. For example, -10 represents the tenth to the last day of
+ the month.
+
+ The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal
+ 44) separated list of days of the year. Valid values are 1 to 366 or
+ -366 to -1. For example, -1 represents the last day of the year
+ (December 31st) and -306 represents the 306th to the last day of the
+ year (March 1st).
+
+ The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal
+ 44) separated list of ordinals specifying weeks of the year. Valid
+ values are 1 to 53 or -53 to -1. This corresponds to weeks according
+ to week numbering as defined in [ISO 8601]. A week is defined as a
+ seven day period, starting on the day of the week defined to be the
+ week start (see WKST). Week number one of the calendar year is the
+ first week which contains at least four (4) days in that calendar
+ year. This rule part is only valid for YEARLY rules. For example, 3
+ represents the third week of the year.
+
+ Note: Assuming a Monday week start, week 53 can only occur when
+ Thursday is January 1 or if it is a leap year and Wednesday is
+ January 1.
+
+
+
+Dawson & Stenerson Standards Track [Page 43]
+
+RFC 2445 iCalendar November 1998
+
+
+ The BYMONTH rule part specifies a COMMA character (US-ASCII decimal
+ 44) separated list of months of the year. Valid values are 1 to 12.
+
+ The WKST rule part specifies the day on which the workweek starts.
+ Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
+ when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule
+ part is specified. This is also significant when in a YEARLY RRULE
+ when a BYWEEKNO rule part is specified. The default value is MO.
+
+ The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
+ 44) separated list of values which corresponds to the nth occurrence
+ within the set of events specified by the rule. Valid values are 1 to
+ 366 or -366 to -1. It MUST only be used in conjunction with another
+ BYxxx rule part. For example "the last work day of the month" could
+ be represented as:
+
+ RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
+
+ Each BYSETPOS value can include a positive (+n) or negative (-n)
+ integer. If present, this indicates the nth occurrence of the
+ specific occurrence within the set of events specified by the rule.
+
+ If BYxxx rule part values are found which are beyond the available
+ scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
+
+ Information, not contained in the rule, necessary to determine the
+ various recurrence instance start time and dates are derived from the
+ Start Time (DTSTART) entry attribute. For example,
+ "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
+ month or a time. This information would be the same as what is
+ specified for DTSTART.
+
+ BYxxx rule parts modify the recurrence in some manner. BYxxx rule
+ parts for a period of time which is the same or greater than the
+ frequency generally reduce or limit the number of occurrences of the
+ recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the
+ number of recurrence instances from all days (if BYMONTH tag is not
+ present) to all days in January. BYxxx rule parts for a period of
+ time less than the frequency generally increase or expand the number
+ of occurrences of the recurrence. For example,
+ "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the
+ yearly recurrence set from 1 (if BYMONTH tag is not present) to 2.
+
+ If multiple BYxxx rule parts are specified, then after evaluating the
+ specified FREQ and INTERVAL rule parts, the BYxxx rule parts are
+ applied to the current set of evaluated occurrences in the following
+ order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,
+ BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
+
+
+
+Dawson & Stenerson Standards Track [Page 44]
+
+RFC 2445 iCalendar November 1998
+
+
+ Here is an example of evaluating multiple BYxxx rule parts.
+
+ DTSTART;TZID=US-Eastern:19970105T083000
+ RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
+ BYMINUTE=30
+
+ First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive
+ at "every other year". Then, "BYMONTH=1" would be applied to arrive
+ at "every January, every other year". Then, "BYDAY=SU" would be
+ applied to arrive at "every Sunday in January, every other year".
+ Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in
+ January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30"
+ would be applied to arrive at "every Sunday in January at 8:30 AM and
+ 9:30 AM, every other year". Then, lacking information from RRULE, the
+ second is derived from DTSTART, to end up in "every Sunday in January
+ at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the
+ BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were
+ missing, the appropriate minute, hour, day or month would have been
+ retrieved from the "DTSTART" property.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example: The following is a rule which specifies 10 meetings which
+ occur every other day:
+
+ FREQ=DAILY;COUNT=10;INTERVAL=2
+
+ There are other examples specified in the "RRULE" specification.
+
+4.3.11 Text
+
+ Value Name: TEXT
+
+ Purpose This value type is used to identify values that contain human
+ readable text.
+
+ Formal Definition: The character sets supported by this revision of
+ iCalendar are UTF-8 and US ASCII thereof. The applicability to other
+ character sets is for future work. The value type is defined by the
+ following notation.
+
+ text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
+ ; Folded according to description above
+
+ ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n")
+ ; \\ encodes \, \N or \n encodes newline
+ ; \; encodes ;, \, encodes ,
+
+
+
+Dawson & Stenerson Standards Track [Page 45]
+
+RFC 2445 iCalendar November 1998
+
+
+ TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B
+ %x5D-7E / NON-US-ASCII
+ ; Any character except CTLs not needed by the current
+ ; character set, DQUOTE, ";", ":", "\", ","
+
+ Note: Certain other character sets may require modification of the
+ above definitions, but this is beyond the scope of this document.
+
+ Description: If the property permits, multiple "text" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values.
+
+ The language in which the text is represented can be controlled by
+ the "LANGUAGE" property parameter.
+
+ An intentional formatted text line break MUST only be included in a
+ "TEXT" property value by representing the line break with the
+ character sequence of BACKSLASH (US-ASCII decimal 92), followed by a
+ LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER
+ N (US-ASCII decimal 78), that is "\n" or "\N".
+
+ The "TEXT" property values may also contain special characters that
+ are used to signify delimiters, such as a COMMA character for lists
+ of values or a SEMICOLON character for structured values. In order to
+ support the inclusion of these special characters in "TEXT" property
+ values, they MUST be escaped with a BACKSLASH character. A BACKSLASH
+ character (US-ASCII decimal 92) in a "TEXT" property value MUST be
+ escaped with another BACKSLASH character. A COMMA character in a
+ "TEXT" property value MUST be escaped with a BACKSLASH character
+ (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property
+ value MUST be escaped with a BACKSLASH character (US-ASCII decimal
+ 92). However, a COLON character in a "TEXT" property value SHALL NOT
+ be escaped with a BACKSLASH character.Example: A multiple line value
+ of:
+
+ Project XYZ Final Review
+ Conference Room - 3B
+ Come Prepared.
+
+ would be represented as:
+
+ Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 46]
+
+RFC 2445 iCalendar November 1998
+
+
+4.3.12 Time
+
+ Value Name: TIME
+
+ Purpose: This value type is used to identify values that contain a
+ time of day.
+
+ Formal Definition: The data type is defined by the following
+ notation:
+
+ time = time-hour time-minute time-second [time-utc]
+
+ time-hour = 2DIGIT ;00-23
+ time-minute = 2DIGIT ;00-59
+ time-second = 2DIGIT ;00-60
+ ;The "60" value is used to account for "leap" seconds.
+
+ time-utc = "Z"
+
+ Description: If the property permits, multiple "time" values are
+ specified by a COMMA character (US-ASCII decimal 44) separated list
+ of values. No additional content value encoding (i.e., BACKSLASH
+ character encoding) is defined for this value type.
+
+ The "TIME" data type is used to identify values that contain a time
+ of day. The format is based on the [ISO 8601] complete
+ representation, basic format for a time of day. The text format
+ consists of a two-digit 24-hour of the day (i.e., values 0-23), two-
+ digit minute in the hour (i.e., values 0-59), and two-digit seconds
+ in the minute (i.e., values 0-60). The seconds value of 60 MUST only
+ to be used to account for "leap" seconds. Fractions of a second are
+ not supported by this format.
+
+ In parallel to the "DATE-TIME" definition above, the "TIME" data type
+ expresses time values in three forms:
+
+ The form of time with UTC offset MUST NOT be used. For example, the
+ following is NOT VALID for a time value:
+
+ 230000-0800 ;Invalid time format
+
+ FORM #1 LOCAL TIME
+
+ The local time form is simply a time value that does not contain the
+ UTC designator nor does it reference a time zone. For example, 11:00
+ PM:
+
+ 230000
+
+
+
+Dawson & Stenerson Standards Track [Page 47]
+
+RFC 2445 iCalendar November 1998
+
+
+ Time values of this type are said to be "floating" and are not bound
+ to any time zone in particular. They are used to represent the same
+ hour, minute, and second value regardless of which time zone is
+ currently being observed. For example, an event can be defined that
+ indicates that an individual will be busy from 11:00 AM to 1:00 PM
+ every day, no matter which time zone the person is in. In these
+ cases, a local time can be specified. The recipient of an iCalendar
+ object with a property value consisting of a local time, without any
+ relative time zone information, SHOULD interpret the value as being
+ fixed to whatever time zone the ATTENDEE is in at any given moment.
+ This means that two ATTENDEEs may participate in the same event at
+ different UTC times; floating time SHOULD only be used where that is
+ reasonable behavior.
+
+ In most cases, a fixed time is desired. To properly communicate a
+ fixed time in a property value, either UTC time or local time with
+ time zone reference MUST be specified.
+
+ The use of local time in a TIME value without the TZID property
+ parameter is to be interpreted as a local time value, regardless of
+ the existence of "VTIMEZONE" calendar components in the iCalendar
+ object.
+
+ FORM #2: UTC TIME
+
+ UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z
+ suffix character (US-ASCII decimal 90), the UTC designator, appended
+ to the time value. For example, the following represents 07:00 AM
+ UTC:
+
+ 070000Z
+
+ The TZID property parameter MUST NOT be applied to TIME properties
+ whose time values are specified in UTC.
+
+ FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
+
+ The local time with reference to time zone information form is
+ identified by the use the TZID property parameter to reference the
+ appropriate time zone definition. TZID is discussed in detail in the
+ section on Time Zone.
+
+ Example: The following represents 8:30 AM in New York in Winter, five
+ hours behind UTC, in each of the three formats using the "X-
+ TIMEOFDAY" non-standard property:
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 48]
+
+RFC 2445 iCalendar November 1998
+
+
+ X-TIMEOFDAY:083000
+
+ X-TIMEOFDAY:133000Z
+
+ X-TIMEOFDAY;TZID=US-Eastern:083000
+
+4.3.13 URI
+
+ Value Name: URI
+
+ Purpose: This value type is used to identify values that contain a
+ uniform resource identifier (URI) type of reference to the property
+ value.
+
+ Formal Definition: The data type is defined by the following
+ notation:
+
+ uri = <As defined by any IETF RFC>
+
+ Description: This data type might be used to reference binary
+ information, for values that are large, or otherwise undesirable to
+ include directly in the iCalendar object.
+
+ The URI value formats in RFC 1738, RFC 2111 and any other IETF
+ registered value format can be specified.
+
+ Any IANA registered URI format can be used. These include, but are
+ not limited to, those defined in RFC 1738 and RFC 2111.
+
+ When a property parameter value is a URI value type, the URI MUST be
+ specified as a quoted-string value.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example: The following is a URI for a network file:
+
+ http://host1.com/my-report.txt
+
+4.3.14 UTC Offset
+
+ Value Name: UTC-OFFSET
+
+ Purpose: This value type is used to identify properties that contain
+ an offset from UTC to local time.
+
+ Formal Definition: The data type is defined by the following
+ notation:
+
+
+
+Dawson & Stenerson Standards Track [Page 49]
+
+RFC 2445 iCalendar November 1998
+
+
+ utc-offset = time-numzone ;As defined above in time data type
+
+ time-numzone = ("+" / "-") time-hour time-minute [time-
+ second]
+
+ Description: The PLUS SIGN character MUST be specified for positive
+ UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000"
+ are not allowed. The time-second, if present, may not be 60; if
+ absent, it defaults to zero.
+
+ No additional content value encoding (i.e., BACKSLASH character
+ encoding) is defined for this value type.
+
+ Example: The following UTC offsets are given for standard time for
+ New York (five hours behind UTC) and Geneva (one hour ahead of UTC):
+
+ -0500
+
+ +0100
+
+4.4 iCalendar Object
+
+ The Calendaring and Scheduling Core Object is a collection of
+ calendaring and scheduling information. Typically, this information
+ will consist of a single iCalendar object. However, multiple
+ iCalendar objects can be sequentially grouped together. The first
+ line and last line of the iCalendar object MUST contain a pair of
+ iCalendar object delimiter strings. The syntax for an iCalendar
+ object is as follows:
+
+ icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
+ icalbody
+ "END" ":" "VCALENDAR" CRLF)
+
+ The following is a simple example of an iCalendar object:
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//hacksw/handcal//NONSGML v1.0//EN
+ BEGIN:VEVENT
+ DTSTART:19970714T170000Z
+ DTEND:19970715T035959Z
+ SUMMARY:Bastille Day Party
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 50]
+
+RFC 2445 iCalendar November 1998
+
+
+4.5 Property
+
+ A property is the definition of an individual attribute describing a
+ calendar or a calendar component. A property takes the form defined
+ by the "contentline" notation defined in section 4.1.1.
+
+ The following is an example of a property:
+
+ DTSTART:19960415T133000Z
+
+ This memo imposes no ordering of properties within an iCalendar
+ object.
+
+ Property names, parameter names and enumerated parameter values are
+ case insensitive. For example, the property name "DUE" is the same as
+ "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same
+ as DtStart;TzID=US-Eastern:19980714T120000.
+
+4.6 Calendar Components
+
+ The body of the iCalendar object consists of a sequence of calendar
+ properties and one or more calendar components. The calendar
+ properties are attributes that apply to the calendar as a whole. The
+ calendar components are collections of properties that express a
+ particular calendar semantic. For example, the calendar component can
+ specify an event, a to-do, a journal entry, time zone information, or
+ free/busy time information, or an alarm.
+
+ The body of the iCalendar object is defined by the following
+ notation:
+
+ icalbody = calprops component
+
+ calprops = 2*(
+
+ ; 'prodid' and 'version' are both REQUIRED,
+ ; but MUST NOT occur more than once
+
+ prodid /version /
+
+ ; 'calscale' and 'method' are optional,
+ ; but MUST NOT occur more than once
+
+ calscale /
+ method /
+
+ x-prop
+
+
+
+
+Dawson & Stenerson Standards Track [Page 51]
+
+RFC 2445 iCalendar November 1998
+
+
+ )
+
+ component = 1*(eventc / todoc / journalc / freebusyc /
+ / timezonec / iana-comp / x-comp)
+
+ iana-comp = "BEGIN" ":" iana-token CRLF
+
+ 1*contentline
+
+ "END" ":" iana-token CRLF
+
+ x-comp = "BEGIN" ":" x-name CRLF
+
+ 1*contentline
+
+ "END" ":" x-name CRLF
+
+ An iCalendar object MUST include the "PRODID" and "VERSION" calendar
+ properties. In addition, it MUST include at least one calendar
+ component. Special forms of iCalendar objects are possible to publish
+ just busy time (i.e., only a "VFREEBUSY" calendar component) or time
+ zone (i.e., only a "VTIMEZONE" calendar component) information. In
+ addition, a complex iCalendar object is possible that is used to
+ capture a complete snapshot of the contents of a calendar (e.g.,
+ composite of many different calendar components). More commonly, an
+ iCalendar object will consist of just a single "VEVENT", "VTODO" or
+ "VJOURNAL" calendar component.
+
+4.6.1 Event Component
+
+ Component Name: "VEVENT"
+
+ Purpose: Provide a grouping of component properties that describe an
+ event.
+
+ Format Definition: A "VEVENT" calendar component is defined by the
+ following notation:
+
+ eventc = "BEGIN" ":" "VEVENT" CRLF
+ eventprop *alarmc
+ "END" ":" "VEVENT" CRLF
+
+ eventprop = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ class / created / description / dtstart / geo /
+
+
+
+Dawson & Stenerson Standards Track [Page 52]
+
+RFC 2445 iCalendar November 1998
+
+
+ last-mod / location / organizer / priority /
+ dtstamp / seq / status / summary / transp /
+ uid / url / recurid /
+
+ ; either 'dtend' or 'duration' may appear in
+ ; a 'eventprop', but 'dtend' and 'duration'
+ ; MUST NOT occur in the same 'eventprop'
+
+ dtend / duration /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+
+ attach / attendee / categories / comment /
+ contact / exdate / exrule / rstatus / related /
+ resources / rdate / rrule / x-prop
+
+ )
+
+ Description: A "VEVENT" calendar component is a grouping of component
+ properties, and possibly including "VALARM" calendar components, that
+ represents a scheduled amount of time on a calendar. For example, it
+ can be an activity; such as a one-hour long, department meeting from
+ 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time
+ on an individual calendar. Hence, the event will appear as an opaque
+ interval in a search for busy time. Alternately, the event can have
+ its Time Transparency set to "TRANSPARENT" in order to prevent
+ blocking of the event in searches for busy time.
+
+ The "VEVENT" is also the calendar component used to specify an
+ anniversary or daily reminder within a calendar. These events have a
+ DATE value type for the "DTSTART" property instead of the default
+ data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
+ MUST be specified as a DATE value also. The anniversary type of
+ "VEVENT" can span more than one date (i.e, "DTEND" property value is
+ set to a calendar date after the "DTSTART" property value).
+
+ The "DTSTART" property for a "VEVENT" specifies the inclusive start
+ of the event. For recurring events, it also specifies the very first
+ instance in the recurrence set. The "DTEND" property for a "VEVENT"
+ calendar component specifies the non-inclusive end of the event. For
+ cases where a "VEVENT" calendar component specifies a "DTSTART"
+ property with a DATE data type but no "DTEND" property, the events
+ non-inclusive end is the end of the calendar date specified by the
+ "DTSTART" property. For cases where a "VEVENT" calendar component
+ specifies a "DTSTART" property with a DATE-TIME data type but no
+ "DTEND" property, the event ends on the same calendar date and time
+ of day specified by the "DTSTART" property.
+
+
+
+Dawson & Stenerson Standards Track [Page 53]
+
+RFC 2445 iCalendar November 1998
+
+
+ The "VEVENT" calendar component cannot be nested within another
+ calendar component. However, "VEVENT" calendar components can be
+ related to each other or to a "VTODO" or to a "VJOURNAL" calendar
+ component with the "RELATED-TO" property.
+
+ Example: The following is an example of the "VEVENT" calendar
+ component used to represent a meeting that will also be opaque to
+ searches for busy time:
+
+ BEGIN:VEVENT
+ UID:19970901T130000Z-123401@host.com
+ DTSTAMP:19970901T1300Z
+ DTSTART:19970903T163000Z
+ DTEND:19970903T190000Z
+ SUMMARY:Annual Employee Review
+ CLASS:PRIVATE
+ CATEGORIES:BUSINESS,HUMAN RESOURCES
+ END:VEVENT
+
+ The following is an example of the "VEVENT" calendar component used
+ to represent a reminder that will not be opaque, but rather
+ transparent, to searches for busy time:
+
+ BEGIN:VEVENT
+ UID:19970901T130000Z-123402@host.com
+ DTSTAMP:19970901T1300Z
+ DTSTART:19970401T163000Z
+ DTEND:19970402T010000Z
+ SUMMARY:Laurel is in sensitivity awareness class.
+ CLASS:PUBLIC
+ CATEGORIES:BUSINESS,HUMAN RESOURCES
+ TRANSP:TRANSPARENT
+ END:VEVENT
+
+ The following is an example of the "VEVENT" calendar component used
+ to represent an anniversary that will occur annually. Since it takes
+ up no time, it will not appear as opaque in a search for busy time;
+ no matter what the value of the "TRANSP" property indicates:
+
+ BEGIN:VEVENT
+ UID:19970901T130000Z-123403@host.com
+ DTSTAMP:19970901T1300Z
+ DTSTART:19971102
+ SUMMARY:Our Blissful Anniversary
+ CLASS:CONFIDENTIAL
+ CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
+ RRULE:FREQ=YEARLY
+ END:VEVENT
+
+
+
+Dawson & Stenerson Standards Track [Page 54]
+
+RFC 2445 iCalendar November 1998
+
+
+4.6.2 To-do Component
+
+ Component Name: VTODO
+
+ Purpose: Provide a grouping of calendar properties that describe a
+ to-do.
+
+ Formal Definition: A "VTODO" calendar component is defined by the
+ following notation:
+
+ todoc = "BEGIN" ":" "VTODO" CRLF
+ todoprop *alarmc
+ "END" ":" "VTODO" CRLF
+
+ todoprop = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ class / completed / created / description / dtstamp /
+ dtstart / geo / last-mod / location / organizer /
+ percent / priority / recurid / seq / status /
+ summary / uid / url /
+
+ ; either 'due' or 'duration' may appear in
+ ; a 'todoprop', but 'due' and 'duration'
+ ; MUST NOT occur in the same 'todoprop'
+
+ due / duration /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+ attach / attendee / categories / comment / contact /
+ exdate / exrule / rstatus / related / resources /
+ rdate / rrule / x-prop
+
+ )
+
+ Description: A "VTODO" calendar component is a grouping of component
+ properties and possibly "VALARM" calendar components that represent
+ an action-item or assignment. For example, it can be used to
+ represent an item of work assigned to an individual; such as "turn in
+ travel expense today".
+
+ The "VTODO" calendar component cannot be nested within another
+ calendar component. However, "VTODO" calendar components can be
+ related to each other or to a "VTODO" or to a "VJOURNAL" calendar
+ component with the "RELATED-TO" property.
+
+
+
+Dawson & Stenerson Standards Track [Page 55]
+
+RFC 2445 iCalendar November 1998
+
+
+ A "VTODO" calendar component without the "DTSTART" and "DUE" (or
+ "DURATION") properties specifies a to-do that will be associated with
+ each successive calendar date, until it is completed.
+
+ Example: The following is an example of a "VTODO" calendar component:
+
+ BEGIN:VTODO
+ UID:19970901T130000Z-123404@host.com
+ DTSTAMP:19970901T1300Z
+ DTSTART:19970415T133000Z
+ DUE:19970416T045959Z
+ SUMMARY:1996 Income Tax Preparation
+ CLASS:CONFIDENTIAL
+ CATEGORIES:FAMILY,FINANCE
+ PRIORITY:1
+ STATUS:NEEDS-ACTION
+ END:VTODO
+
+4.6.3 Journal Component
+
+ Component Name: VJOURNAL
+
+ Purpose: Provide a grouping of component properties that describe a
+ journal entry.
+
+ Formal Definition: A "VJOURNAL" calendar component is defined by the
+ following notation:
+
+ journalc = "BEGIN" ":" "VJOURNAL" CRLF
+ jourprop
+ "END" ":" "VJOURNAL" CRLF
+
+ jourprop = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ class / created / description / dtstart / dtstamp /
+ last-mod / organizer / recurid / seq / status /
+ summary / uid / url /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+
+ attach / attendee / categories / comment /
+ contact / exdate / exrule / related / rdate /
+ rrule / rstatus / x-prop
+
+
+
+
+Dawson & Stenerson Standards Track [Page 56]
+
+RFC 2445 iCalendar November 1998
+
+
+ )
+
+ Description: A "VJOURNAL" calendar component is a grouping of
+ component properties that represent one or more descriptive text
+ notes associated with a particular calendar date. The "DTSTART"
+ property is used to specify the calendar date that the journal entry
+ is associated with. Generally, it will have a DATE value data type,
+ but it can also be used to specify a DATE-TIME value data type.
+ Examples of a journal entry include a daily record of a legislative
+ body or a journal entry of individual telephone contacts for the day
+ or an ordered list of accomplishments for the day. The "VJOURNAL"
+ calendar component can also be used to associate a document with a
+ calendar date.
+
+ The "VJOURNAL" calendar component does not take up time on a
+ calendar. Hence, it does not play a role in free or busy time
+ searches - - it is as though it has a time transparency value of
+ TRANSPARENT. It is transparent to any such searches.
+
+ The "VJOURNAL" calendar component cannot be nested within another
+ calendar component. However, "VJOURNAL" calendar components can be
+ related to each other or to a "VEVENT" or to a "VTODO" calendar
+ component, with the "RELATED-TO" property.
+
+ Example: The following is an example of the "VJOURNAL" calendar
+ component:
+
+ BEGIN:VJOURNAL
+ UID:19970901T130000Z-123405@host.com
+ DTSTAMP:19970901T1300Z
+ DTSTART;VALUE=DATE:19970317
+ SUMMARY:Staff meeting minutes
+ DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
+ and Bob. Aurora project plans were reviewed. There is currently
+ no budget reserves for this project. Lisa will escalate to
+ management. Next meeting on Tuesday.\n
+ 2. Telephone Conference: ABC Corp. sales representative called
+ to discuss new printer. Promised to get us a demo by Friday.\n
+ 3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
+ Is looking into a loaner car. 654-2323 (tel).
+ END:VJOURNAL
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 57]
+
+RFC 2445 iCalendar November 1998
+
+
+4.6.4 Free/Busy Component
+
+ Component Name: VFREEBUSY
+
+ Purpose: Provide a grouping of component properties that describe
+ either a request for free/busy time, describe a response to a request
+ for free/busy time or describe a published set of busy time.
+
+ Formal Definition: A "VFREEBUSY" calendar component is defined by the
+ following notation:
+
+ freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
+ fbprop
+ "END" ":" "VFREEBUSY" CRLF
+
+ fbprop = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ contact / dtstart / dtend / duration / dtstamp /
+ organizer / uid / url /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+
+ attendee / comment / freebusy / rstatus / x-prop
+
+ )
+
+ Description: A "VFREEBUSY" calendar component is a grouping of
+ component properties that represents either a request for, a reply to
+ a request for free or busy time information or a published set of
+ busy time information.
+
+ When used to request free/busy time information, the "ATTENDEE"
+ property specifies the calendar users whose free/busy time is being
+ requested; the "ORGANIZER" property specifies the calendar user who
+ is requesting the free/busy time; the "DTSTART" and "DTEND"
+ properties specify the window of time for which the free/busy time is
+ being requested; the "UID" and "DTSTAMP" properties are specified to
+ assist in proper sequencing of multiple free/busy time requests.
+
+ When used to reply to a request for free/busy time, the "ATTENDEE"
+ property specifies the calendar user responding to the free/busy time
+ request; the "ORGANIZER" property specifies the calendar user that
+ originally requested the free/busy time; the "FREEBUSY" property
+ specifies the free/busy time information (if it exists); and the
+
+
+
+Dawson & Stenerson Standards Track [Page 58]
+
+RFC 2445 iCalendar November 1998
+
+
+ "UID" and "DTSTAMP" properties are specified to assist in proper
+ sequencing of multiple free/busy time replies.
+
+ When used to publish busy time, the "ORGANIZER" property specifies
+ the calendar user associated with the published busy time; the
+ "DTSTART" and "DTEND" properties specify an inclusive time window
+ that surrounds the busy time information; the "FREEBUSY" property
+ specifies the published busy time information; and the "DTSTAMP"
+ property specifies the date/time that iCalendar object was created.
+
+ The "VFREEBUSY" calendar component cannot be nested within another
+ calendar component. Multiple "VFREEBUSY" calendar components can be
+ specified within an iCalendar object. This permits the grouping of
+ Free/Busy information into logical collections, such as monthly
+ groups of busy time information.
+
+ The "VFREEBUSY" calendar component is intended for use in iCalendar
+ object methods involving requests for free time, requests for busy
+ time, requests for both free and busy, and the associated replies.
+
+ Free/Busy information is represented with the "FREEBUSY" property.
+ This property provides a terse representation of time periods. One or
+ more "FREEBUSY" properties can be specified in the "VFREEBUSY"
+ calendar component.
+
+ When present in a "VFREEBUSY" calendar component, the "DTSTART" and
+ "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
+ properties. In a free time request, these properties can be used in
+ combination with the "DURATION" property to represent a request for a
+ duration of free time within a specified window of time.
+
+ The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are
+ not permitted within a "VFREEBUSY" calendar component. Any recurring
+ events are resolved into their individual busy time periods using the
+ "FREEBUSY" property.
+
+ Example: The following is an example of a "VFREEBUSY" calendar
+ component used to request free or busy time information:
+
+ BEGIN:VFREEBUSY
+ ORGANIZER:MAILTO:jane_doe@host1.com
+ ATTENDEE:MAILTO:john_public@host2.com
+ DTSTART:19971015T050000Z
+ DTEND:19971016T050000Z
+ DTSTAMP:19970901T083000Z
+ END:VFREEBUSY
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 59]
+
+RFC 2445 iCalendar November 1998
+
+
+ The following is an example of a "VFREEBUSY" calendar component used
+ to reply to the request with busy time information:
+
+ BEGIN:VFREEBUSY
+ ORGANIZER:MAILTO:jane_doe@host1.com
+ ATTENDEE:MAILTO:john_public@host2.com
+ DTSTAMP:19970901T100000Z
+ FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
+ 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
+ URL:http://host2.com/pub/busy/jpublic-01.ifb
+ COMMENT:This iCalendar file contains busy time information for
+ the next three months.
+ END:VFREEBUSY
+
+ The following is an example of a "VFREEBUSY" calendar component used
+ to publish busy time information.
+
+ BEGIN:VFREEBUSY
+ ORGANIZER: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
+
+4.6.5 Time Zone Component
+
+ Component Name: VTIMEZONE
+
+ Purpose: Provide a grouping of component properties that defines a
+ time zone.
+
+ Formal Definition: A "VTIMEZONE" calendar component is defined by the
+ following notation:
+
+ timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
+
+ 2*(
+
+ ; 'tzid' is required, but MUST NOT occur more
+ ; than once
+
+ tzid /
+
+ ; 'last-mod' and 'tzurl' are optional,
+ but MUST NOT occur more than once
+
+
+
+Dawson & Stenerson Standards Track [Page 60]
+
+RFC 2445 iCalendar November 1998
+
+
+ last-mod / tzurl /
+
+ ; one of 'standardc' or 'daylightc' MUST occur
+ ..; and each MAY occur more than once.
+
+ standardc / daylightc /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ x-prop
+
+ )
+
+ "END" ":" "VTIMEZONE" CRLF
+
+ standardc = "BEGIN" ":" "STANDARD" CRLF
+
+ tzprop
+
+ "END" ":" "STANDARD" CRLF
+
+ daylightc = "BEGIN" ":" "DAYLIGHT" CRLF
+
+ tzprop
+
+ "END" ":" "DAYLIGHT" CRLF
+
+ tzprop = 3*(
+
+ ; the following are each REQUIRED,
+ ; but MUST NOT occur more than once
+
+ dtstart / tzoffsetto / tzoffsetfrom /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+
+ comment / rdate / rrule / tzname / x-prop
+
+ )
+
+ Description: A time zone is unambiguously defined by the set of time
+ measurement rules determined by the governing body for a given
+ geographic area. These rules describe at a minimum the base offset
+ from UTC for the time zone, often referred to as the Standard Time
+ offset. Many locations adjust their Standard Time forward or backward
+ by one hour, in order to accommodate seasonal changes in number of
+
+
+
+Dawson & Stenerson Standards Track [Page 61]
+
+RFC 2445 iCalendar November 1998
+
+
+ daylight hours, often referred to as Daylight Saving Time. Some
+ locations adjust their time by a fraction of an hour. Standard Time
+ is also known as Winter Time. Daylight Saving Time is also known as
+ Advanced Time, Summer Time, or Legal Time in certain countries. The
+ following table shows the changes in time zone rules in effect for
+ New York City starting from 1967. Each line represents a description
+ or rule for a particular observance.
+
+ Effective Observance Rule
+
+ Date (Date/Time) Offset Abbreviation
+
+ 1967-* last Sun in Oct, 02:00 -0500 EST
+
+ 1967-1973 last Sun in Apr, 02:00 -0400 EDT
+
+ 1974-1974 Jan 6, 02:00 -0400 EDT
+
+ 1975-1975 Feb 23, 02:00 -0400 EDT
+
+ 1976-1986 last Sun in Apr, 02:00 -0400 EDT
+
+ 1987-* first Sun in Apr, 02:00 -0400 EDT
+
+ Note: The specification of a global time zone registry is not
+ addressed by this document and is left for future study.
+ However, implementers may find the Olson time zone database [TZ]
+ a useful reference. It is an informal, public-domain collection
+ of time zone information, which is currently being maintained by
+ volunteer Internet participants, and is used in several
+ operating systems. This database contains current and historical
+ time zone information for a wide variety of locations around the
+ globe; it provides a time zone identifier for every unique time
+ zone rule set in actual use since 1970, with historical data
+ going back to the introduction of standard time.
+
+ Interoperability between two calendaring and scheduling applications,
+ especially for recurring events, to-dos or journal entries, is
+ dependent on the ability to capture and convey date and time
+ information in an unambiguous format. The specification of current
+ time zone information is integral to this behavior.
+
+ If present, the "VTIMEZONE" calendar component defines the set of
+ Standard Time and Daylight Saving Time observances (or rules) for a
+ particular time zone for a given interval of time. The "VTIMEZONE"
+ calendar component cannot be nested within other calendar components.
+ Multiple "VTIMEZONE" calendar components can exist in an iCalendar
+ object. In this situation, each "VTIMEZONE" MUST represent a unique
+
+
+
+Dawson & Stenerson Standards Track [Page 62]
+
+RFC 2445 iCalendar November 1998
+
+
+ time zone definition. This is necessary for some classes of events,
+ such as airline flights, that start in one time zone and end in
+ another.
+
+ The "VTIMEZONE" calendar component MUST be present if the iCalendar
+ object contains an RRULE that generates dates on both sides of a time
+ zone shift (e.g. both in Standard Time and Daylight Saving Time)
+ unless the iCalendar object intends to convey a floating time (See
+ the section "4.1.10.11 Time" for proper interpretation of floating
+ time). It can be present if the iCalendar object does not contain
+ such a RRULE. In addition, if a RRULE is present, there MUST be valid
+ time zone information for all recurrence instances.
+
+ The "VTIMEZONE" calendar component MUST include the "TZID" property
+ and at least one definition of a standard or daylight component. The
+ standard or daylight component MUST include the "DTSTART",
+ "TZOFFSETFROM" and "TZOFFSETTO" properties.
+
+ An individual "VTIMEZONE" calendar component MUST be specified for
+ each unique "TZID" parameter value specified in the iCalendar object.
+
+ Each "VTIMEZONE" calendar component consists of a collection of one
+ or more sub-components that describe the rule for a particular
+ observance (either a Standard Time or a Daylight Saving Time
+ observance). The "STANDARD" sub-component consists of a collection of
+ properties that describe Standard Time. The "DAYLIGHT" sub-component
+ consists of a collection of properties that describe Daylight Saving
+ Time. In general this collection of properties consists of:
+
+ - the first onset date-time for the observance
+
+ - the last onset date-time for the observance, if a last onset
+ is known.
+
+ - the offset to be applied for the observance
+
+ - a rule that describes the day and time when the observance
+ takes effect
+
+ - an optional name for the observance
+
+ For a given time zone, there may be multiple unique definitions of
+ the observances over a period of time. Each observance is described
+ using either a "STANDARD" or "DAYLIGHT" sub-component. The collection
+ of these sub-components is used to describe the time zone for a given
+ period of time. The offset to apply at any given time is found by
+ locating the observance that has the last onset date and time before
+ the time in question, and using the offset value from that
+
+
+
+Dawson & Stenerson Standards Track [Page 63]
+
+RFC 2445 iCalendar November 1998
+
+
+ observance.
+
+ The top-level properties in a "VTIMEZONE" calendar component are:
+
+ The mandatory "TZID" property is a text value that uniquely
+ identifies the VTIMZONE calendar component within the scope of an
+ iCalendar object.
+
+ The optional "LAST-MODIFIED" property is a UTC value that specifies
+ the date and time that this time zone definition was last updated.
+
+ The optional "TZURL" property is url value that points to a published
+ VTIMEZONE definition. TZURL SHOULD refer to a resource that is
+ accessible by anyone who might need to interpret the object. This
+ SHOULD NOT normally be a file: URL or other URL that is not widely-
+ accessible.
+
+ The collection of properties that are used to define the STANDARD and
+ DAYLIGHT sub-components include:
+
+ The mandatory "DTSTART" property gives the effective onset date and
+ local time for the time zone sub-component definition. "DTSTART" in
+ this usage MUST be specified as a local DATE-TIME value.
+
+ The mandatory "TZOFFSETFROM" property gives the UTC offset which is
+ in use when the onset of this time zone observance begins.
+ "TZOFFSETFROM" is combined with "DTSTART" to define the effective
+ onset for the time zone sub-component definition. For example, the
+ following represents the time at which the observance of Standard
+ Time took effect in Fall 1967 for New York City:
+
+ DTSTART:19671029T020000
+
+ TZOFFSETFROM:-0400
+
+ The mandatory "TZOFFSETTO " property gives the UTC offset for the
+ time zone sub-component (Standard Time or Daylight Saving Time) when
+ this observance is in use.
+
+ The optional "TZNAME" property is the customary name for the time
+ zone. It may be specified multiple times, to allow for specifying
+ multiple language variants of the time zone names. This could be used
+ for displaying dates.
+
+ If specified, the onset for the observance defined by the time zone
+ sub-component is defined by either the "RRULE" or "RDATE" property.
+ If neither is specified, only one sub-component can be specified in
+ the "VTIMEZONE" calendar component and it is assumed that the single
+
+
+
+Dawson & Stenerson Standards Track [Page 64]
+
+RFC 2445 iCalendar November 1998
+
+
+ observance specified is always in effect.
+
+ The "RRULE" property defines the recurrence rule for the onset of the
+ observance defined by this time zone sub-component. Some specific
+ requirements for the usage of RRULE for this purpose include:
+
+ - If observance is known to have an effective end date, the
+ "UNTIL" recurrence rule parameter MUST be used to specify the
+ last valid onset of this observance (i.e., the UNTIL date-time
+ will be equal to the last instance generated by the recurrence
+ pattern). It MUST be specified in UTC time.
+
+ - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
+ when generating the onset date-time values (instances) from the
+ RRULE.
+
+ Alternatively, the "RDATE" property can be used to define the onset
+ of the observance by giving the individual onset date and times.
+ "RDATE" in this usage MUST be specified as a local DATE-TIME value in
+ UTC time.
+
+ The optional "COMMENT" property is also allowed for descriptive
+ explanatory text.
+
+ Example: The following are examples of the "VTIMEZONE" calendar
+ component:
+
+ This is an example showing time zone information for the Eastern
+ United States using "RDATE" property. Note that this is only suitable
+ for a recurring event that starts on or later than April 6, 1997 at
+ 03:00:00 EDT (i.e., the earliest effective transition date and time)
+ and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid
+ date and time for EST in this scenario). For example, this can be
+ used for a recurring event that occurs every Friday, 8am-9:00 AM,
+ starting June 1, 1997, ending December 31, 1997.
+
+ BEGIN:VTIMEZONE
+ TZID:US-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ BEGIN:STANDARD
+ DTSTART:19971026T020000
+ RDATE:19971026T020000
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:EST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19971026T020000
+
+
+
+Dawson & Stenerson Standards Track [Page 65]
+
+RFC 2445 iCalendar November 1998
+
+
+ RDATE:19970406T020000
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:EDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+
+ This is a simple example showing the current time zone rules for the
+ Eastern United States using a RRULE recurrence pattern. Note that
+ there is no effective end date to either of the Standard Time or
+ Daylight Time rules. This information would be valid for a recurring
+ event starting today and continuing indefinitely.
+
+ BEGIN:VTIMEZONE
+ TZID:US-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ TZURL:http://zones.stds_r_us.net/tz/US-Eastern
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:EST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:EDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+
+ This is an example showing a fictitious set of rules for the Eastern
+ United States, where the Daylight Time rule has an effective end date
+ (i.e., after that date, Daylight Time is no longer observed).
+
+ BEGIN:VTIMEZONE
+ TZID:US--Fictitious-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:EST
+ END:STANDARD
+
+
+
+
+Dawson & Stenerson Standards Track [Page 66]
+
+RFC 2445 iCalendar November 1998
+
+
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:EDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+
+ This is an example showing a fictitious set of rules for the Eastern
+ United States, where the first Daylight Time rule has an effective
+ end date. There is a second Daylight Time rule that picks up where
+ the other left off.
+
+ BEGIN:VTIMEZONE
+ TZID:US--Fictitious-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:EST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:EDT
+ END:DAYLIGHT
+ BEGIN:DAYLIGHT
+ DTSTART:19990424T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:EDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+
+4.6.6 Alarm Component
+
+ Component Name: VALARM
+
+ Purpose: Provide a grouping of component properties that define an
+ alarm.
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 67]
+
+RFC 2445 iCalendar November 1998
+
+
+ Formal Definition: A "VALARM" calendar component is defined by the
+ following notation:
+
+ alarmc = "BEGIN" ":" "VALARM" CRLF
+ (audioprop / dispprop / emailprop / procprop)
+ "END" ":" "VALARM" CRLF
+
+ audioprop = 2*(
+
+ ; 'action' and 'trigger' are both REQUIRED,
+ ; but MUST NOT occur more than once
+
+ action / trigger /
+
+ ; 'duration' and 'repeat' are both optional,
+ ; and MUST NOT occur more than once each,
+ ; but if one occurs, so MUST the other
+
+ duration / repeat /
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ attach /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ x-prop
+
+ )
+
+
+
+ dispprop = 3*(
+
+ ; the following are all REQUIRED,
+ ; but MUST NOT occur more than once
+
+ action / description / trigger /
+
+ ; 'duration' and 'repeat' are both optional,
+ ; and MUST NOT occur more than once each,
+ ; but if one occurs, so MUST the other
+
+ duration / repeat /
+
+ ; the following is optional,
+
+
+
+Dawson & Stenerson Standards Track [Page 68]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; and MAY occur more than once
+
+ *x-prop
+
+ )
+
+
+
+ emailprop = 5*(
+
+ ; the following are all REQUIRED,
+ ; but MUST NOT occur more than once
+
+ action / description / trigger / summary
+
+ ; the following is REQUIRED,
+ ; and MAY occur more than once
+
+ attendee /
+
+ ; 'duration' and 'repeat' are both optional,
+ ; and MUST NOT occur more than once each,
+ ; but if one occurs, so MUST the other
+
+ duration / repeat /
+
+ ; the following are optional,
+ ; and MAY occur more than once
+
+ attach / x-prop
+
+ )
+
+
+
+ procprop = 3*(
+
+ ; the following are all REQUIRED,
+ ; but MUST NOT occur more than once
+
+ action / attach / trigger /
+
+ ; 'duration' and 'repeat' are both optional,
+ ; and MUST NOT occur more than once each,
+ ; but if one occurs, so MUST the other
+
+ duration / repeat /
+
+
+
+
+Dawson & Stenerson Standards Track [Page 69]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; 'description' is optional,
+ ; and MUST NOT occur more than once
+
+ description /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ x-prop
+
+ )
+
+ Description: A "VALARM" calendar component is a grouping of component
+ properties that is a reminder or alarm for an event or a to-do. For
+ example, it may be used to define a reminder for a pending event or
+ an overdue to-do.
+
+ The "VALARM" calendar component MUST include the "ACTION" and
+ "TRIGGER" properties. The "ACTION" property further constrains the
+ "VALARM" calendar component in the following ways:
+
+ When the action is "AUDIO", the alarm can also include one and only
+ one "ATTACH" property, which MUST point to a sound resource, which is
+ rendered when the alarm is triggered.
+
+ When the action is "DISPLAY", the alarm MUST also include a
+ "DESCRIPTION" property, which contains the text to be displayed when
+ the alarm is triggered.
+
+ When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
+ property, which contains the text to be used as the message body, a
+ "SUMMARY" property, which contains the text to be used as the message
+ subject, and one or more "ATTENDEE" properties, which contain the
+ email address of attendees to receive the message. It can also
+ include one or more "ATTACH" properties, which are intended to be
+ sent as message attachments. When the alarm is triggered, the email
+ message is sent.
+
+ When the action is "PROCEDURE", the alarm MUST include one and only
+ one "ATTACH" property, which MUST point to a procedure resource,
+ which is invoked when the alarm is triggered.
+
+ The "VALARM" calendar component MUST only appear within either a
+ "VEVENT" or "VTODO" calendar component. "VALARM" calendar components
+ cannot be nested. Multiple mutually independent "VALARM" calendar
+ components can be specified for a single "VEVENT" or "VTODO" calendar
+ component.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 70]
+
+RFC 2445 iCalendar November 1998
+
+
+ The "TRIGGER" property specifies when the alarm will be triggered.
+ The "TRIGGER" property specifies a duration prior to the start of an
+ event or a to-do. The "TRIGGER" edge may be explicitly set to be
+ relative to the "START" or "END" of the event or to-do with the
+ "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property
+ value type can alternatively be set to an absolute calendar date and
+ time of day value.
+
+ In an alarm set to trigger on the "START" of an event or to-do, the
+ "DTSTART" property MUST be present in the associated event or to-do.
+ In an alarm in a "VEVENT" calendar component set to trigger on the
+ "END" of the event, either the "DTEND" property MUST be present, or
+ the "DTSTART" and "DURATION" properties MUST both be present. In an
+ alarm in a "VTODO" calendar component set to trigger on the "END" of
+ the to-do, either the "DUE" property MUST be present, or the
+ "DTSTART" and "DURATION" properties MUST both be present.
+
+ The alarm can be defined such that it triggers repeatedly. A
+ definition of an alarm with a repeating trigger MUST include both the
+ "DURATION" and "REPEAT" properties. The "DURATION" property specifies
+ the delay period, after which the alarm will repeat. The "REPEAT"
+ property specifies the number of additional repetitions that the
+ alarm will triggered. This repitition count is in addition to the
+ initial triggering of the alarm. Both of these properties MUST be
+ present in order to specify a repeating alarm. If one of these two
+ properties is absent, then the alarm will not repeat beyond the
+ initial trigger.
+
+ The "ACTION" property is used within the "VALARM" calendar component
+ to specify the type of action invoked when the alarm is triggered.
+ The "VALARM" properties provide enough information for a specific
+ action to be invoked. It is typically the responsibility of a
+ "Calendar User Agent" (CUA) to deliver the alarm in the specified
+ fashion. An "ACTION" property value of AUDIO specifies an alarm that
+ causes a sound to be played to alert the user; DISPLAY specifies an
+ alarm that causes a text message to be displayed to the user; EMAIL
+ specifies an alarm that causes an electronic email message to be
+ delivered to one or more email addresses; and PROCEDURE specifies an
+ alarm that causes a procedure to be executed. The "ACTION" property
+ MUST specify one and only one of these values.
+
+ In an AUDIO alarm, if the optional "ATTACH" property is included, it
+ MUST specify an audio sound resource. The intention is that the sound
+ will be played as the alarm effect. If an "ATTACH" property is
+ specified that does not refer to a sound resource, or if the
+ specified sound resource cannot be rendered (because its format is
+ unsupported, or because it cannot be retrieved), then the CUA or
+ other entity responsible for playing the sound may choose a fallback
+
+
+
+Dawson & Stenerson Standards Track [Page 71]
+
+RFC 2445 iCalendar November 1998
+
+
+ action, such as playing a built-in default sound, or playing no sound
+ at all.
+
+ In a DISPLAY alarm, the intended alarm effect is for the text value
+ of the "DESCRIPTION" property to be displayed to the user.
+
+ In an EMAIL alarm, the intended alarm effect is for an email message
+ to be composed and delivered to all the addresses specified by the
+ "ATTENDEE" properties in the "VALARM" calendar component. The
+ "DESCRIPTION" property of the "VALARM" calendar component MUST be
+ used as the body text of the message, and the "SUMMARY" property MUST
+ be used as the subject text. Any "ATTACH" properties in the "VALARM"
+ calendar component SHOULD be sent as attachments to the message.
+
+ In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar
+ component MUST specify a procedure or program that is intended to be
+ invoked as the alarm effect. If the procedure or program is in a
+ format that cannot be rendered, then no procedure alarm will be
+ invoked. If the "DESCRIPTION" property is present, its value
+ specifies the argument string to be passed to the procedure or
+ program. "Calendar User Agents" that receive an iCalendar object with
+ this category of alarm, can disable or allow the "Calendar User" to
+ disable, or otherwise ignore this type of alarm. While a very useful
+ alarm capability, the PROCEDURE type of alarm SHOULD be treated by
+ the "Calendar User Agent" as a potential security risk.
+
+ Example: The following example is for a "VALARM" calendar component
+ that specifies an audio alarm that will sound at a precise time and
+ repeat 4 more times at 15 minute intervals:
+
+ BEGIN:VALARM
+ TRIGGER;VALUE=DATE-TIME:19970317T133000Z
+ REPEAT:4
+ DURATION:PT15M
+ ACTION:AUDIO
+ ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
+ END:VALARM
+
+ The following example is for a "VALARM" calendar component that
+ specifies a display alarm that will trigger 30 minutes before the
+ scheduled start of the event or the due date/time of the to-do it is
+ associated with and will repeat 2 more times at 15 minute intervals:
+
+ BEGIN:VALARM
+ TRIGGER:-PT30M
+ REPEAT:2
+ DURATION:PT15M
+ ACTION:DISPLAY
+
+
+
+Dawson & Stenerson Standards Track [Page 72]
+
+RFC 2445 iCalendar November 1998
+
+
+ DESCRIPTION:Breakfast meeting with executive\n
+ team at 8:30 AM EST.
+ END:VALARM
+
+ The following example is for a "VALARM" calendar component that
+ specifies an email alarm that will trigger 2 days before the
+ scheduled due date/time of a to-do it is associated with. It does not
+ repeat. The email has a subject, body and attachment link.
+
+ BEGIN:VALARM
+ TRIGGER:-P2D
+ ACTION:EMAIL
+ ATTENDEE:MAILTO:john_doe@host.com
+ SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
+ DESCRIPTION:A draft agenda needs to be sent out to the attendees
+ to the weekly managers meeting (MGR-LIST). Attached is a
+ pointer the document template for the agenda file.
+ ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen
+ da.doc
+ END:VALARM
+
+ The following example is for a "VALARM" calendar component that
+ specifies a procedural alarm that will trigger at a precise date/time
+ and will repeat 23 more times at one hour intervals. The alarm will
+ invoke a procedure file.
+
+ BEGIN:VALARM
+ TRIGGER;VALUE=DATE-TIME:19980101T050000Z
+ REPEAT:23
+ DURATION:PT1H
+ ACTION:PROCEDURE
+ ATTACH;FMTTYPE=application/binary:ftp://host.com/novo-
+ procs/felizano.exe
+ END:VALARM
+
+4.7 Calendar Properties
+
+ The Calendar Properties are attributes that apply to the iCalendar
+ object, as a whole. These properties do not appear within a calendar
+ component. They SHOULD be specified after the "BEGIN:VCALENDAR"
+ property and prior to any calendar component.
+
+4.7.1 Calendar Scale
+
+ Property Name: CALSCALE
+
+ Purpose: This property defines the calendar scale used for the
+ calendar information specified in the iCalendar object.
+
+
+
+Dawson & Stenerson Standards Track [Page 73]
+
+RFC 2445 iCalendar November 1998
+
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: Property can be specified in an iCalendar object. The
+ default value is "GREGORIAN".
+
+ Description: This memo is based on the Gregorian calendar scale. The
+ Gregorian calendar scale is assumed if this property is not specified
+ in the iCalendar object. It is expected that other calendar scales
+ will be defined in other specifications or by future versions of this
+ memo.
+
+ Format Definition: The property is defined by the following notation:
+
+ calscale = "CALSCALE" calparam ":" calvalue CRLF
+
+ calparam = *(";" xparam)
+
+ calvalue = "GREGORIAN" / iana-token
+
+ Example: The following is an example of this property:
+
+ CALSCALE:GREGORIAN
+
+4.7.2 Method
+
+ Property Name: METHOD
+
+ Purpose: This property defines the iCalendar object method associated
+ with the calendar object.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified in an iCalendar object.
+
+ Description: When used in a MIME message entity, the value of this
+ property MUST be the same as the Content-Type "method" parameter
+ value. This property can only appear once within the iCalendar
+ object. If either the "METHOD" property or the Content-Type "method"
+ parameter is specified, then the other MUST also be specified.
+
+ No methods are defined by this specification. This is the subject of
+ other specifications, such as the iCalendar Transport-independent
+
+
+
+Dawson & Stenerson Standards Track [Page 74]
+
+RFC 2445 iCalendar November 1998
+
+
+ Interoperability Protocol (iTIP) defined by [ITIP].
+
+ If this property is not present in the iCalendar object, then a
+ scheduling transaction MUST NOT be assumed. In such cases, the
+ iCalendar object is merely being used to transport a snapshot of some
+ calendar information; without the intention of conveying a scheduling
+ semantic.
+
+ Format Definition: The property is defined by the following notation:
+
+ method = "METHOD" metparam ":" metvalue CRLF
+
+ metparam = *(";" xparam)
+
+ metvalue = iana-token
+
+ Example: The following is a hypothetical example of this property to
+ convey that the iCalendar object is a request for a meeting:
+
+ METHOD:REQUEST
+
+4.7.3 Product Identifier
+
+ Property Name: PRODID
+
+ Purpose: This property specifies the identifier for the product that
+ created the iCalendar object.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property MUST be specified once in an iCalendar
+ object.
+
+ Description: The vendor of the implementation SHOULD assure that this
+ is a globally unique identifier; using some technique such as an FPI
+ value, as defined in [ISO 9070].
+
+ This property SHOULD not be used to alter the interpretation of an
+ iCalendar object beyond the semantics specified in this memo. For
+ example, it is not to be used to further the understanding of non-
+ standard properties.
+
+ Format Definition: The property is defined by the following notation:
+
+ prodid = "PRODID" pidparam ":" pidvalue CRLF
+
+
+
+Dawson & Stenerson Standards Track [Page 75]
+
+RFC 2445 iCalendar November 1998
+
+
+ pidparam = *(";" xparam)
+
+ pidvalue = text
+ ;Any text that describes the product and version
+ ;and that is generally assured of being unique.
+
+ Example: The following is an example of this property. It does not
+ imply that English is the default language.
+
+ PRODID:-//ABC Corporation//NONSGML My Product//EN
+
+4.7.4 Version
+
+ Property Name: VERSION
+
+ Purpose: This property specifies the identifier corresponding to the
+ highest version number or the minimum and maximum range of the
+ iCalendar specification that is required in order to interpret the
+ iCalendar object.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property MUST be specified by an iCalendar object,
+ but MUST only be specified once.
+
+ Description: A value of "2.0" corresponds to this memo.
+
+ Format Definition: The property is defined by the following notation:
+
+ version = "VERSION" verparam ":" vervalue CRLF
+
+ verparam = *(";" xparam)
+
+ vervalue = "2.0" ;This memo
+ / maxver
+ / (minver ";" maxver)
+
+ minver = <A IANA registered iCalendar version identifier>
+ ;Minimum iCalendar version needed to parse the iCalendar object
+
+ maxver = <A IANA registered iCalendar version identifier>
+ ;Maximum iCalendar version needed to parse the iCalendar object
+
+ Example: The following is an example of this property:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 76]
+
+RFC 2445 iCalendar November 1998
+
+
+ VERSION:2.0
+
+4.8 Component Properties
+
+ The following properties can appear within calendar components, as
+ specified by each component property definition.
+
+4.8.1 Descriptive Component Properties
+
+ The following properties specify descriptive information about
+ calendar components.
+
+4.8.1.1 Attachment
+
+ Property Name: ATTACH
+
+ Purpose: The property provides the capability to associate a document
+ object with a calendar component.
+
+ Value Type: The default value type for this property is URI. The
+ value type can also be set to BINARY to indicate inline binary
+ encoded content information.
+
+ Property Parameters: Non-standard, inline encoding, format type and
+ value data type property parameters can be specified on this
+ property.
+
+ Conformance: The property can be specified in a "VEVENT", "VTODO",
+ "VJOURNAL" or "VALARM" calendar components.
+
+ Description: The property can be specified within "VEVENT", "VTODO",
+ "VJOURNAL", or "VALARM" calendar components. This property can be
+ specified multiple times within an iCalendar object.
+
+ Format Definition: The property is defined by the following notation:
+
+ attach = "ATTACH" attparam ":" uri CRLF
+
+ attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
+ ";" "VALUE" "=" "BINARY" ":" binary
+
+ attparam = *(
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ (";" fmttypeparam) /
+
+
+
+
+Dawson & Stenerson Standards Track [Page 77]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following are examples of this property:
+
+ ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com
+
+ ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
+ reports/r-960812.ps
+
+4.8.1.2 Categories
+
+ Property Name: CATEGORIES
+
+ Purpose: This property defines the categories for a calendar
+ component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard and language property parameters
+ can be specified on this property.
+
+ Conformance: The property can be specified within "VEVENT", "VTODO"
+ or "VJOURNAL" calendar components.
+
+ Description: This property is used to specify categories or subtypes
+ of the calendar component. The categories are useful in searching for
+ a calendar component of a particular type and category. Within the
+ "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one
+ category can be specified as a list of categories separated by the
+ COMMA character (US-ASCII decimal 44).
+
+ Format Definition: The property is defined by the following notation:
+
+ categories = "CATEGORIES" catparam ":" text *("," text)
+ CRLF
+
+ catparam = *(
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ (";" languageparam ) /
+
+
+
+
+Dawson & Stenerson Standards Track [Page 78]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following are examples of this property:
+
+ CATEGORIES:APPOINTMENT,EDUCATION
+
+ CATEGORIES:MEETING
+
+4.8.1.3 Classification
+
+ Property Name: CLASS
+
+ Purpose: This property defines the access classification for a
+ calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified once in a "VEVENT",
+ "VTODO" or "VJOURNAL" calendar components.
+
+ Description: An access classification is only one component of the
+ general security system within a calendar application. It provides a
+ method of capturing the scope of the access the calendar owner
+ intends for information within an individual calendar entry. The
+ access classification of an individual iCalendar component is useful
+ when measured along with the other security components of a calendar
+ system (e.g., calendar user authentication, authorization, access
+ rights, access role, etc.). Hence, the semantics of the individual
+ access classifications cannot be completely defined by this memo
+ alone. Additionally, due to the "blind" nature of most exchange
+ processes using this memo, these access classifications cannot serve
+ as an enforcement statement for a system receiving an iCalendar
+ object. Rather, they provide a method for capturing the intention of
+ the calendar owner for the access to the calendar component.
+
+ Format Definition: The property is defined by the following notation:
+
+ class = "CLASS" classparam ":" classvalue CRLF
+
+ classparam = *(";" xparam)
+
+
+
+Dawson & Stenerson Standards Track [Page 79]
+
+RFC 2445 iCalendar November 1998
+
+
+ classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
+ / x-name
+ ;Default is PUBLIC
+
+ Example: The following is an example of this property:
+
+ CLASS:PUBLIC
+
+4.8.1.4 Comment
+
+ Property Name: COMMENT
+
+ Purpose: This property specifies non-processing information intended
+ to provide a comment to the calendar user.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: This property can be specified in "VEVENT", "VTODO",
+ "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
+
+ Description: The property can be specified multiple times.
+
+ Format Definition: The property is defined by the following notation:
+
+ comment = "COMMENT" commparam ":" text CRLF
+
+ commparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following is an example of this property:
+
+ COMMENT:The meeting really needs to include both ourselves
+ and the customer. We can't hold this meeting without them.
+ As a matter of fact\, the venue for the meeting ought to be at
+
+
+
+Dawson & Stenerson Standards Track [Page 80]
+
+RFC 2445 iCalendar November 1998
+
+
+ their site. - - John
+
+ The data type for this property is TEXT.
+
+4.8.1.5 Description
+
+ Property Name: DESCRIPTION
+
+ Purpose: This property provides a more complete description of the
+ calendar component, than that provided by the "SUMMARY" property.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: The property can be specified in the "VEVENT", "VTODO",
+ "VJOURNAL" or "VALARM" calendar components. The property can be
+ specified multiple times only within a "VJOURNAL" calendar component.
+
+ Description: This property is used in the "VEVENT" and "VTODO" to
+ capture lengthy textual decriptions associated with the activity.
+
+ This property is used in the "VJOURNAL" calendar component to capture
+ one more textual journal entries.
+
+ This property is used in the "VALARM" calendar component to capture
+ the display text for a DISPLAY category of alarm, to capture the body
+ text for an EMAIL category of alarm and to capture the argument
+ string for a PROCEDURE category of alarm.
+
+ Format Definition: The property is defined by the following notation:
+
+ description = "DESCRIPTION" descparam ":" text CRLF
+
+ descparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+
+
+Dawson & Stenerson Standards Track [Page 81]
+
+RFC 2445 iCalendar November 1998
+
+
+ Example: The following is an example of the property with formatted
+ line breaks in the property value:
+
+ DESCRIPTION:Meeting to provide technical review for "Phoenix"
+ design.\n Happy Face Conference Room. Phoenix design team
+ MUST attend this meeting.\n RSVP to team leader.
+
+ The following is an example of the property with folding of long
+ lines:
+
+ DESCRIPTION:Last draft of the new novel is to be completed
+ for the editor's proof today.
+
+4.8.1.6 Geographic Position
+
+ Property Name: GEO
+
+ Purpose: This property specifies information related to the global
+ position for the activity specified by a calendar component.
+
+ Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
+ values.
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in "VEVENT" or "VTODO"
+ calendar components.
+
+ Description: The property value specifies latitude and longitude, in
+ that order (i.e., "LAT LON" ordering). The longitude represents the
+ location east or west of the prime meridian as a positive or negative
+ real number, respectively. The longitude and latitude values MAY be
+ specified up to six decimal places, which will allow for accuracy to
+ within one meter of geographical position. Receiving applications
+ MUST accept values of this precision and MAY truncate values of
+ greater precision.
+
+ Values for latitude and longitude shall be expressed as decimal
+ fractions of degrees. Whole degrees of latitude shall be represented
+ by a two-digit decimal number ranging from 0 through 90. Whole
+ degrees of longitude shall be represented by a decimal number ranging
+ from 0 through 180. When a decimal fraction of a degree is specified,
+ it shall be separated from the whole number of degrees by a decimal
+ point.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 82]
+
+RFC 2445 iCalendar November 1998
+
+
+ Latitudes north of the equator shall be specified by a plus sign (+),
+ or by the absence of a minus sign (-), preceding the digits
+ designating degrees. Latitudes south of the Equator shall be
+ designated by a minus sign (-) preceding the digits designating
+ degrees. A point on the Equator shall be assigned to the Northern
+ Hemisphere.
+
+ Longitudes east of the prime meridian shall be specified by a plus
+ sign (+), or by the absence of a minus sign (-), preceding the digits
+ designating degrees. Longitudes west of the meridian shall be
+ designated by minus sign (-) preceding the digits designating
+ degrees. A point on the prime meridian shall be assigned to the
+ Eastern Hemisphere. A point on the 180th meridian shall be assigned
+ to the Western Hemisphere. One exception to this last convention is
+ permitted. For the special condition of describing a band of latitude
+ around the earth, the East Bounding Coordinate data element shall be
+ assigned the value +180 (180) degrees.
+
+ Any spatial address with a latitude of +90 (90) or -90 degrees will
+ specify the position at the North or South Pole, respectively. The
+ component for longitude may have any legal value.
+
+ With the exception of the special condition described above, this
+ form is specified in Department of Commerce, 1986, Representation of
+ geographic point locations for information interchange (Federal
+ Information Processing Standard 70-1): Washington, Department of
+ Commerce, National Institute of Standards and Technology.
+
+ The simple formula for converting degrees-minutes-seconds into
+ decimal degrees is:
+
+ decimal = degrees + minutes/60 + seconds/3600.
+
+ Format Definition: The property is defined by the following notation:
+
+ geo = "GEO" geoparam ":" geovalue CRLF
+
+ geoparam = *(";" xparam)
+
+ geovalue = float ";" float
+ ;Latitude and Longitude components
+
+ Example: The following is an example of this property:
+
+ GEO:37.386013;-122.082932
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 83]
+
+RFC 2445 iCalendar November 1998
+
+
+4.8.1.7 Location
+
+ Property Name: LOCATION
+
+ Purpose: The property defines the intended venue for the activity
+ defined by a calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: This property can be specified in "VEVENT" or "VTODO"
+ calendar component.
+
+ Description: Specific venues such as conference or meeting rooms may
+ be explicitly specified using this property. An alternate
+ representation may be specified that is a URI that points to
+ directory information with more structured specification of the
+ location. For example, the alternate representation may specify
+ either an LDAP URI pointing to an LDAP server entry or a CID URI
+ pointing to a MIME body part containing a vCard [RFC 2426] for the
+ location.
+
+ Format Definition: The property is defined by the following notation:
+
+ location = "LOCATION locparam ":" text CRLF
+
+ locparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following are some examples of this property:
+
+ LOCATION:Conference Room - F123, Bldg. 002
+
+ LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
+ Conference Room - F123, Bldg. 002
+
+
+
+Dawson & Stenerson Standards Track [Page 84]
+
+RFC 2445 iCalendar November 1998
+
+
+4.8.1.8 Percent Complete
+
+ Property Name: PERCENT-COMPLETE
+
+ Purpose: This property is used by an assignee or delegatee of a to-do
+ to convey the percent completion of a to-do to the Organizer.
+
+ Value Type: INTEGER
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in a "VTODO" calendar
+ component.
+
+ Description: The property value is a positive integer between zero
+ and one hundred. A value of "0" indicates the to-do has not yet been
+ started. A value of "100" indicates that the to-do has been
+ completed. Integer values in between indicate the percent partially
+ complete.
+
+ When a to-do is assigned to multiple individuals, the property value
+ indicates the percent complete for that portion of the to-do assigned
+ to the assignee or delegatee. For example, if a to-do is assigned to
+ both individuals "A" and "B". A reply from "A" with a percent
+ complete of "70" indicates that "A" has completed 70% of the to-do
+ assigned to them. A reply from "B" with a percent complete of "50"
+ indicates "B" has completed 50% of the to-do assigned to them.
+
+ Format Definition: The property is defined by the following notation:
+
+ percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
+
+ pctparam = *(";" xparam)
+
+ Example: The following is an example of this property to show 39%
+ completion:
+
+ PERCENT-COMPLETE:39
+
+4.8.1.9 Priority
+
+ Property Name: PRIORITY
+
+ Purpose: The property defines the relative priority for a calendar
+ component.
+
+ Value Type: INTEGER
+
+
+
+Dawson & Stenerson Standards Track [Page 85]
+
+RFC 2445 iCalendar November 1998
+
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified in a "VEVENT" or "VTODO"
+ calendar component.
+
+ Description: The priority is specified as an integer in the range
+ zero to nine. A value of zero (US-ASCII decimal 48) specifies an
+ undefined priority. A value of one (US-ASCII decimal 49) is the
+ highest priority. A value of two (US-ASCII decimal 50) is the second
+ highest priority. Subsequent numbers specify a decreasing ordinal
+ priority. A value of nine (US-ASCII decimal 58) is the lowest
+ priority.
+
+ A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
+ "LOW" is mapped into this property such that a property value in the
+ range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52)
+ specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is
+ the normal or "MEDIUM" priority. A value in the range of six (US-
+ ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority.
+
+ A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
+ "C3" is mapped into this property such that a property value of one
+ (US-ASCII decimal 49) specifies "A1", a property value of two (US-
+ ASCII decimal 50) specifies "A2", a property value of three (US-ASCII
+ decimal 51) specifies "A3", and so forth up to a property value of 9
+ (US-ASCII decimal 58) specifies "C3".
+
+ Other integer values are reserved for future use.
+
+ Within a "VEVENT" calendar component, this property specifies a
+ priority for the event. This property may be useful when more than
+ one event is scheduled for a given time period.
+
+ Within a "VTODO" calendar component, this property specified a
+ priority for the to-do. This property is useful in prioritizing
+ multiple action items for a given time period.
+
+ Format Definition: The property is specified by the following
+ notation:
+
+ priority = "PRIORITY" prioparam ":" privalue CRLF
+ ;Default is zero
+
+ prioparam = *(";" xparam)
+
+ privalue = integer ;Must be in the range [0..9]
+ ; All other values are reserved for future use
+
+
+
+Dawson & Stenerson Standards Track [Page 86]
+
+RFC 2445 iCalendar November 1998
+
+
+ The following is an example of a property with the highest priority:
+
+ PRIORITY:1
+
+ The following is an example of a property with a next highest
+ priority:
+
+ PRIORITY:2
+
+ Example: The following is an example of a property with no priority.
+ This is equivalent to not specifying the "PRIORITY" property:
+
+ PRIORITY:0
+
+4.8.1.10 Resources
+
+ Property Name: RESOURCES
+
+ Purpose: This property defines the equipment or resources anticipated
+ for an activity specified by a calendar entity..
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: This property can be specified in "VEVENT" or "VTODO"
+ calendar component.
+
+ Description: The property value is an arbitrary text. More than one
+ resource can be specified as a list of resources separated by the
+ COMMA character (US-ASCII decimal 44).
+
+ Format Definition: The property is defined by the following notation:
+
+ resources = "RESOURCES" resrcparam ":" text *("," text) CRLF
+
+ resrcparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 87]
+
+RFC 2445 iCalendar November 1998
+
+
+ (";" xparam)
+
+ )
+
+ Example: The following is an example of this property:
+
+ RESOURCES:EASEL,PROJECTOR,VCR
+
+ RESOURCES;LANGUAGE=fr:1 raton-laveur
+
+4.8.1.11 Status
+
+ Property Name: STATUS
+
+ Purpose: This property defines the overall status or confirmation for
+ the calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in "VEVENT", "VTODO" or
+ "VJOURNAL" calendar components.
+
+ Description: In a group scheduled calendar component, the property is
+ used by the "Organizer" to provide a confirmation of the event to the
+ "Attendees". For example in a "VEVENT" calendar component, the
+ "Organizer" can indicate that a meeting is tentative, confirmed or
+ cancelled. In a "VTODO" calendar component, the "Organizer" can
+ indicate that an action item needs action, is completed, is in
+ process or being worked on, or has been cancelled. In a "VJOURNAL"
+ calendar component, the "Organizer" can indicate that a journal entry
+ is draft, final or has been cancelled or removed.
+
+ Format Definition: The property is defined by the following notation:
+
+ status = "STATUS" statparam] ":" statvalue CRLF
+
+ statparam = *(";" xparam)
+
+ statvalue = "TENTATIVE" ;Indicates event is
+ ;tentative.
+ / "CONFIRMED" ;Indicates event is
+ ;definite.
+ / "CANCELLED" ;Indicates event was
+ ;cancelled.
+ ;Status values for a "VEVENT"
+
+
+
+Dawson & Stenerson Standards Track [Page 88]
+
+RFC 2445 iCalendar November 1998
+
+
+ statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action.
+ / "COMPLETED" ;Indicates to-do completed.
+ / "IN-PROCESS" ;Indicates to-do in process of
+ / "CANCELLED" ;Indicates to-do was cancelled.
+ ;Status values for "VTODO".
+
+ statvalue =/ "DRAFT" ;Indicates journal is draft.
+ / "FINAL" ;Indicates journal is final.
+ / "CANCELLED" ;Indicates journal is removed.
+ ;Status values for "VJOURNAL".
+
+ Example: The following is an example of this property for a "VEVENT"
+ calendar component:
+
+ STATUS:TENTATIVE
+
+ The following is an example of this property for a "VTODO" calendar
+ component:
+
+ STATUS:NEEDS-ACTION
+
+ The following is an example of this property for a "VJOURNAL"
+ calendar component:
+
+ STATUS:DRAFT
+
+4.8.1.12 Summary
+
+ Property Name: SUMMARY
+
+ Purpose: This property defines a short summary or subject for the
+ calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: The property can be specified in "VEVENT", "VTODO",
+ "VJOURNAL" or "VALARM" calendar components.
+
+ Description: This property is used in the "VEVENT", "VTODO" and
+ "VJOURNAL" calendar components to capture a short, one line summary
+ about the activity or journal entry.
+
+ This property is used in the "VALARM" calendar component to capture
+ the subject of an EMAIL category of alarm.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 89]
+
+RFC 2445 iCalendar November 1998
+
+
+ Format Definition: The property is defined by the following notation:
+
+ summary = "SUMMARY" summparam ":" text CRLF
+
+ summparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following is an example of this property:
+
+ SUMMARY:Department Party
+
+4.8.2 Date and Time Component Properties
+
+ The following properties specify date and time related information in
+ calendar components.
+
+4.8.2.1 Date/Time Completed
+
+ Property Name: COMPLETED
+
+ Purpose: This property defines the date and time that a to-do was
+ actually completed.
+
+ Value Type: DATE-TIME
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified in a "VTODO" calendar
+ component.
+
+ Description: The date and time MUST be in a UTC format.
+
+ Format Definition: The property is defined by the following notation:
+
+ completed = "COMPLETED" compparam ":" date-time CRLF
+
+
+
+
+Dawson & Stenerson Standards Track [Page 90]
+
+RFC 2445 iCalendar November 1998
+
+
+ compparam = *(";" xparam)
+
+ Example: The following is an example of this property:
+
+ COMPLETED:19960401T235959Z
+
+4.8.2.2 Date/Time End
+
+ Property Name: DTEND
+
+ Purpose: This property specifies the date and time that a calendar
+ component ends.
+
+ Value Type: The default value type is DATE-TIME. The value type can
+ be set to a DATE value type.
+
+ Property Parameters: Non-standard, value data type, time zone
+ identifier property parameters can be specified on this property.
+
+ Conformance: This property can be specified in "VEVENT" or
+ "VFREEBUSY" calendar components.
+
+ Description: Within the "VEVENT" calendar component, this property
+ defines the date and time by which the event ends. The value MUST be
+ later in time than the value of the "DTSTART" property.
+
+ Within the "VFREEBUSY" calendar component, this property defines the
+ end date and time for the free or busy time information. The time
+ MUST be specified in the UTC time format. The value MUST be later in
+ time than the value of the "DTSTART" property.
+
+ Format Definition: The property is defined by the following notation:
+
+ dtend = "DTEND" dtendparam":" dtendval CRLF
+
+ dtendparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+ (";" tzidparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 91]
+
+RFC 2445 iCalendar November 1998
+
+
+ (";" xparam)
+
+ )
+
+
+
+ dtendval = date-time / date
+ ;Value MUST match value type
+
+ Example: The following is an example of this property:
+
+ DTEND:19960401T235959Z
+
+ DTEND;VALUE=DATE:19980704
+
+4.8.2.3 Date/Time Due
+
+ Property Name: DUE
+
+ Purpose: This property defines the date and time that a to-do is
+ expected to be completed.
+
+ Value Type: The default value type is DATE-TIME. The value type can
+ be set to a DATE value type.
+
+ Property Parameters: Non-standard, value data type, time zone
+ identifier property parameters can be specified on this property.
+
+ Conformance: The property can be specified once in a "VTODO" calendar
+ component.
+
+ Description: The value MUST be a date/time equal to or after the
+ DTSTART value, if specified.
+
+ Format Definition: The property is defined by the following notation:
+
+ due = "DUE" dueparam":" dueval CRLF
+
+ dueparam = *(
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+ (";" tzidparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+
+
+
+Dawson & Stenerson Standards Track [Page 92]
+
+RFC 2445 iCalendar November 1998
+
+
+ *(";" xparam)
+
+ )
+
+
+
+ dueval = date-time / date
+ ;Value MUST match value type
+
+ Example: The following is an example of this property:
+
+ DUE:19980430T235959Z
+
+4.8.2.4 Date/Time Start
+
+ Property Name: DTSTART
+
+ Purpose: This property specifies when the calendar component begins.
+
+ Value Type: The default value type is DATE-TIME. The time value MUST
+ be one of the forms defined for the DATE-TIME value type. The value
+ type can be set to a DATE value type.
+
+ Property Parameters: Non-standard, value data type, time zone
+ identifier property parameters can be specified on this property.
+
+ Conformance: This property can be specified in the "VEVENT", "VTODO",
+ "VFREEBUSY", or "VTIMEZONE" calendar components.
+
+ Description: Within the "VEVENT" calendar component, this property
+ defines the start date and time for the event. The property is
+ REQUIRED in "VEVENT" calendar components. Events can have a start
+ date/time but no end date/time. In that case, the event does not take
+ up any time.
+
+ Within the "VFREEBUSY" calendar component, this property defines the
+ start date and time for the free or busy time information. The time
+ MUST be specified in UTC time.
+
+ Within the "VTIMEZONE" calendar component, this property defines the
+ effective start date and time for a time zone specification. This
+ property is REQUIRED within each STANDARD and DAYLIGHT part included
+ in "VTIMEZONE" calendar components and MUST be specified as a local
+ DATE-TIME without the "TZID" property parameter.
+
+ Format Definition: The property is defined by the following notation:
+
+ dtstart = "DTSTART" dtstparam ":" dtstval CRLF
+
+
+
+Dawson & Stenerson Standards Track [Page 93]
+
+RFC 2445 iCalendar November 1998
+
+
+ dtstparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+ (";" tzidparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ *(";" xparam)
+
+ )
+
+
+
+ dtstval = date-time / date
+ ;Value MUST match value type
+
+ Example: The following is an example of this property:
+
+ DTSTART:19980118T073000Z
+
+4.8.2.5 Duration
+
+ Property Name: DURATION
+
+ Purpose: The property specifies a positive duration of time.
+
+ Value Type: DURATION
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified in "VEVENT", "VTODO",
+ "VFREEBUSY" or "VALARM" calendar components.
+
+ Description: In a "VEVENT" calendar component the property may be
+ used to specify a duration of the event, instead of an explicit end
+ date/time. In a "VTODO" calendar component the property may be used
+ to specify a duration for the to-do, instead of an explicit due
+ date/time. In a "VFREEBUSY" calendar component the property may be
+ used to specify the interval of free time being requested. In a
+ "VALARM" calendar component the property may be used to specify the
+ delay period prior to repeating an alarm.
+
+ Format Definition: The property is defined by the following notation:
+
+
+
+Dawson & Stenerson Standards Track [Page 94]
+
+RFC 2445 iCalendar November 1998
+
+
+ duration = "DURATION" durparam ":" dur-value CRLF
+ ;consisting of a positive duration of time.
+
+ durparam = *(";" xparam)
+
+ Example: The following is an example of this property that specifies
+ an interval of time of 1 hour and zero minutes and zero seconds:
+
+ DURATION:PT1H0M0S
+
+ The following is an example of this property that specifies an
+ interval of time of 15 minutes.
+
+ DURATION:PT15M
+
+4.8.2.6 Free/Busy Time
+
+ Property Name: FREEBUSY
+
+ Purpose: The property defines one or more free or busy time
+ intervals.
+
+ Value Type: PERIOD. The date and time values MUST be in an UTC time
+ format.
+
+ Property Parameters: Non-standard or free/busy time type property
+ parameters can be specified on this property.
+
+ Conformance: The property can be specified in a "VFREEBUSY" calendar
+ component.
+
+ Property Parameter: "FBTYPE" and non-standard parameters can be
+ specified on this property.
+
+ Description: These time periods can be specified as either a start
+ and end date-time or a start date-time and duration. The date and
+ time MUST be a UTC time format.
+
+ "FREEBUSY" properties within the "VFREEBUSY" calendar component
+ SHOULD be sorted in ascending order, based on start time and then end
+ time, with the earliest periods first.
+
+ The "FREEBUSY" property can specify more than one value, separated by
+ the COMMA character (US-ASCII decimal 44). In such cases, the
+ "FREEBUSY" property values SHOULD all be of the same "FBTYPE"
+ property parameter type (e.g., all values of a particular "FBTYPE"
+ listed together in a single property).
+
+
+
+
+Dawson & Stenerson Standards Track [Page 95]
+
+RFC 2445 iCalendar November 1998
+
+
+ Format Definition: The property is defined by the following notation:
+
+ freebusy = "FREEBUSY" fbparam ":" fbvalue
+ CRLF
+
+ fbparam = *(
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ (";" fbtypeparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ fbvalue = period *["," period]
+ ;Time value MUST be in the UTC time format.
+
+ Example: The following are some examples of this property:
+
+ FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
+
+ FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
+
+ FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H,
+ 19970308T230000Z/19970309T000000Z
+
+4.8.2.7 Time Transparency
+
+ Property Name: TRANSP
+
+ Purpose: This property defines whether an event is transparent or not
+ to busy time searches.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified once in a "VEVENT"
+ calendar component.
+
+ Description: Time Transparency is the characteristic of an event that
+ determines whether it appears to consume time on a calendar. Events
+ that consume actual time for the individual or resource associated
+
+
+
+Dawson & Stenerson Standards Track [Page 96]
+
+RFC 2445 iCalendar November 1998
+
+
+ with the calendar SHOULD be recorded as OPAQUE, allowing them to be
+ detected by free-busy time searches. Other events, which do not take
+ up the individual's (or resource's) time SHOULD be recorded as
+ TRANSPARENT, making them invisible to free-busy time searches.
+
+ Format Definition: The property is specified by the following
+ notation:
+
+ transp = "TRANSP" tranparam ":" transvalue CRLF
+
+ tranparam = *(";" xparam)
+
+ transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
+ / "TRANSPARENT" ;Transparent on busy time searches.
+ ;Default value is OPAQUE
+
+ Example: The following is an example of this property for an event
+ that is transparent or does not block on free/busy time searches:
+
+ TRANSP:TRANSPARENT
+
+ The following is an example of this property for an event that is
+ opaque or blocks on free/busy time searches:
+
+ TRANSP:OPAQUE
+
+4.8.3 Time Zone Component Properties
+
+ The following properties specify time zone information in calendar
+ components.
+
+4.8.3.1 Time Zone Identifier
+
+ Property Name: TZID
+
+ Purpose: This property specifies the text value that uniquely
+ identifies the "VTIMEZONE" calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property MUST be specified in a "VTIMEZONE"
+ calendar component.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 97]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: This is the label by which a time zone calendar
+ component is referenced by any iCalendar properties whose data type
+ is either DATE-TIME or TIME and not intended to specify a UTC or a
+ "floating" time. The presence of the SOLIDUS character (US-ASCII
+ decimal 47) as a prefix, indicates that this TZID represents an
+ unique ID in a globally defined time zone registry (when such
+ registry is defined).
+
+ Note: This document does not define a naming convention for time
+ zone identifiers. Implementers may want to use the naming
+ conventions defined in existing time zone specifications such as
+ the public-domain Olson database [TZ]. The specification of
+ globally unique time zone identifiers is not addressed by this
+ document and is left for future study.
+
+ Format Definition: This property is defined by the following
+ notation:
+
+ tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
+
+ tzidpropparam = *(";" xparam)
+
+ ;tzidprefix = "/"
+ ; Defined previously. Just listed here for reader convenience.
+
+ Example: The following are examples of non-globally unique time zone
+ identifiers:
+
+ TZID:US-Eastern
+
+ TZID:California-Los_Angeles
+
+ The following is an example of a fictitious globally unique time zone
+ identifier:
+
+ TZID:/US-New_York-New_York
+
+4.8.3.2 Time Zone Name
+
+ Property Name: TZNAME
+
+ Purpose: This property specifies the customary designation for a time
+ zone description.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard and language property parameters
+ can be specified on this property.
+
+
+
+Dawson & Stenerson Standards Track [Page 98]
+
+RFC 2445 iCalendar November 1998
+
+
+ Conformance: This property can be specified in a "VTIMEZONE" calendar
+ component.
+
+ Description: This property may be specified in multiple languages; in
+ order to provide for different language requirements.
+
+ Format Definition: This property is defined by the following
+ notation:
+
+ tzname = "TZNAME" tznparam ":" text CRLF
+
+ tznparam = *(
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following are example of this property:
+
+ TZNAME:EST
+
+ The following is an example of this property when two different
+ languages for the time zone name are specified:
+
+ TZNAME;LANGUAGE=en:EST
+ TZNAME;LANGUAGE=fr-CA:HNE
+
+4.8.3.3 Time Zone Offset From
+
+ Property Name: TZOFFSETFROM
+
+ Purpose: This property specifies the offset which is in use prior to
+ this time zone observance.
+
+ Value Type: UTC-OFFSET
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 99]
+
+RFC 2445 iCalendar November 1998
+
+
+ Conformance: This property MUST be specified in a "VTIMEZONE"
+ calendar component.
+
+ Description: This property specifies the offset which is in use prior
+ to this time observance. It is used to calculate the absolute time at
+ which the transition to a given observance takes place. This property
+ MUST only be specified in a "VTIMEZONE" calendar component. A
+ "VTIMEZONE" calendar component MUST include this property. The
+ property value is a signed numeric indicating the number of hours and
+ possibly minutes from UTC. Positive numbers represent time zones east
+ of the prime meridian, or ahead of UTC. Negative numbers represent
+ time zones west of the prime meridian, or behind UTC.
+
+ Format Definition: The property is defined by the following notation:
+
+ tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset
+ CRLF
+
+ frmparam = *(";" xparam)
+
+ Example: The following are examples of this property:
+
+ TZOFFSETFROM:-0500
+
+ TZOFFSETFROM:+1345
+
+4.8.3.4 Time Zone Offset To
+
+ Property Name: TZOFFSETTO
+
+ Purpose: This property specifies the offset which is in use in this
+ time zone observance.
+
+ Value Type: UTC-OFFSET
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property MUST be specified in a "VTIMEZONE"
+ calendar component.
+
+ Description: This property specifies the offset which is in use in
+ this time zone observance. It is used to calculate the absolute time
+ for the new observance. The property value is a signed numeric
+ indicating the number of hours and possibly minutes from UTC.
+ Positive numbers represent time zones east of the prime meridian, or
+ ahead of UTC. Negative numbers represent time zones west of the prime
+ meridian, or behind UTC.
+
+
+
+Dawson & Stenerson Standards Track [Page 100]
+
+RFC 2445 iCalendar November 1998
+
+
+ Format Definition: The property is defined by the following notation:
+
+ tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
+
+ toparam = *(";" xparam)
+
+ Example: The following are examples of this property:
+
+ TZOFFSETTO:-0400
+
+ TZOFFSETTO:+1245
+
+4.8.3.5 Time Zone URL
+
+ Property Name: TZURL
+
+ Purpose: The TZURL provides a means for a VTIMEZONE component to
+ point to a network location that can be used to retrieve an up-to-
+ date version of itself.
+
+ Value Type: URI
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in a "VTIMEZONE" calendar
+ component.
+
+ Description: The TZURL provides a means for a VTIMEZONE component to
+ point to a network location that can be used to retrieve an up-to-
+ date version of itself. This provides a hook to handle changes
+ government bodies impose upon time zone definitions. Retrieval of
+ this resource results in an iCalendar object containing a single
+ VTIMEZONE component and a METHOD property set to PUBLISH.
+
+ Format Definition: The property is defined by the following notation:
+
+ tzurl = "TZURL" tzurlparam ":" uri CRLF
+
+ tzurlparam = *(";" xparam)
+
+ Example: The following is an example of this property:
+
+ TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 101]
+
+RFC 2445 iCalendar November 1998
+
+
+4.8.4 Relationship Component Properties
+
+ The following properties specify relationship information in calendar
+ components.
+
+4.8.4.1 Attendee
+
+ Property Name: ATTENDEE
+
+ Purpose: The property defines an "Attendee" within a calendar
+ component.
+
+ Value Type: CAL-ADDRESS
+
+ Property Parameters: Non-standard, language, calendar user type,
+ group or list membership, participation role, participation status,
+ RSVP expectation, delegatee, delegator, sent by, common name or
+ directory entry reference property parameters can be specified on
+ this property.
+
+ Conformance: This property MUST be specified in an iCalendar object
+ that specifies a group scheduled calendar entity. This property MUST
+ NOT be specified in an iCalendar object when publishing the calendar
+ information (e.g., NOT in an iCalendar object that specifies the
+ publication of a calendar user's busy time, event, to-do or journal).
+ This property is not specified in an iCalendar object that specifies
+ only a time zone definition or that defines calendar entities that
+ are not group scheduled entities, but are entities only on a single
+ user's calendar.
+
+ Description: The property MUST only be specified within calendar
+ components to specify participants, non-participants and the chair of
+ a group scheduled calendar entity. The property is specified within
+ an "EMAIL" category of the "VALARM" calendar component to specify an
+ email address that is to receive the email type of iCalendar alarm.
+
+ The property parameter CN is for the common or displayable name
+ associated with the calendar address; ROLE, for the intended role
+ that the attendee will have in the calendar component; PARTSTAT, for
+ the status of the attendee's participation; RSVP, for indicating
+ whether the favor of a reply is requested; CUTYPE, to indicate the
+ type of calendar user; MEMBER, to indicate the groups that the
+ attendee belongs to; DELEGATED-TO, to indicate the calendar users
+ that the original request was delegated to; and DELEGATED-FROM, to
+ indicate whom the request was delegated from; SENT-BY, to indicate
+ whom is acting on behalf of the ATTENDEE; and DIR, to indicate the
+ URI that points to the directory information corresponding to the
+ attendee. These property parameters can be specified on an "ATTENDEE"
+
+
+
+Dawson & Stenerson Standards Track [Page 102]
+
+RFC 2445 iCalendar November 1998
+
+
+ property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar
+ component. They MUST not be specified in an "ATTENDEE" property in a
+ "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property
+ parameter is specified, the identified language applies to the CN
+ parameter.
+
+ A recipient delegated a request MUST inherit the RSVP and ROLE values
+ from the attendee that delegated the request to them.
+
+ Multiple attendees can be specified by including multiple "ATTENDEE"
+ properties within the calendar component.
+
+ Format Definition: The property is defined by the following notation:
+
+ attendee = "ATTENDEE" attparam ":" cal-address CRLF
+
+ attparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" cutypeparam) / (";"memberparam) /
+ (";" roleparam) / (";" partstatparam) /
+ (";" rsvpparam) / (";" deltoparam) /
+ (";" delfromparam) / (";" sentbyparam) /
+ (";"cnparam) / (";" dirparam) /
+ (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following are examples of this property's use for a to-
+ do:
+
+ ORGANIZER:MAILTO:jsmith@host1.com
+ ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com":
+ MAILTO:joecool@host2.com
+ ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com":
+ MAILTO:ildoit@host1.com
+
+ The following is an example of this property used for specifying
+ multiple attendees to an event:
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 103]
+
+RFC 2445 iCalendar November 1998
+
+
+ ORGANIZER:MAILTO:jsmith@host1.com
+ ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot
+ :MAILTO:hcabot@host2.com
+ ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com"
+ ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com
+
+ The following is an example of this property with a URI to the
+ directory information associated with the attendee:
+
+ ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC%
+ 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@
+ host1.com
+
+ The following is an example of this property with "delegatee" and
+ "delegator" information for an event:
+
+ ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com
+ ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
+ "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@
+ host2.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
+ "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss
+ @host2.com
+ ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
+ :MAILTO:jdoe@host1.com
+
+ Example: The following is an example of this property's use when
+ another calendar user is acting on behalf of the "Attendee":
+
+ ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO:
+ jsmith@host1.com
+
+4.8.4.2 Contact
+
+ Property Name: CONTACT
+
+ Purpose: The property is used to represent contact information or
+ alternately a reference to contact information associated with the
+ calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard, alternate text representation and
+ language property parameters can be specified on this property.
+
+ Conformance: The property can be specified in a "VEVENT", "VTODO",
+ "VJOURNAL" or "VFREEBUSY" calendar component.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 104]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: The property value consists of textual contact
+ information. An alternative representation for the property value can
+ also be specified that refers to a URI pointing to an alternate form,
+ such as a vCard [RFC 2426], for the contact information.
+
+ Format Definition: The property is defined by the following notation:
+
+ contact = "CONTACT" contparam ":" text CRLF
+
+ contparam = *(
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" altrepparam) / (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following is an example of this property referencing
+ textual contact information:
+
+ CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
+
+ The following is an example of this property with an alternate
+ representation of a LDAP URI to a directory entry containing the
+ contact information:
+
+ CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\,
+ c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\,
+ +1-919-555-1234
+
+ The following is an example of this property with an alternate
+ representation of a MIME body part containing the contact
+ information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
+ content-type:
+
+ CONTACT;ALTREP="CID=<part3.msg970930T083000SILVER@host.com>":Jim
+ Dolittle\, ABC Industries\, +1-919-555-1234
+
+ The following is an example of this property referencing a network
+ resource, such as a vCard [RFC 2426] object containing the contact
+ information:
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 105]
+
+RFC 2445 iCalendar November 1998
+
+
+ CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim
+ Dolittle\, ABC Industries\, +1-919-555-1234
+
+4.8.4.3 Organizer
+
+ Property Name: ORGANIZER
+
+ Purpose: The property defines the organizer for a calendar component.
+
+ Value Type: CAL-ADDRESS
+
+ Property Parameters: Non-standard, language, common name, directory
+ entry reference, sent by property parameters can be specified on this
+ property.
+
+ Conformance: This property MUST be specified in an iCalendar object
+ that specifies a group scheduled calendar entity. This property MUST
+ be specified in an iCalendar object that specifies the publication of
+ a calendar user's busy time. This property MUST NOT be specified in
+ an iCalendar object that specifies only a time zone definition or
+ that defines calendar entities that are not group scheduled entities,
+ but are entities only on a single user's calendar.
+
+ Description: The property is specified within the "VEVENT", "VTODO",
+ "VJOURNAL calendar components to specify the organizer of a group
+ scheduled calendar entity. The property is specified within the
+ "VFREEBUSY" calendar component to specify the calendar user
+ requesting the free or busy time. When publishing a "VFREEBUSY"
+ calendar component, the property is used to specify the calendar that
+ the published busy time came from.
+
+ The property has the property parameters CN, for specifying the
+ common or display name associated with the "Organizer", DIR, for
+ specifying a pointer to the directory information associated with the
+ "Organizer", SENT-BY, for specifying another calendar user that is
+ acting on behalf of the "Organizer". The non-standard parameters may
+ also be specified on this property. If the LANGUAGE property
+ parameter is specified, the identified language applies to the CN
+ parameter value.
+
+ Format Definition: The property is defined by the following notation:
+
+ organizer = "ORGANIZER" orgparam ":"
+ cal-address CRLF
+
+ orgparam = *(
+
+ ; the following are optional,
+
+
+
+Dawson & Stenerson Standards Track [Page 106]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; but MUST NOT occur more than once
+
+ (";" cnparam) / (";" dirparam) / (";" sentbyparam) /
+ (";" languageparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ Example: The following is an example of this property:
+
+ ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com
+
+ The following is an example of this property with a pointer to the
+ directory information associated with the organizer:
+
+ ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ
+ ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com
+
+ The following is an example of this property used by another calendar
+ user who is acting on behalf of the organizer, with responses
+ intended to be sent back to the organizer, not the other calendar
+ user:
+
+ ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com":
+ MAILTO:jsmith@host1.com
+
+4.8.4.4 Recurrence ID
+
+ Property Name: RECURRENCE-ID
+
+ Purpose: This property is used in conjunction with the "UID" and
+ "SEQUENCE" property to identify a specific instance of a recurring
+ "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
+ value is the effective value of the "DTSTART" property of the
+ recurrence instance.
+
+ Value Type: The default value type for this property is DATE-TIME.
+ The time format can be any of the valid forms defined for a DATE-TIME
+ value type. See DATE-TIME value type definition for specific
+ interpretations of the various forms. The value type can be set to
+ DATE.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 107]
+
+RFC 2445 iCalendar November 1998
+
+
+ Property Parameters: Non-standard property, value data type, time
+ zone identifier and recurrence identifier range parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in an iCalendar object
+ containing a recurring calendar component.
+
+ Description: The full range of calendar components specified by a
+ recurrence set is referenced by referring to just the "UID" property
+ value corresponding to the calendar component. The "RECURRENCE-ID"
+ property allows the reference to an individual instance within the
+ recurrence set.
+
+ If the value of the "DTSTART" property is a DATE type value, then the
+ value MUST be the calendar date for the recurrence instance.
+
+ The date/time value is set to the time when the original recurrence
+ instance would occur; meaning that if the intent is to change a
+ Friday meeting to Thursday, the date/time is still set to the
+ original Friday meeting.
+
+ The "RECURRENCE-ID" property is used in conjunction with the "UID"
+ and "SEQUENCE" property to identify a particular instance of a
+ recurring event, to-do or journal. For a given pair of "UID" and
+ "SEQUENCE" property values, the "RECURRENCE-ID" value for a
+ recurrence instance is fixed. When the definition of the recurrence
+ set for a calendar component changes, and hence the "SEQUENCE"
+ property value changes, the "RECURRENCE-ID" for a given recurrence
+ instance might also change.The "RANGE" parameter is used to specify
+ the effective range of recurrence instances from the instance
+ specified by the "RECURRENCE-ID" property value. The default value
+ for the range parameter is the single recurrence instance only. The
+ value can also be "THISANDPRIOR" to indicate a range defined by the
+ given recurrence instance and all prior instances or the value can be
+ "THISANDFUTURE" to indicate a range defined by the given recurrence
+ instance and all subsequent instances.
+
+ Format Definition: The property is defined by the following notation:
+
+ recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF
+
+ ridparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
+ (";" tzidparam) / (";" rangeparam) /
+
+
+
+Dawson & Stenerson Standards Track [Page 108]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ ridval = date-time / date
+ ;Value MUST match value type
+
+ Example: The following are examples of this property:
+
+ RECURRENCE-ID;VALUE=DATE:19960401
+
+ RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
+
+4.8.4.5 Related To
+
+ Property Name: RELATED-TO
+
+ Purpose: The property is used to represent a relationship or
+ reference between one calendar component and another.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard and relationship type property
+ parameters can be specified on this property.
+
+ Conformance: The property can be specified one or more times in the
+ "VEVENT", "VTODO" or "VJOURNAL" calendar components.
+
+ Description: The property value consists of the persistent, globally
+ unique identifier of another calendar component. This value would be
+ represented in a calendar component by the "UID" property.
+
+ By default, the property value points to another calendar component
+ that has a PARENT relationship to the referencing object. The
+ "RELTYPE" property parameter is used to either explicitly state the
+ default PARENT relationship type to the referenced calendar component
+ or to override the default PARENT relationship type and specify
+ either a CHILD or SIBLING relationship. The PARENT relationship
+ indicates that the calendar component is a subordinate of the
+ referenced calendar component. The CHILD relationship indicates that
+ the calendar component is a superior of the referenced calendar
+ component. The SIBLING relationship indicates that the calendar
+ component is a peer of the referenced calendar component.
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 109]
+
+RFC 2445 iCalendar November 1998
+
+
+ Changes to a calendar component referenced by this property can have
+ an implicit impact on the related calendar component. For example, if
+ a group event changes its start or end date or time, then the
+ related, dependent events will need to have their start and end dates
+ changed in a corresponding way. Similarly, if a PARENT calendar
+ component is canceled or deleted, then there is an implied impact to
+ the related CHILD calendar components. This property is intended only
+ to provide information on the relationship of calendar components. It
+ is up to the target calendar system to maintain any property
+ implications of this relationship.
+
+ Format Definition: The property is defined by the following notation:
+
+ related = "RELATED-TO" [relparam] ":" text CRLF
+
+ relparam = *(
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+ (";" reltypeparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparm)
+
+ )
+
+ The following is an example of this property:
+
+ RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com>
+
+ RELATED-TO:<19960401-080045-4000F192713-0052@host1.com>
+
+4.8.4.6 Uniform Resource Locator
+
+ Property Name: URL
+
+ Purpose: This property defines a Uniform Resource Locator (URL)
+ associated with the iCalendar object.
+
+ Value Type: URI
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 110]
+
+RFC 2445 iCalendar November 1998
+
+
+ Conformance: This property can be specified once in the "VEVENT",
+ "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
+
+ Description: This property may be used in a calendar component to
+ convey a location where a more dynamic rendition of the calendar
+ information associated with the calendar component can be found. This
+ memo does not attempt to standardize the form of the URI, nor the
+ format of the resource pointed to by the property value. If the URL
+ property and Content-Location MIME header are both specified, they
+ MUST point to the same resource.
+
+ Format Definition: The property is defined by the following notation:
+
+ url = "URL" urlparam ":" uri CRLF
+
+ urlparam = *(";" xparam)
+
+ Example: The following is an example of this property:
+
+ URL:http://abc.com/pub/calendars/jsmith/mytime.ics
+
+4.8.4.7 Unique Identifier
+
+ Property Name: UID
+
+ Purpose: This property defines the persistent, globally unique
+ identifier for the calendar component.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property MUST be specified in the "VEVENT", "VTODO",
+ "VJOURNAL" or "VFREEBUSY" calendar components.
+
+ Description: The UID itself MUST be a globally unique identifier. The
+ generator of the identifier MUST guarantee that the identifier is
+ unique. There are several algorithms that can be used to accomplish
+ this. The identifier is RECOMMENDED to be the identical syntax to the
+ [RFC 822] addr-spec. A good method to assure uniqueness is to put the
+ domain name or a domain literal IP address of the host on which the
+ identifier was created on the right hand side of the "@", and on the
+ left hand side, put a combination of the current calendar date and
+ time of day (i.e., formatted in as a DATE-TIME value) along with some
+ other currently unique (perhaps sequential) identifier available on
+ the system (for example, a process id number). Using a date/time
+ value on the left hand side and a domain name or domain literal on
+
+
+
+Dawson & Stenerson Standards Track [Page 111]
+
+RFC 2445 iCalendar November 1998
+
+
+ the right hand side makes it possible to guarantee uniqueness since
+ no two hosts should be using the same domain name or IP address at
+ the same time. Though other algorithms will work, it is RECOMMENDED
+ that the right hand side contain some domain identifier (either of
+ the host itself or otherwise) such that the generator of the message
+ identifier can guarantee the uniqueness of the left hand side within
+ the scope of that domain.
+
+ This is the method for correlating scheduling messages with the
+ referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
+
+ The full range of calendar components specified by a recurrence set
+ is referenced by referring to just the "UID" property value
+ corresponding to the calendar component. The "RECURRENCE-ID" property
+ allows the reference to an individual instance within the recurrence
+ set.
+
+ This property is an important method for group scheduling
+ applications to match requests with later replies, modifications or
+ deletion requests. Calendaring and scheduling applications MUST
+ generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar
+ components to assure interoperability with other group scheduling
+ applications. This identifier is created by the calendar system that
+ generates an iCalendar object.
+
+ Implementations MUST be able to receive and persist values of at
+ least 255 characters for this property.
+
+ Format Definition: The property is defined by the following notation:
+
+ uid = "UID" uidparam ":" text CRLF
+
+ uidparam = *(";" xparam)
+
+ Example: The following is an example of this property:
+
+ UID:19960401T080045Z-4000F192713-0052@host1.com
+
+4.8.5 Recurrence Component Properties
+
+ The following properties specify recurrence information in calendar
+ components.
+
+4.8.5.1 Exception Date/Times
+
+ Property Name: EXDATE
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 112]
+
+RFC 2445 iCalendar November 1998
+
+
+ Purpose: This property defines the list of date/time exceptions for a
+ recurring calendar component.
+
+ Value Type: The default value type for this property is DATE-TIME.
+ The value type can be set to DATE.
+
+ Property Parameters: Non-standard, value data type and time zone
+ identifier property parameters can be specified on this property.
+
+ Conformance: This property can be specified in an iCalendar object
+ that includes a recurring calendar component.
+
+ Description: The exception dates, if specified, are used in computing
+ the recurrence set. The recurrence set is the complete set of
+ recurrence instances for a calendar component. The recurrence set is
+ generated by considering the initial "DTSTART" property along with
+ the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+ within the iCalendar object. The "DTSTART" property defines the first
+ instance in the recurrence set. Multiple instances of the "RRULE" and
+ "EXRULE" properties can also be specified to define more
+ sophisticated recurrence sets. The final recurrence set is generated
+ by gathering all of the start date-times generated by any of the
+ specified "RRULE" and "RDATE" properties, and then excluding any
+ start date and times which fall within the union of start date and
+ times generated by any specified "EXRULE" and "EXDATE" properties.
+ This implies that start date and times within exclusion related
+ properties (i.e., "EXDATE" and "EXRULE") take precedence over those
+ specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where
+ duplicate instances are generated by the "RRULE" and "RDATE"
+ properties, only one recurrence is considered. Duplicate instances
+ are ignored.
+
+ The "EXDATE" property can be used to exclude the value specified in
+ "DTSTART". However, in such cases the original "DTSTART" date MUST
+ still be maintained by the calendaring and scheduling system because
+ the original "DTSTART" value has inherent usage dependencies by other
+ properties such as the "RECURRENCE-ID".
+
+ Format Definition: The property is defined by the following notation:
+
+ exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
+
+ exdtparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+
+
+
+Dawson & Stenerson Standards Track [Page 113]
+
+RFC 2445 iCalendar November 1998
+
+
+ (";" tzidparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ exdtval = date-time / date
+ ;Value MUST match value type
+
+ Example: The following is an example of this property:
+
+ EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
+
+4.8.5.2 Exception Rule
+
+ Property Name: EXRULE
+
+ Purpose: This property defines a rule or repeating pattern for an
+ exception to a recurrence set.
+
+ Value Type: RECUR
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in "VEVENT", "VTODO" or
+ "VJOURNAL" calendar components.
+
+ Description: The exception rule, if specified, is used in computing
+ the recurrence set. The recurrence set is the complete set of
+ recurrence instances for a calendar component. The recurrence set is
+ generated by considering the initial "DTSTART" property along with
+ the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+ within the iCalendar object. The "DTSTART" defines the first instance
+ in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
+ properties can also be specified to define more sophisticated
+ recurrence sets. The final recurrence set is generated by gathering
+ all of the start date-times generated by any of the specified "RRULE"
+ and "RDATE" properties, and excluding any start date and times which
+ fall within the union of start date and times generated by any
+ specified "EXRULE" and "EXDATE" properties. This implies that start
+ date and times within exclusion related properties (i.e., "EXDATE"
+ and "EXRULE") take precedence over those specified by inclusion
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 114]
+
+RFC 2445 iCalendar November 1998
+
+
+ properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
+ generated by the "RRULE" and "RDATE" properties, only one recurrence
+ is considered. Duplicate instances are ignored.
+
+ The "EXRULE" property can be used to exclude the value specified in
+ "DTSTART". However, in such cases the original "DTSTART" date MUST
+ still be maintained by the calendaring and scheduling system because
+ the original "DTSTART" value has inherent usage dependencies by other
+ properties such as the "RECURRENCE-ID".
+
+ Format Definition: The property is defined by the following notation:
+
+ exrule = "EXRULE" exrparam ":" recur CRLF
+
+ exrparam = *(";" xparam)
+
+ Example: The following are examples of this property. Except every
+ other week, on Tuesday and Thursday for 4 occurrences:
+
+ EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH
+
+ Except daily for 10 occurrences:
+
+ EXRULE:FREQ=DAILY;COUNT=10
+
+ Except yearly in June and July for 8 occurrences:
+
+ EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7
+
+4.8.5.3 Recurrence Date/Times
+
+ Property Name: RDATE
+
+ Purpose: This property defines the list of date/times for a
+ recurrence set.
+
+ Value Type: The default value type for this property is DATE-TIME.
+ The value type can be set to DATE or PERIOD.
+
+ Property Parameters: Non-standard, value data type and time zone
+ identifier property parameters can be specified on this property.
+
+ Conformance: The property can be specified in "VEVENT", "VTODO",
+ "VJOURNAL" or "VTIMEZONE" calendar components.
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 115]
+
+RFC 2445 iCalendar November 1998
+
+
+ Description: This property can appear along with the "RRULE" property
+ to define an aggregate set of repeating occurrences. When they both
+ appear in an iCalendar object, the recurring events are defined by
+ the union of occurrences defined by both the "RDATE" and "RRULE".
+
+ The recurrence dates, if specified, are used in computing the
+ recurrence set. The recurrence set is the complete set of recurrence
+ instances for a calendar component. The recurrence set is generated
+ by considering the initial "DTSTART" property along with the "RRULE",
+ "RDATE", "EXDATE" and "EXRULE" properties contained within the
+ iCalendar object. The "DTSTART" property defines the first instance
+ in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
+ properties can also be specified to define more sophisticated
+ recurrence sets. The final recurrence set is generated by gathering
+ all of the start date/times generated by any of the specified "RRULE"
+ and "RDATE" properties, and excluding any start date/times which fall
+ within the union of start date/times generated by any specified
+ "EXRULE" and "EXDATE" properties. This implies that start date/times
+ within exclusion related properties (i.e., "EXDATE" and "EXRULE")
+ take precedence over those specified by inclusion properties (i.e.,
+ "RDATE" and "RRULE"). Where duplicate instances are generated by the
+ "RRULE" and "RDATE" properties, only one recurrence is considered.
+ Duplicate instances are ignored.
+
+ Format Definition: The property is defined by the following notation:
+
+ rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
+
+ rdtparam = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
+ (";" tzidparam) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ rdtval = date-time / date / period
+ ;Value MUST match value type
+
+ Example: The following are examples of this property:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 116]
+
+RFC 2445 iCalendar November 1998
+
+
+ RDATE:19970714T123000Z
+
+ RDATE;TZID=US-EASTERN:19970714T083000
+
+ RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
+ 19960404T010000Z/PT3H
+
+ RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
+ 19970526,19970704,19970901,19971014,19971128,19971129,19971225
+
+4.8.5.4 Recurrence Rule
+
+ Property Name: RRULE
+
+ Purpose: This property defines a rule or repeating pattern for
+ recurring events, to-dos, or time zone definitions.
+
+ Value Type: RECUR
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified one or more times in
+ recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It
+ can also be specified once in each STANDARD or DAYLIGHT sub-component
+ of the "VTIMEZONE" calendar component.
+
+ Description: The recurrence rule, if specified, is used in computing
+ the recurrence set. The recurrence set is the complete set of
+ recurrence instances for a calendar component. The recurrence set is
+ generated by considering the initial "DTSTART" property along with
+ the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+ within the iCalendar object. The "DTSTART" property defines the first
+ instance in the recurrence set. Multiple instances of the "RRULE" and
+ "EXRULE" properties can also be specified to define more
+ sophisticated recurrence sets. The final recurrence set is generated
+ by gathering all of the start date/times generated by any of the
+ specified "RRULE" and "RDATE" properties, and excluding any start
+ date/times which fall within the union of start date/times generated
+ by any specified "EXRULE" and "EXDATE" properties. This implies that
+ start date/times within exclusion related properties (i.e., "EXDATE"
+ and "EXRULE") take precedence over those specified by inclusion
+ properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
+ generated by the "RRULE" and "RDATE" properties, only one recurrence
+ is considered. Duplicate instances are ignored.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 117]
+
+RFC 2445 iCalendar November 1998
+
+
+ The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
+ property pair, specified within the iCalendar object defines the
+ first instance of the recurrence. When used with a recurrence rule,
+ the "DTSTART" and "DTEND" properties MUST be specified in local time
+ and the appropriate set of "VTIMEZONE" calendar components MUST be
+ included. For detail on the usage of the "VTIMEZONE" calendar
+ component, see the "VTIMEZONE" calendar component definition.
+
+ Any duration associated with the iCalendar object applies to all
+ members of the generated recurrence set. Any modified duration for
+ specific recurrences MUST be explicitly specified using the "RDATE"
+ property.
+
+ Format Definition: This property is defined by the following
+ notation:
+
+ rrule = "RRULE" rrulparam ":" recur CRLF
+
+ rrulparam = *(";" xparam)
+
+ Example: All examples assume the Eastern United States time zone.
+
+ Daily for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=DAILY;COUNT=10
+
+ ==> (1997 9:00 AM EDT)September 2-11
+
+ Daily until December 24, 1997:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
+
+ ==> (1997 9:00 AM EDT)September 2-30;October 1-25
+ (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
+
+ Every other day - forever:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=DAILY;INTERVAL=2
+ ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30;
+ October 2,4,6...20,22,24
+ (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
+ Dec 1,3,...
+
+ Every 10 days, 5 occurrences:
+
+
+
+
+Dawson & Stenerson Standards Track [Page 118]
+
+RFC 2445 iCalendar November 1998
+
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
+
+ ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
+
+ Everyday in January, for 3 years:
+
+ DTSTART;TZID=US-Eastern:19980101T090000
+ RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
+ BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
+ or
+ RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
+
+ ==> (1998 9:00 AM EDT)January 1-31
+ (1999 9:00 AM EDT)January 1-31
+ (2000 9:00 AM EDT)January 1-31
+
+ Weekly for 10 occurrences
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;COUNT=10
+
+ ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
+ (1997 9:00 AM EST)October 28;November 4
+
+ Weekly until December 24, 1997
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
+
+ ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
+ (1997 9:00 AM EST)October 28;November 4,11,18,25;
+ December 2,9,16,23
+ Every other week - forever:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
+
+ ==> (1997 9:00 AM EDT)September 2,16,30;October 14
+ (1997 9:00 AM EST)October 28;November 11,25;December 9,23
+ (1998 9:00 AM EST)January 6,20;February
+ ...
+
+ Weekly on Tuesday and Thursday for 5 weeks:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
+ or
+
+
+
+Dawson & Stenerson Standards Track [Page 119]
+
+RFC 2445 iCalendar November 1998
+
+
+ RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
+
+ ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
+
+ Every other week on Monday, Wednesday and Friday until December 24,
+ 1997, but starting on Tuesday, September 2, 1997:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
+ BYDAY=MO,WE,FR
+ ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
+ 1,3,13,15,17
+ (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
+ December 8,10,12,22
+
+ Every other week on Tuesday and Thursday, for 8 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
+
+ ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
+
+ Monthly on the 1st Friday for ten occurrences:
+
+ DTSTART;TZID=US-Eastern:19970905T090000
+ RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
+
+ ==> (1997 9:00 AM EDT)September 5;October 3
+ (1997 9:00 AM EST)November 7;Dec 5
+ (1998 9:00 AM EST)January 2;February 6;March 6;April 3
+ (1998 9:00 AM EDT)May 1;June 5
+
+ Monthly on the 1st Friday until December 24, 1997:
+
+ DTSTART;TZID=US-Eastern:19970905T090000
+ RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
+
+ ==> (1997 9:00 AM EDT)September 5;October 3
+ (1997 9:00 AM EST)November 7;December 5
+
+ Every other month on the 1st and last Sunday of the month for 10
+ occurrences:
+
+ DTSTART;TZID=US-Eastern:19970907T090000
+ RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
+
+ ==> (1997 9:00 AM EDT)September 7,28
+ (1997 9:00 AM EST)November 2,30
+
+
+
+Dawson & Stenerson Standards Track [Page 120]
+
+RFC 2445 iCalendar November 1998
+
+
+ (1998 9:00 AM EST)January 4,25;March 1,29
+ (1998 9:00 AM EDT)May 3,31
+
+ Monthly on the second to last Monday of the month for 6 months:
+
+ DTSTART;TZID=US-Eastern:19970922T090000
+ RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
+
+ ==> (1997 9:00 AM EDT)September 22;October 20
+ (1997 9:00 AM EST)November 17;December 22
+ (1998 9:00 AM EST)January 19;February 16
+
+ Monthly on the third to the last day of the month, forever:
+
+ DTSTART;TZID=US-Eastern:19970928T090000
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
+
+ ==> (1997 9:00 AM EDT)September 28
+ (1997 9:00 AM EST)October 29;November 28;December 29
+ (1998 9:00 AM EST)January 29;February 26
+ ...
+
+ Monthly on the 2nd and 15th of the month for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
+
+ ==> (1997 9:00 AM EDT)September 2,15;October 2,15
+ (1997 9:00 AM EST)November 2,15;December 2,15
+ (1998 9:00 AM EST)January 2,15
+
+ Monthly on the first and last day of the month for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970930T090000
+ RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
+
+ ==> (1997 9:00 AM EDT)September 30;October 1
+ (1997 9:00 AM EST)October 31;November 1,30;December 1,31
+ (1998 9:00 AM EST)January 1,31;February 1
+
+ Every 18 months on the 10th thru 15th of the month for 10
+ occurrences:
+
+ DTSTART;TZID=US-Eastern:19970910T090000
+ RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
+ 15
+
+ ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
+
+
+
+Dawson & Stenerson Standards Track [Page 121]
+
+RFC 2445 iCalendar November 1998
+
+
+ (1999 9:00 AM EST)March 10,11,12,13
+
+ Every Tuesday, every other month:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
+
+ ==> (1997 9:00 AM EDT)September 2,9,16,23,30
+ (1997 9:00 AM EST)November 4,11,18,25
+ (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
+ ...
+
+ Yearly in June and July for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970610T090000
+ RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
+ ==> (1997 9:00 AM EDT)June 10;July 10
+ (1998 9:00 AM EDT)June 10;July 10
+ (1999 9:00 AM EDT)June 10;July 10
+ (2000 9:00 AM EDT)June 10;July 10
+ (2001 9:00 AM EDT)June 10;July 10
+ Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
+ are specified, the day is gotten from DTSTART
+
+ Every other year on January, February, and March for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970310T090000
+ RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
+
+ ==> (1997 9:00 AM EST)March 10
+ (1999 9:00 AM EST)January 10;February 10;March 10
+ (2001 9:00 AM EST)January 10;February 10;March 10
+ (2003 9:00 AM EST)January 10;February 10;March 10
+
+ Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970101T090000
+ RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
+
+ ==> (1997 9:00 AM EST)January 1
+ (1997 9:00 AM EDT)April 10;July 19
+ (2000 9:00 AM EST)January 1
+ (2000 9:00 AM EDT)April 9;July 18
+ (2003 9:00 AM EST)January 1
+ (2003 9:00 AM EDT)April 10;July 19
+ (2006 9:00 AM EST)January 1
+
+ Every 20th Monday of the year, forever:
+
+
+
+Dawson & Stenerson Standards Track [Page 122]
+
+RFC 2445 iCalendar November 1998
+
+
+ DTSTART;TZID=US-Eastern:19970519T090000
+ RRULE:FREQ=YEARLY;BYDAY=20MO
+
+ ==> (1997 9:00 AM EDT)May 19
+ (1998 9:00 AM EDT)May 18
+ (1999 9:00 AM EDT)May 17
+ ...
+
+ Monday of week number 20 (where the default start of the week is
+ Monday), forever:
+
+ DTSTART;TZID=US-Eastern:19970512T090000
+ RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
+
+ ==> (1997 9:00 AM EDT)May 12
+ (1998 9:00 AM EDT)May 11
+ (1999 9:00 AM EDT)May 17
+ ...
+
+ Every Thursday in March, forever:
+
+ DTSTART;TZID=US-Eastern:19970313T090000
+ RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
+
+ ==> (1997 9:00 AM EST)March 13,20,27
+ (1998 9:00 AM EST)March 5,12,19,26
+ (1999 9:00 AM EST)March 4,11,18,25
+ ...
+
+ Every Thursday, but only during June, July, and August, forever:
+
+ DTSTART;TZID=US-Eastern:19970605T090000
+ RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
+
+ ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
+ August 7,14,21,28
+ (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
+ August 6,13,20,27
+ (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
+ August 5,12,19,26
+ ...
+
+ Every Friday the 13th, forever:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ EXDATE;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
+
+
+
+
+Dawson & Stenerson Standards Track [Page 123]
+
+RFC 2445 iCalendar November 1998
+
+
+ ==> (1998 9:00 AM EST)February 13;March 13;November 13
+ (1999 9:00 AM EDT)August 13
+ (2000 9:00 AM EDT)October 13
+ ...
+
+ The first Saturday that follows the first Sunday of the month,
+ forever:
+
+ DTSTART;TZID=US-Eastern:19970913T090000
+ RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
+
+ ==> (1997 9:00 AM EDT)September 13;October 11
+ (1997 9:00 AM EST)November 8;December 13
+ (1998 9:00 AM EST)January 10;February 7;March 7
+ (1998 9:00 AM EDT)April 11;May 9;June 13...
+ ...
+
+ Every four years, the first Tuesday after a Monday in November,
+ forever (U.S. Presidential Election day):
+
+ DTSTART;TZID=US-Eastern:19961105T090000
+ RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
+ 5,6,7,8
+
+ ==> (1996 9:00 AM EST)November 5
+ (2000 9:00 AM EST)November 7
+ (2004 9:00 AM EST)November 2
+ ...
+
+ The 3rd instance into the month of one of Tuesday, Wednesday or
+ Thursday, for the next 3 months:
+
+ DTSTART;TZID=US-Eastern:19970904T090000
+ RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
+
+ ==> (1997 9:00 AM EDT)September 4;October 7
+ (1997 9:00 AM EST)November 6
+
+ The 2nd to last weekday of the month:
+
+ DTSTART;TZID=US-Eastern:19970929T090000
+ RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
+
+ ==> (1997 9:00 AM EDT)September 29
+ (1997 9:00 AM EST)October 30;November 27;December 30
+ (1998 9:00 AM EST)January 29;February 26;March 30
+ ...
+
+
+
+
+Dawson & Stenerson Standards Track [Page 124]
+
+RFC 2445 iCalendar November 1998
+
+
+ Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
+
+ ==> (September 2, 1997 EDT)09:00,12:00,15:00
+
+ Every 15 minutes for 6 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
+
+ ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
+
+ Every hour and a half for 4 occurrences:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
+
+ ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
+
+ Every 20 minutes from 9:00 AM to 4:40 PM every day:
+
+ DTSTART;TZID=US-Eastern:19970902T090000
+ RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
+ or
+ RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
+
+ ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
+ ... 16:00,16:20,16:40
+ (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
+ ...16:00,16:20,16:40
+ ...
+
+ An example where the days generated makes a difference because of
+ WKST:
+
+ DTSTART;TZID=US-Eastern:19970805T090000
+ RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
+
+ ==> (1997 EDT)Aug 5,10,19,24
+
+ changing only WKST from MO to SU, yields different results...
+
+ DTSTART;TZID=US-Eastern:19970805T090000
+ RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
+ ==> (1997 EDT)August 5,17,19,31
+
+
+
+
+Dawson & Stenerson Standards Track [Page 125]
+
+RFC 2445 iCalendar November 1998
+
+
+4.8.6 Alarm Component Properties
+
+ The following properties specify alarm information in calendar
+ components.
+
+4.8.6.1 Action
+
+ Property Name: ACTION
+
+ Purpose: This property defines the action to be invoked when an alarm
+ is triggered.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property MUST be specified once in a "VALARM"
+ calendar component.
+
+ Description: Each "VALARM" calendar component has a particular type
+ of action associated with it. This property specifies the type of
+ action
+
+ Format Definition: The property is defined by the following notation:
+
+ action = "ACTION" actionparam ":" actionvalue CRLF
+
+ actionparam = *(";" xparam)
+
+ actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
+ / iana-token / x-name
+
+ Example: The following are examples of this property in a "VALARM"
+ calendar component:
+
+ ACTION:AUDIO
+
+ ACTION:DISPLAY
+
+ ACTION:PROCEDURE
+
+4.8.6.2 Repeat Count
+
+ Property Name: REPEAT
+
+ Purpose: This property defines the number of time the alarm should be
+ repeated, after the initial trigger.
+
+
+
+Dawson & Stenerson Standards Track [Page 126]
+
+RFC 2445 iCalendar November 1998
+
+
+ Value Type: INTEGER
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in a "VALARM" calendar
+ component.
+
+ Description: If the alarm triggers more than once, then this property
+ MUST be specified along with the "DURATION" property.
+
+ Format Definition: The property is defined by the following notation:
+
+ repeatcnt = "REPEAT" repparam ":" integer CRLF
+ ;Default is "0", zero.
+
+ repparam = *(";" xparam)
+
+ Example: The following is an example of this property for an alarm
+ that repeats 4 additional times with a 5 minute delay after the
+ initial triggering of the alarm:
+
+ REPEAT:4
+ DURATION:PT5M
+
+4.8.6.3 Trigger
+
+ Property Name: TRIGGER
+
+ Purpose: This property specifies when an alarm will trigger.
+
+ Value Type: The default value type is DURATION. The value type can be
+ set to a DATE-TIME value type, in which case the value MUST specify a
+ UTC formatted DATE-TIME value.
+
+ Property Parameters: Non-standard, value data type, time zone
+ identifier or trigger relationship property parameters can be
+ specified on this property. The trigger relationship property
+ parameter MUST only be specified when the value type is DURATION.
+
+ Conformance: This property MUST be specified in the "VALARM" calendar
+ component.
+
+ Description: Within the "VALARM" calendar component, this property
+ defines when the alarm will trigger. The default value type is
+ DURATION, specifying a relative time for the trigger of the alarm.
+ The default duration is relative to the start of an event or to-do
+ that the alarm is associated with. The duration can be explicitly set
+
+
+
+Dawson & Stenerson Standards Track [Page 127]
+
+RFC 2445 iCalendar November 1998
+
+
+ to trigger from either the end or the start of the associated event
+ or to-do with the "RELATED" parameter. A value of START will set the
+ alarm to trigger off the start of the associated event or to-do. A
+ value of END will set the alarm to trigger off the end of the
+ associated event or to-do.
+
+ Either a positive or negative duration may be specified for the
+ "TRIGGER" property. An alarm with a positive duration is triggered
+ after the associated start or end of the event or to-do. An alarm
+ with a negative duration is triggered before the associated start or
+ end of the event or to-do.
+
+ The "RELATED" property parameter is not valid if the value type of
+ the property is set to DATE-TIME (i.e., for an absolute date and time
+ alarm trigger). If a value type of DATE-TIME is specified, then the
+ property value MUST be specified in the UTC time format. If an
+ absolute trigger is specified on an alarm for a recurring event or
+ to-do, then the alarm will only trigger for the specified absolute
+ date/time, along with any specified repeating instances.
+
+ If the trigger is set relative to START, then the "DTSTART" property
+ MUST be present in the associated "VEVENT" or "VTODO" calendar
+ component. If an alarm is specified for an event with the trigger set
+ relative to the END, then the "DTEND" property or the "DSTART" and
+ "DURATION' properties MUST be present in the associated "VEVENT"
+ calendar component. If the alarm is specified for a to-do with a
+ trigger set relative to the END, then either the "DUE" property or
+ the "DSTART" and "DURATION' properties MUST be present in the
+ associated "VTODO" calendar component.
+
+ Alarms specified in an event or to-do which is defined in terms of a
+ DATE value type will be triggered relative to 00:00:00 UTC on the
+ specified date. For example, if "DTSTART:19980205, then the duration
+ trigger will be relative to19980205T000000Z.
+
+ Format Definition: The property is defined by the following notation:
+
+ trigger = "TRIGGER" (trigrel / trigabs)
+
+ trigrel = *(
+
+ ; the following are optional,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" "DURATION") /
+ (";" trigrelparam) /
+
+ ; the following is optional,
+
+
+
+Dawson & Stenerson Standards Track [Page 128]
+
+RFC 2445 iCalendar November 1998
+
+
+ ; and MAY occur more than once
+
+ (";" xparam)
+ ) ":" dur-value
+
+ trigabs = 1*(
+
+ ; the following is REQUIRED,
+ ; but MUST NOT occur more than once
+
+ (";" "VALUE" "=" "DATE-TIME") /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ ) ":" date-time
+
+ Example: A trigger set 15 minutes prior to the start of the event or
+ to-do.
+
+ TRIGGER:-P15M
+
+ A trigger set 5 minutes after the end of the event or to-do.
+
+ TRIGGER;RELATED=END:P5M
+
+ A trigger set to an absolute date/time.
+
+ TRIGGER;VALUE=DATE-TIME:19980101T050000Z
+
+4.8.7 Change Management Component Properties
+
+ The following properties specify change management information in
+ calendar components.
+
+4.8.7.1 Date/Time Created
+
+ Property Name: CREATED
+
+ Purpose: This property specifies the date and time that the calendar
+ information was created by the calendar user agent in the calendar
+ store.
+
+ Note: This is analogous to the creation date and time for a file
+ in the file system.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 129]
+
+RFC 2445 iCalendar November 1998
+
+
+ Value Type: DATE-TIME
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified once in "VEVENT", "VTODO"
+ or "VJOURNAL" calendar components.
+
+ Description: The date and time is a UTC value.
+
+ Format Definition: The property is defined by the following notation:
+
+ created = "CREATED" creaparam ":" date-time CRLF
+
+ creaparam = *(";" xparam)
+
+ Example: The following is an example of this property:
+
+ CREATED:19960329T133000Z
+
+4.8.7.2 Date/Time Stamp
+
+ Property Name: DTSTAMP
+
+ Purpose: The property indicates the date/time that the instance of
+ the iCalendar object was created.
+
+ Value Type: DATE-TIME
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property MUST be included in the "VEVENT", "VTODO",
+ "VJOURNAL" or "VFREEBUSY" calendar components.
+
+ Description: The value MUST be specified in the UTC time format.
+
+ This property is also useful to protocols such as [IMIP] that have
+ inherent latency issues with the delivery of content. This property
+ will assist in the proper sequencing of messages containing iCalendar
+ objects.
+
+ This property is different than the "CREATED" and "LAST-MODIFIED"
+ properties. These two properties are used to specify when the
+ particular calendar data in the calendar store was created and last
+ modified. This is different than when the iCalendar object
+ representation of the calendar service information was created or
+ last modified.
+
+
+
+Dawson & Stenerson Standards Track [Page 130]
+
+RFC 2445 iCalendar November 1998
+
+
+ Format Definition: The property is defined by the following notation:
+
+ dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
+
+ stmparam = *(";" xparam)
+
+ Example:
+
+ DTSTAMP:19971210T080000Z
+
+4.8.7.3 Last Modified
+
+ Property Name: LAST-MODIFIED
+
+ Purpose: The property specifies the date and time that the
+ information associated with the calendar component was last revised
+ in the calendar store.
+
+ Note: This is analogous to the modification date and time for a
+ file in the file system.
+
+ Value Type: DATE-TIME
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: This property can be specified in the "EVENT", "VTODO",
+ "VJOURNAL" or "VTIMEZONE" calendar components.
+
+ Description: The property value MUST be specified in the UTC time
+ format.
+
+ Format Definition: The property is defined by the following notation:
+
+ last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF
+
+ lstparam = *(";" xparam)
+
+ Example: The following is are examples of this property:
+
+ LAST-MODIFIED:19960817T133000Z
+
+4.8.7.4 Sequence Number
+
+ Property Name: SEQUENCE
+
+ Purpose: This property defines the revision sequence number of the
+ calendar component within a sequence of revisions.
+
+
+
+Dawson & Stenerson Standards Track [Page 131]
+
+RFC 2445 iCalendar November 1998
+
+
+ Value Type: integer
+
+ Property Parameters: Non-standard property parameters can be
+ specified on this property.
+
+ Conformance: The property can be specified in "VEVENT", "VTODO" or
+ "VJOURNAL" calendar component.
+
+ Description: When a calendar component is created, its sequence
+ number is zero (US-ASCII decimal 48). It is monotonically incremented
+ by the "Organizer's" CUA each time the "Organizer" makes a
+ significant revision to the calendar component. When the "Organizer"
+ makes changes to one of the following properties, the sequence number
+ MUST be incremented:
+
+ . "DTSTART"
+
+ . "DTEND"
+
+ . "DUE"
+
+ . "RDATE"
+
+ . "RRULE"
+
+ . "EXDATE"
+
+ . "EXRULE"
+
+ . "STATUS"
+
+ In addition, changes made by the "Organizer" to other properties can
+ also force the sequence number to be incremented. The "Organizer" CUA
+ MUST increment the sequence number when ever it makes changes to
+ properties in the calendar component that the "Organizer" deems will
+ jeopardize the validity of the participation status of the
+ "Attendees". For example, changing the location of a meeting from one
+ locale to another distant locale could effectively impact the
+ participation status of the "Attendees".
+
+ The "Organizer" includes this property in an iCalendar object that it
+ sends to an "Attendee" to specify the current version of the calendar
+ component.
+
+ The "Attendee" includes this property in an iCalendar object that it
+ sends to the "Organizer" to specify the version of the calendar
+ component that the "Attendee" is referring to.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 132]
+
+RFC 2445 iCalendar November 1998
+
+
+ A change to the sequence number is not the mechanism that an
+ "Organizer" uses to request a response from the "Attendees". The
+ "RSVP" parameter on the "ATTENDEE" property is used by the
+ "Organizer" to indicate that a response from the "Attendees" is
+ requested.
+
+ Format Definition: This property is defined by the following
+ notation:
+
+ seq = "SEQUENCE" seqparam ":" integer CRLF
+ ; Default is "0"
+
+ seqparam = *(";" xparam)
+
+ Example: The following is an example of this property for a calendar
+ component that was just created by the "Organizer".
+
+ SEQUENCE:0
+
+ The following is an example of this property for a calendar component
+ that has been revised two different times by the "Organizer".
+
+ SEQUENCE:2
+
+4.8.8 Miscellaneous Component Properties
+
+ The following properties specify information about a number of
+ miscellaneous features of calendar components.
+
+4.8.8.1 Non-standard Properties
+
+ Property Name: Any property name with a "X-" prefix
+
+ Purpose: This class of property provides a framework for defining
+ non-standard properties.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard and language property parameters
+ can be specified on this property.
+
+ Conformance: This property can be specified in any calendar
+ component.
+
+ Description: The MIME Calendaring and Scheduling Content Type
+ provides a "standard mechanism for doing non-standard things". This
+ extension support is provided for implementers to "push the envelope"
+ on the existing version of the memo. Extension properties are
+
+
+
+Dawson & Stenerson Standards Track [Page 133]
+
+RFC 2445 iCalendar November 1998
+
+
+ specified by property and/or property parameter names that have the
+ prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER
+ X character followed by the HYPEN-MINUS character). It is recommended
+ that vendors concatenate onto this sentinel another short prefix text
+ to identify the vendor. This will facilitate readability of the
+ extensions and minimize possible collision of names between different
+ vendors. User agents that support this content type are expected to
+ be able to parse the extension properties and property parameters but
+ can ignore them.
+
+ At present, there is no registration authority for names of extension
+ properties and property parameters. The data type for this property
+ is TEXT. Optionally, the data type can be any of the other valid data
+ types.
+
+ Format Definition: The property is defined by the following notation:
+
+ x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF
+ ; Lines longer than 75 octets should be folded
+
+ Example: The following might be the ABC vendor's extension for an
+ audio-clip form of subject property:
+
+ X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
+
+4.8.8.2 Request Status
+
+ Property Name: REQUEST-STATUS
+
+ Purpose: This property defines the status code returned for a
+ scheduling request.
+
+ Value Type: TEXT
+
+ Property Parameters: Non-standard and language property parameters
+ can be specified on this property.
+
+ Conformance: The property can be specified in "VEVENT", "VTODO",
+ "VJOURNAL" or "VFREEBUSY" calendar component.
+
+ Description: This property is used to return status code information
+ related to the processing of an associated iCalendar object. The data
+ type for this property is TEXT.
+
+ The value consists of a short return status component, a longer
+ return status description component, and optionally a status-specific
+ data component. The components of the value are separated by the
+ SEMICOLON character (US-ASCII decimal 59).
+
+
+
+Dawson & Stenerson Standards Track [Page 134]
+
+RFC 2445 iCalendar November 1998
+
+
+ The short return status is a PERIOD character (US-ASCII decimal 46)
+ separated 3-tuple of integers. For example, "3.1.1". The successive
+ levels of integers provide for a successive level of status code
+ granularity.
+
+ The following are initial classes for the return status code.
+ Individual iCalendar object methods will define specific return
+ status codes for these classes. In addition, other classes for the
+ return status code may be defined using the registration process
+ defined later in this memo.
+
+ |==============+===============================================|
+ | Short Return | Longer Return Status Description |
+ | Status Code | |
+ |==============+===============================================|
+ | 1.xx | Preliminary success. This class of status |
+ | | of status code indicates that the request has |
+ | | request has been initially processed but that |
+ | | completion is pending. |
+ |==============+===============================================|
+ | 2.xx | Successful. This class of status code |
+ | | indicates that the request was completed |
+ | | successfuly. However, the exact status code |
+ | | can indicate that a fallback has been taken. |
+ |==============+===============================================|
+ | 3.xx | Client Error. This class of status code |
+ | | indicates that the request was not successful.|
+ | | The error is the result of either a syntax or |
+ | | a semantic error in the client formatted |
+ | | request. Request should not be retried until |
+ | | the condition in the request is corrected. |
+ |==============+===============================================|
+ | 4.xx | Scheduling Error. This class of status code |
+ | | indicates that the request was not successful.|
+ | | Some sort of error occurred within the |
+ | | calendaring and scheduling service, not |
+ | | directly related to the request itself. |
+ |==============+===============================================|
+
+ Format Definition: The property is defined by the following notation:
+
+ rstatus = "REQUEST-STATUS" rstatparam ":"
+ statcode ";" statdesc [";" extdata]
+
+ rstatparam = *(
+
+ ; the following is optional,
+ ; but MUST NOT occur more than once
+
+
+
+Dawson & Stenerson Standards Track [Page 135]
+
+RFC 2445 iCalendar November 1998
+
+
+ (";" languageparm) /
+
+ ; the following is optional,
+ ; and MAY occur more than once
+
+ (";" xparam)
+
+ )
+
+ statcode = 1*DIGIT *("." 1*DIGIT)
+ ;Hierarchical, numeric return status code
+
+ statdesc = text
+ ;Textual status description
+
+ extdata = text
+ ;Textual exception data. For example, the offending property
+ ;name and value or complete property line.
+
+ Example: The following are some possible examples of this property.
+ The COMMA and SEMICOLON separator characters in the property value
+ are BACKSLASH character escaped because they appear in a text value.
+
+ REQUEST-STATUS:2.0;Success
+
+ REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
+
+ REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
+ as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
+
+ REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
+
+ REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
+ MAILTO:jsmith@host.com
+
+5 iCalendar Object Examples
+
+ The following examples are provided as an informational source of
+ illustrative iCalendar objects consistent with this content type.
+
+ The following example specifies a three-day conference that begins at
+ 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
+ 1996.
+
+ BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
+ 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
+ UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
+ DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
+
+
+
+Dawson & Stenerson Standards Track [Page 136]
+
+RFC 2445 iCalendar November 1998
+
+
+ CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
+ DESCRIPTION:Networld+Interop Conference
+ and Exhibit\nAtlanta World Congress Center\n
+ Atlanta, Georgia END:VEVENT END:VCALENDAR
+
+ The following example specifies a group scheduled meeting that begin
+ at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
+ 1998. The "Organizer" has scheduled the meeting with one or more
+ calendar users in a group. A time zone specification for Eastern
+ United States has been specified.
+
+ BEGIN:VCALENDAR
+ PRODID:-//RDU Software//NONSGML HandCal//EN
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ TZID:US-Eastern
+ BEGIN:STANDARD
+ DTSTART:19981025T020000
+ RDATE:19981025T020000
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:EST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19990404T020000
+ 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
+
+
+
+
+Dawson & Stenerson Standards Track [Page 137]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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
+
+
+
+Dawson & Stenerson Standards Track [Page 138]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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
+
+
+
+Dawson & Stenerson Standards Track [Page 139]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 140]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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 RFC defining 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.
+
+
+
+Dawson & Stenerson Standards Track [Page 141]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 142]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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
+
+
+
+Dawson & Stenerson Standards Track [Page 143]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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)", RFC 2447,
+ 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", RFC 2446, 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.
+
+ [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822, August 1982.
+
+ [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC 1766] Alvestrand, H., "Tags for the Identification of
+ Languages", RFC 1766, March 1995.
+
+ [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
+ Extensions (MIME) - Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
+ Extensions (MIME) - Part Two: Media Types", RFC 2046,
+ November 1996.
+
+
+
+
+Dawson & Stenerson Standards Track [Page 144]
+
+RFC 2445 iCalendar November 1998
+
+
+ [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) - Part Four: Registration
+ Procedures", RFC 2048, January 1997.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
+ for Directory Information", RFC 2425, September 1998.
+
+ [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+ RFC 2426, 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.
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 145]
+
+RFC 2445 iCalendar November 1998
+
+
+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
+
+
+
+
+Dawson & Stenerson Standards Track [Page 146]
+
+RFC 2445 iCalendar November 1998
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 147]
+
+RFC 2445 iCalendar November 1998
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson Standards Track [Page 148]
+