libical

A simple ical library.
git clone git://r-36.net/libical
Log | Files | Refs | LICENSE

commit bccaa1ea3b33f47b4be6de3745635d5378ab4016
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(-)

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"), +to deal in the Software without restriction, including without limitation +the 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. 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} + +test: 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 diff --git a/README.md b/README.md @@ -0,0 +1,9 @@ +# A simple ical library + +## Usage + +see icaltest.c + + +Have fun! + 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 + 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 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 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; +} + 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__ + +typedef struct vitemprop_t vitemprop_t; +struct vitemprop_t { + vitemprop_t *next; + vitemprop_t *prev; + + char *name; + char *params; + char *value; +}; + +typedef struct vitem_t vitem_t; +struct vitem_t { + vitem_t *next; + vitem_t *prev; + + char *type; + + vitemprop_t *props; + vitemprop_t *lastp; + int nprops; +}; + +typedef 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 + 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; +} + 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; +} + 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 + 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] +