event_uri.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc docName="draft-menderico-v-event-uri-00" category="info">
  <front>
    <title abbrev="v-event URI">
      v-event URI: An URI scheme for events.
    </title>
    <author initials="R." surname="Menderico"
            fullname="Raphael Menderico" role="editor">
      <organization abbrev="Google">
	Google Inc.
      </organization>
      <address>
	<postal>
          <street>Brandschenkestrasse 110</street>
          <city>Zurich</city> <region>ZH</region>
          <code>8002</code>
          <country>CH</country>
	</postal>
	<email>menderico@google.com</email>
	<uri>http://www.google.com/</uri>
      </address>
    </author>
    <author initials="P." surname="Schlup"
            fullname="Paulo Schlup">
      <organization abbrev="Google">
	Google Inc.
      </organization>
      <address>
	<postal>
          <street>Brandschenkestrasse 110</street>
          <city>Zurich</city> <region>ZH</region>
          <code>8002</code>
          <country>CH</country>
	</postal>
	<email>pschlup@google.com</email>
	<uri>http://www.google.com/</uri>
      </address>
    </author>
    <author initials="L." surname="Kristiansen"
            fullname="Lucia Kristiansen">
      <organization abbrev="Google">
	Google Inc.
      </organization>
      <address>
	<postal>
          <street>Brandschenkestrasse 110</street>
          <city>Zurich</city> <region>ZH</region>
          <code>8002</code>
          <country>CH</country>
	</postal>
	<email>lucka@google.com</email>
	<uri>http://www.google.com/</uri>
      </address>
    </author>
    <date day="24" month="November" year="2015"/>
    <area>Internet</area>
    <keyword>Calendar</keyword>
    <keyword>iCal</keyword>
    <keyword>URI</keyword>
    <keyword>QR code</keyword>
    <abstract>
      <t>
	This document defines the format of Uniform Resource
	Identifiers (URIs) for calendar events, allowing users to add
	these events to their calendar application from any source that
	defines them, like web sites and printed QR codes
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="section.intro" title="Introduction">
      <t>
	Calendar users currently often do not have the ability to
	quickly add an event to theirdefault calendar app, when
	encountering event data on a webpage, poster or mobile
	apps. In this sense events have fallen behind other real world
	entities, like e-mail <xref target="RFC6068"/> and geo
	coordinates <xref target="RFC5870"/> which allow for
	performing actions in default apps when encountering these
	entities anywhere. This recommendations document addresses the
	problem by proposing best practices when embedding and
	publishing calendar data. We believe that using a standardized
	URI scheme for event publishing will make populating of users’
	calendars much simpler, will make developers’ lives easier and
	will increase calendar apps usage in general. A major
	additional benefit of URIs is sharing of events on physical
	media (for example via QR codes) or via URL.</t>
    </section>
    <section anchor="section.motivation"
	     title="Motivation and related work">
      <section anchor="section.current"
	       title="Current event publishing practices">
	<t>
	  Many ways to add events to calendar apps have been developed
	  due to the lack of standardization. While these solve the
	  basic need of sharing events, it does so with limited reach,
	  are harder to use and limit adoption by new providers. We
	  will briefly mention four common ways: using a download
	  link, hCalendar embedding, using VEVENTs in QR codes and
	  provider specific buttons.
	</t>
	<section anchor="section.icalendar"
		 title="Publish a link to an iCalendar file">
	  <t>
	    A simple way to publish an event i sto share a link that
	    points to an iCalendar <xref target="RFC5545"/> file and
	    provide a link to the user for downloading it. In an ideal
	    world, a user would click on the link pointing to a file,
	    the browser would recognize this link as a calendar file
	    and redirect it to the proper calendar application, which
	    would display the event information to the user, allowing
	    simple edit actions, and saving it to the calendar.
	  </t>

	  <t>
	    There are many problems with this method. Files must be
	    hosted in a server, which is not always feasible or easy,
	    and need to be maintained separately from the web pages
	    they are linked from. This poses unnecessary difficulty
	    for blog and CMS users, especially when compared to
	    linking to email addresses or other web pages.</t>

	  <t>
	    Furthermore, ICS files might not be recognized by the
	    browser or operating system, or the user might use a
	    web-based calendar app instead of a native one. Files
	    might also contain malware and pose additional risk, with
	    some end users avoiding downloaded files altogether.</t>
	  
	  <t>
	    One additional problem is coupling of the file and the
	    entity it represents. Currently the user needs to manually
	    keep the event file and all the links and descriptions
	    with the same information in the links about in sync. It
	    is preferable to have this information close
	    together. Ideally the same tools used to generate a page
	    could be used to assure a link and the text information
	    being displayed are synchronized.
	  </t>
	</section>
	<section anchor="section.qr_readers"
		 title="Current QR code implementations">
	  <t>
	    Several QR code readers (<xref target="ZXing"/><xref
	    target="i-nigma"/>) support calendar events to be embedded
	    in QR codes, but they have their own non-standard
	    implementation, usually a single VEVENT iCalendar
	    component. They work well on the mobile platform but rely
	    on OS internals <xref target="CalendarContract"/> to add
	    the event to the calendar.
	  </t>
	  <t>
	    While QR code does not dictate a format for calendar
	    events, most readers implement the URI standard schemes
	    and would benefit from this proposal.
	  </t>
	</section>
	<section anchor="section.hcalendar" title="hCalendar">
	  <t>
	    hCalendar <xref target="hCalendar"/> is a microformat for
	    events that can be used to annotate a web page or another
	    document and indicate to readers that an event is
	    present. While microformats are useful for parsing and
	    styling, they are not meant to be used as links to an
	    event and need to be used in conjunction with the external
	    ICS file method or a proprietary browser extension. They
	    usually require a complex interaction between the website
	    and the calendar application to get it right. This also
	    makes it not ideal for QR scanning, since the annotations
	    were not designed to represent the whole content of a
	    document. They are more appropriate as an annotation on a
	    previously structured text.
	  </t>
	</section>
	<section anchor="section.custom_link"
		 title="Custom calendar application link">
	  <t>
	    Several calendar systems provide a proprietary URL for
	    event creation (<xref target="AddThisEvent"/><xref
	    target="GoogleCalendar"/>). However, due to lack of
	    standards, applications must implement and link to these
	    separately. This burdens both content creators and web
	    site users: content creators must maintain individual
	    links for each calendar application provider, and end
	    users must find and choose the appropriate one for their
	    own case. This consumes precious space on the page and
	    requires understanding of several APIs, making it
	    difficult for a developer that wants to just publish a
	    simple event. Furthermore, it's impossible to link to all
	    calendar app providers, requiring a combination of this
	    method with the ICS file hosting method.
	  </t>
	</section>
      </section>
      <section anchor="section.possible_impls"
	       title="Alternative implementations">
	<t>
	  Tthough not currently used by the most popular calendar
	  applications, other implementations could theoretically
	  converge into a standard.  We will talk briefly about the
	  calendar mime type in combination with
	  RegisterContentHandler, data URI scheme and a custom URI
	  scheme.
	</t>
	<section anchor="section.mime"
		 title="text/calendar MIME type in combination with
			RegisterContentHandler">
	  <t>
	    One way to use iCal files and avoid downloading it would
	    be registering a handler for calendar MIME <xref
	    target="RFC6838"/> types (text/calendar <xref
	    target="RFC5545"/>).  Operating Systems know how to handle
	    mime type properly, and are able to redirect it to
	    the right application. Web browsers, on the other hand,
	    still have limited capability to handle it. The method
	    RegisterContentHandler [RegisterContentHandler] allows to
	    send a given mime type file directly to a website, but so
	    far has only been implemented by Mozilla and only supports
	    atom/xml MIME type.
	  </t>
	</section>
	<section anchor="section.data" title="data URI">
	  <t>
	    Data URIs <xref target="RFC2397"/> can be used to replace an
	    external file in an HTML. One advantage is that it gets
	    embedded into the HTML and removes the need of an external
	    file, either a real file or emulated.  Unfortunately,
	    browsers treat these the same way they treat files,
	    therefore they would still need to be downloaded or properly
	    redirected to an application, and RegisterContentHandler
	    would need to be implemented by browsers and QR readers
	    before this approach can be used.
	  </t>
	</section>
	<section anchor="section.custom" title="Custom URI scheme">
	  <t>
	    A  custom URI  scheme  for events  would  behave similar  to
	    e-mail <xref target="RFC6068"/> geo <xref target="RFC5870"/>
	    and other  schemes, where the  resource (e-mail, geo,  or in
	    this case, the  event) is properly identified  and follows a
	    specified  protocol. An  HTML  page could  publish an  event
	    using this scheme  (as it would with any  other link format)
	    or a  print page could embed  it in an 2D-barcode.  The user
	    would  have  several options  of  handling  it: opening  his
	    application  of  choice,  or  redirecting  to  a  previously
	    registered  website  [RegisterProtocolHandler]. Support  for
	    URI  schemes  is  widespread,  most  Operating  Systems  and
	    browsers support it and its associated APIs.
	  </t>
	</section>
      </section>
    </section>
    <section anchor="section.uri" title="The v-event URI scheme">
      <t>
	In this section we will propose a custom URI schema that could
	be implemented easily by any calendar application and
	developers alike. We will also discuss some of its special
	requirements and provide several examples
      </t>
      <section anchor="section.syntax" title="Syntax">
	<t>
	  The v-event URI scheme syntax is based on both iCalendar <xref
	  target="RFC5545"/> and data URI scheme <xref
	  target="RFC2397"/>, we intend to make it trivial for people
	  used to iCalendar syntax to implement this scheme, and also
	  make it consistent with other existing URI formats. The
	  basic syntax for the URI is:
          <figure suppress-title="true">
	    <artwork align="center">
	      v-event:[base64,] icalendar event
	    </artwork>
	  </figure>
	  To be compatible with the generic URI syntax <xref
	  target="RFC3986"/>, the whole URI needs to follow the
	  percent encoding escaping. The iCalendar event can be either
	  written as an escaped text or, if base64 is specified,
	  converted to base64. Calendar applications MUST recognize
	  both formats to be compliant with this URI scheme
	  
	  For the iCalendar the following restrictions apply:
	  <list style="symbols">
	    <t>Exactly one entity in the VCALENDAR (VEVENT / VTODO) must
	    be specified.</t>
	    <t> MUST be a valid entity as specified by RFC 5545 <xref
	    target="RFC5545"/>, except for rules specified in this
	    document that can violate the RFC specification</t>
	    <t>Start and End dates MUST contain timezone through the
	    TZID param, as described in section 3.8.2.2 and 3.8.2.4 of
	    RFC 5545 <xref target="RFC5545"/></t>
	    <t>Timezones MUST be specified using one of the valid
	    names from the IANA timezone database (tz) <xref
	    target="tz"/>. Also, VTIMEZONE entries MUST NOT be added
	    to the v-event URI or to the source files. All calendar
	    applications reading events will recognize these names
	    (see <xref target="section.calendar_requirements"/> for
	    more details)</t>
	    <t>The event MUST contain a UID, as specified by section
	    3.8.4.7 of RFC 5545 <xref target="RFC5545"/></t>
	    <t>The VCALENDAR object MAY contain a SOURCE field
	    <xref target="CalDavExtensions"/>, pointing to an ICS file that can
	    contain extra information about the event contained in the
	    calendar. If the source file and the entry contradict each
	    other, the information presented in the source MUST
	    prevail. If the source is available, the event contained in
	    the source file MUST have the same UID as the event
	    expressed by the URI</t>
	    <t>The URI size MUST fit in the medium you're choosing to
	    transmit it, For reference, URIs larger than 2048
	    characters are known to not work properly on all browsers,
	    and QR codes have a hard limit of 2953 characters in its
	    most permissive encoding. In practice, we recommend
	    limiting the URI to 1024 characters and our tests have
	    shown 500 characters are usually enough for most common
	    scenarios.</t>
	    <t>LAST-MODIFIED field, as specified by section 3.8.7.3 of
	    RFC 5545 <xref target="RFC5545"/> MUST be included to
	    allow for changes to be detected by calendar handler
	    applications</t>
	  </list>
	</t>
      </section>
      <section anchor="section.registration" title="URI Registration">
	<t>The v-event URI will be registered with IANA as a
	provisional scheme, to allow all calendar applications to use
	it. The authors are not pursuing a permanent registration
	because they believe that this scheme may be deprecated in the
	future in favor of a DATA URI scheme, when browser
	implementations support that scheme with the same level
	regular URIs are supported.</t>
	<t>The following are the fields required by RFC 7595 <xref
	target="RFC7595"/>
	<list style="symbols">
	  <t>Scheme name: v-event</t>
	  <t>Status: provisional</t>
	  <t>Applications/protocols that use this scheme name:
	  Hypertext (for example, web pages, e-mail. QR code readers),
	  calendar applications.</t>
	  <t>Contact: Raphael Menderico (menderico@google.com)</t>
	  <t>Change Controller: CalConnect <xref
	  target="CalConnect"/></t>
	  <t>References: this document, plus references in it</t>
	</list>
	</t>
      </section>
      <section anchor="section.examples" title="Examples">
	<section anchor="section.101" title="V-Event URI 101 - a simple example">
	  <t>
	    In this first example, we will start with a simple event
	    that follows all the recommendations above. This event
	    starts on March 23rd, 2233, at midnight and finishes at
	    11:59 PM at the same day, in Eastern Time.  It has been
	    last modified on April 1st, 2015. From these, we have
	    the following icalendar event:
	    <figure suppress-title="true">
	      <artwork align="center">
		BEGIN:VCALENDAR
		BEGIN:VEVENT
		SUMMARY:James T. Kirk's birthday
		DTSTART;TZID=US/Eastern:22330322T000000
		DTEND;TZID=US/Eastern:22330322T235900
		UID:8726bc91-a168-4c42-9568-a0e7d35724d6@example.com
		LAST-MODIFIED:20150401T000000Z 
		END:VEVENT
		END:VCALENDAR
	      </artwork>
	    </figure>
	    which leads to the v-event URI:
	    <figure suppress-title="true">
	      <artwork align="center">
		v-event:BEGIN%3AVCALENDAR%0D%0ABEGIN%3AVEVENT%0D%0ASUMMARY
		%3AJames%20T.%20Kirk%27s%20birthday%0D%0ADTSTART%3BTZID%3DUS
		%2FEastern%3A22330322T000000%0D%0ADTEND%3BTZID%3DUS%2F
		Eastern%3A22330322T235900%0D%0AUID%3A8726bc91-a168-4c42-
		9568-a0e7d35724d6%40example.com%0D%0ALAST-MODIFIED%3A
		20150401T000000Z%0D%0AEND%3AVEVENT%0D%0AEND%3AVCALENDAR
	      </artwork>
	    </figure>
	  </t>
	</section>
	<section anchor="section.base64" title="Base 64 encoding">
	  <t>As mentioned before, calendar applications also need to
	  be able to interpret base64 versions of the URIs, the
	  example below represents the same event described
	  in <xref target="section.101" />:
	  <figure suppress-title="true">
	    <artwork align="center">
	      v-event:base64,QkVHSU46VkNBTEVOREFSDQpCRUdJTjpWRVZFTlQNClNVTU1BU
	      lk6SmFtZXMgVC4gS2lyaydzIGJpcnRoZGF5DQpEVFNUQVJUO1RaSUQ9VVMvRWF
	      zdGVybjoyMjMzMDMyMlQwMDAwMDANCkRURU5EO1RaSUQ9VVMvRWFzdGVybjoyM
	      jMzMDMyMlQyMzU5MDANClVJRDo4NzI2YmM5MS1hMTY4LTRjNDItOTU2OC1hMGU
	      3ZDM1NzI0ZDZAZXhhbXBsZS5jb20NCkxBU1QtTU9ESUZJRUQ6MjAxNTA0MDFUM
	      DAwMDAwWg0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg==
	    </artwork>
	  </figure>
	  </t>
	</section>
	<section anchor="section.source" title="Source link">
	  <t>
	    A source link should be added if the URI cannot fit all
	    information about a given event or for any other reason
	    you believe that an ICS file may better suit your
	    needs. For the same example in <xref
	    target="section.101" />, we can add the source URL
	    ‘http://www.example.com/kirk.ics’ and we would obtain
	    the following URIs:
	    <figure suppress-title="true">
	      <artwork align="center">
		v-event:BEGIN%3AVCALENDAR%0D%0ASOURCE%3Ahttp%3A%2F%2Fwww.example.com
		%2Fkirk.ics%0D%0ABEGIN%3AVEVENT%0D%0ASUMMARY%3AJames%20T.%20Kirk%27
		s%20birthday%0D%0ADTSTART%3BTZID%3DUS%2FEastern%3A22330322T000000%0D
		%0ADTEND%3BTZID%3DUS%2FEastern%3A22330322T235900%0D%0AUID%3Af41cb1b
		3-e071-425d-a200-5e1384a22758%40example.com%0D%0ALAST-MODIFIED%3A
		20150401T000000Z%0D%0AEND%3AVEVENT%0D%0AEND%3AVCALENDAR
	      </artwork>
	    </figure>
	    <figure suppress-title="true">
	      <artwork align="center">
		v-event:base64,QkVHSU46VkNBTEVOREFSDQpTT1VSQ0U6aHR0cDovL3d3dy5leGFtcGxlL
		mNvbS9raXJrLmljcw0KQkVHSU46VkVWRU5UDQpTVU1NQVJZOkphbWVzIFQuIEtpcmsnc
		yBiaXJ0aGRheQ0KRFRTVEFSVDtUWklEPVVTL0Vhc3Rlcm46MjIzMzAzMjJUMDAwMDAwD
		QpEVEVORDtUWklEPVVTL0Vhc3Rlcm46MjIzMzAzMjJUMjM1OTAwDQpVSUQ6ZjQxY2Ix
		YjMtZTA3MS00MjVkLWEyMDAtNWUxMzg0YTIyNzU4QGV4YW1wbGUuY29tDQpMQVNU
		LU1PRElGSUVEOjIwMTUwNDAxVDAwMDAwMFoNCkVORDpWRVZFTlQNCkVORDpWQ0
		FMRU5EQVI=
	      </artwork>
	    </figure>
	    The iCal object in this case would be:
	    <figure suppress-title="true">
	      <artwork align="center">	      
		BEGIN:VCALENDAR
		SOURCE:http://www.example.com/kirk.ics
		BEGIN:VEVENT
		SUMMARY:James T. Kirk's birthday
		DTSTART;TZID=US/Eastern:22330322T000000
		DTEND;TZID=US/Eastern:22330322T235900
		UID:f41cb1b3-e071-425d-a200-5e1384a22758@example.com
		LAST-MODIFIED:20150401T000000Z
		END:VEVENT
		END:VCALENDAR
	      </artwork>
	    </figure>
	  </t>
	</section>
	<section anchor="section.qr_examples" title="QR code
						     examples">
	  <t>
	    A QR code containing the first example (<xref
	    target="section.101"/>) can be found at
	    https://goo.gl/lQXIwP. It has been generated using the
	    ZXing barcode generator(<xref target="ZXing"/>).
	  </t>
	</section>
      </section>
      <section anchor="section.requirements"
	       title="Application requirements and best practices">
	<section anchor="section.publisher_requirements"
		 title="Event publisher">
	  <t>
	    For event publishers, the following extra requirements
	    must me met:
	    <list style="symbols">
	      <t>If your entry contains a SOURCE field pointing to an
	      URI, the publisher is responsible for keeping the link
	      live and with up-to-date information while the event
	      information is relevant (i.e, the link must exist until
	      the event expires).</t>
	    </list>
	  </t>
	  <t>
	    There are also some best practices that need to be
	    followed by these publishers in regard to UID generation
	    and the LAST-MODIFIED field, which are discussed in the
	    following subsections.
	  </t>
	  <section anchor="section.uid" title="UID generation">
	    <t>According to RFC 5545 <xref target="RFC5545"/>, every
	    event MUST be published with an UID, so calendar
	    applications can detect multiple occurrences of it and
	    remove them. The UID MUST be a globally unique identifier,
	    and the system generating the event must guarantee it is
	    unique. The recommended way is to generate an id that is
	    internal to a given system (for instance, a database
	    incremental id, an UUID, or something similar) and append
	    the domain name or IP address at the end, separating them
	    by an @.</t>

	    <t>For example, all these are valid unique ids for
	    domain example.com that fit this recommendation and also
	    RFC 5545 <xref target="RFC5545"/>:
	    <list style="symbols">
	      <t>
		[1@example.com]: a simple numerical id, useful if you
		are creating your first event and has no intention to
	      create another or can manage the ids manually.</t>
	      <t> [user-29960401T080000Z-1@example.com]: An UID for an
	      event from user ‘user’ that starts April first, 2996, at
	      8:00 AM, and uses the username and date as keys.</t>
	      <t>[f47935ee-ec5e-4d87-ba26-05e970674a88@example.com]:
	      a UID which uses UUIDs based on RFC 4122 <xref
	      target="RFC4122"/>. Theoretically, UUIDs are
	      themselves unique, but to conform with the
	      recommendation we also appended the domain name.
	      </t>
	    </list>
	    </t>
	  </section>
	</section>
	<section anchor="section.calendar_requirements"
		 title="Calendar applications requirements">
	  <t>
	    For calendar data handlers, the following set of extra
	    rules apply:
	    <list style="symbols">
	      <t>An event MUST only be handled by a calendar
	      application after an user performed an action, such as
	      clicking on a link or scanning a QR code. Events
	      published using the URI SHOULD NOT be added
	      automatically.</t>
	      <t>Calendar data handlers MUST retain sufficient
	      information to determine that an event has changed so
	      that it can inform the user.</t>
	      <t>If a user deletes a previously downloaded event the
	      handler should recognize that and ignore the event
	      unless explicitly clicked on.</t>
	      <t>A calendar application must keep its timezone
	      database always up-to-date and adjust events
	      accordingly. Timezones will be specified by reference
	      (i.e., their ISO names, according to <xref
	      target="tz"/>) and any calendar application MUST
	      understand these.</t>
	    </list>
	  </t>
	</section>
      </section>
    </section>
    <section title="Security and privacy considerations">
      <t>
	Below are some guidelines applications implementing v-event URI
	generators and parsers need to follow in order to avoid
	security and privacy issues.
	<list style="symbols">
	  <t>Whenever a SOURCE link is available, the application MUST
	  ask the user whether to follow the link, since
	  there may be costs associated with downloading data and the
	  user may want to perform this operation in a different
	  environment.</t>
	  <t>Calendar applications MAY check a SOURCE link
	  periodically to check for changes, but MUST NOT update an
	  event automatically based on new information provided by the
	  user. If new information is available through the SOURCE
	  link, calendar applications SHOULD inform the user and ask
	  for his consent before performing any change in his
	  calendar.</t>
	  <t>Reading an v-event URI or following a SOURCE link and
	  downloading a file may pose a security thread if not
	  carefully handled. Particularly code reading these files
	  should be careful to not get exposed to common security bugs
	  like buffer overflows.</t>
	  <t>A SOURCE link SHOULD not be used only as a tracking
	  mechanism, if a link is provided there should be some extra
	  information being provided by it or at least the possibility
	  that the information will be updated if necessary</t>
	  <t>A SOURCE link MUST not require a calendar account in any
	  calendar manager, and MUST NOT represent any form of event
	  subscription by a particular system. Any event subscription
	  action REQUIRES user acknowledgement and approval before
	  being performed.</t>
	  <t>Note that there is no hard limit on the size of a SOURCE
	  file, but it is expected that these contain information only
	  about a single event (i.e., one VEVENT) or recurring event
	  (several VEVENTs with the same RECURRENCE-ID) This has
	  implications for both writers and readers of these source
	  files:
	  <list style="symbols">
	    <t>Writers MUST always provided well-formed data that
	    complies to this document and, more generally, to iCalendar
	    format <xref target="RFC5545"/>.</t>
	    <t>Readers can't rely on the size of an input to decide
	    whether it is valid or not, and SHOULD implement parsers
	    that detect inconsistencies.</t>
	  </list>
	  </t>
	</list>
      </t>
    </section>
    <section anchor="section.future" title="Future work">
      <t>
	As mentioned in section <xref target="section.data"/>, the
	data URI scheme would be a nice fit for providing an uniform
	format for specifying events in the Web and printed media (QR
	and other formats), and we have only chosen another method
	because data support is currently limited.
      </t>
      <t>
	We plan to update this document with a data URI compatible
	format as soon as its support is more widespread, allowing it
	to be used by native applications, browser applications and
	physical media with the same support currently available for
	regular URIs. The format specified here is compatible with
	data URI and minimal changes would be needed to convert from
	one format to another.
      </t>
    </section>
    <section anchor="section.acknowledgements" title="Acknowledgements">
      <t>
	The authors would like to thank the members of CalConnect
	TC-EVENTPUB committee for its contributions to this document,
	particularly Dave Thewlis, Cyrus Daboo and Thomas Schaefer.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <reference anchor="AddThisEvent" target="http://addthisevent.com">
	<front>
	  <title>AddThisEvent</title>
	  <author>
	    <organization>AddThisEvent</organization>
	  </author>
	  <date year="2012"/>
	</front>
	<annotation>Last checked in August 26, 2015</annotation>
      </reference>
     <reference anchor="CalConnect" target="http://calconnect.org">
	<front>
	  <title>CalConnect: The Calendaring and Scheduling Consortium</title>
	  <author>
	    <organization>CalConnect</organization>
	  </author>
	  <date month="January" year="2004"/>
	</front>
	<annotation>Last checked in November 1, 2015</annotation>
      </reference>
      <reference anchor="CalendarContract" target="
						   http://developer.android.com/reference/android/provider/CalendarContract.html">
	<front>
	  <title>Android Calendar Contract</title>
	  <author>
	    <organization>Google Inc.</organization>
	  </author>
	  <date day="19" month="October" year="2011"/>
	</front>
	<annotation>Last checked in August 26, 2015</annotation>
      </reference>
      <reference anchor="CalDavExtensions" target="https://tools.ietf.org/html/draft-ietf-calext-extensions-00">
	<front>
	  <title>New Properties for iCalendar</title>
	  <author fullname="Cyrus Daboo" initials="C." surname="Daboo">
	    <organization>Apple Inc.</organization>
	  </author>
	  <date day="6" month="April" year="2015"/>
	</front>
	<annotation>Last checked in August 26, 2015</annotation>
      </reference>
      <reference anchor="GoogleCalendar" target="
						 http://calendar.google.com">
	<front>
	  <title>Google Calendar</title>
	  <author>
	    <organization>Google Inc.</organization>
	  </author>
	  <date day="13" month="April" year="2006"/>
	</front>
	<annotation>Last checked in August 26, 2015</annotation>
      </reference>
      <reference anchor="hCalendar" target="http://microformats.org/wiki/hcalendar">
	<front>
	  <title>hCalendar Microformat</title>
	  <author fullname="Tantek Çelik" initials="T." surname="Çelik">
	    <organization>microformats.org</organization>
	  </author>
	  <author fullname="Brian Suda" initials="B." surname="Suda">
	    <organization>microformats.org</organization>
	  </author>
	  <date day="19" month="June" year="2005"/>
	</front>
	<annotation>Last checked in July 27, 2015</annotation>
      </reference>
      <reference anchor="i-nigma">
	<front>
	  <title>i-nigma</title>
	  <author>
	    <organization>3GVision</organization>
	  </author>
	  <date day="26" month="August" year="2015"/>
	</front>
	<annotation>Last checked in August 27, 2015</annotation>
      </reference>
      <reference anchor="RFC2397">
	<front>
	  <title>The "data" URL scheme</title>
	  <author initials="L." surname="Masinter" fullname="L. Masinter">
	    <organization/>
	  </author>
	  <date year="1998" month="August"/>
	  <abstract>
	    <t>
	      A new URL scheme, "data", is defined. It allows
	      inclusion of small data items as "immediate" data, as if
	      it had been included externally. [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="2397"/>
	<seriesInfo name="DOI" value="10.17487/RFC2397"/>
      </reference>
      <reference anchor="RFC3986" target="http://www.rfc-editor.org/info/rfc3986">
	<front>
	  <title>Uniform Resource Identifier (URI): Generic Syntax</title>
	  <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
	    <organization/>
	  </author>
	  <author initials="R." surname="Fielding" fullname="R. Fielding">
	    <organization/>
	  </author>
	  <author initials="L." surname="Masinter" fullname="L. Masinter">
	    <organization/>
	  </author>
	  <date year="2005" month="January"/>
	  <abstract>
	    <t>
	      A Uniform Resource Identifier (URI) is a compact
	      sequence of characters that identifies an abstract or
	      physical resource. This specification defines the
	      generic URI syntax and a process for resolving URI
	      references that might be in relative form, along with
	      guidelines and security considerations for the use of
	      URIs on the Internet. The URI syntax defines a grammar
	      that is a superset of all valid URIs, allowing an
	      implementation to parse the common components of a URI
	      reference without knowing the scheme-specific
	      requirements of every possible identifier. This
	      specification does not define a generative grammar for
	      URIs; that task is performed by the individual
	      specifications of each URI scheme. [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
      </reference>
      <reference anchor="RFC4122" target="http://www.rfc-editor.org/info/rfc4122">
	<front>
	  <title>
	    A Universally Unique IDentifier (UUID) URN Namespace
	  </title>
	  <author initials="P." surname="Leach" fullname="P. Leach">
	    <organization/>
	  </author>
	  <author initials="M." surname="Mealling" fullname="M. Mealling">
	    <organization/>
	  </author>
	  <author initials="R." surname="Salz" fullname="R. Salz">
	    <organization/>
	  </author>
	  <date year="2005" month="July"/>
	  <abstract>
	    <t>
	      This specification defines a Uniform Resource Name
	      namespace for UUIDs (Universally Unique IDentifier),
	      also known as GUIDs (Globally Unique IDentifier). A UUID
	      is 128 bits long, and can guarantee uniqueness across
	      space and time. UUIDs were originally used in the Apollo
	      Network Computing System and later in the Open Software
	      Foundation\'s (OSF) Distributed Computing Environment
	      (DCE), and then in Microsoft Windows platforms.
	    </t>
	    <t>
	      This specification is derived from the DCE specification
	      with the kind permission of the OSF (now known as The
	      Open Group). Information from earlier versions of the
	      DCE specification have been incorporated into this
	      document. [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="4122"/>
	<seriesInfo name="DOI" value="10.17487/RFC4122"/>
      </reference>
      <reference anchor="RFC5545"
		 target="http://www.rfc-editor.org/info/rfc5545">
	<front>
	  <title>
	    Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	  </title>
	  <author initials="B." surname="Desruisseaux"
		  fullname="B. Desruisseaux" role="editor">
	    <organization/>
	  </author>
	  <date year="2009" month="September"/>
	  <abstract>
	    <t>
	      This document defines the iCalendar data format for
	      representing and exchanging calendaring and scheduling
	      information such as eventns, to-dos, journal entries, and
	      free/busy information, independent of any particular
	      calendar service or protocol. [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="5545"/>
	<seriesInfo name="DOI" value="10.17487/RFC5545"/>
      </reference>
      <reference anchor="RFC5870" target="http://www.rfc-editor.org/info/rfc5870">
	<front>
	  <title>
	    A Uniform Resource Identifier for Geographic Locations ('geo' URI)
	  </title>
	  <author initials="A." surname="Mayrhofer" fullname="A. Mayrhofer">
	    <organization/>
	  </author>
	  <author initials="C." surname="Spanring" fullname="C. Spanring">
	    <organization/>
	  </author>
	  <date year="2010" month="June"/>
	  <abstract>
	    <t>
	      This document specifies a Uniform Resource Identifier
	      (URI) for geographic locations using the 'geo\' scheme
	      name. A 'geo' URI identifies a physical location in a
	      two- or three-dimensional coordinate reference system in
	      a compact, simple, human-readable, and
	      protocol-independent way. The default coordinate
	      reference system used is the World Geodetic System 1984
	      (WGS-84). [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="5870"/>
	<seriesInfo name="DOI" value="10.17487/RFC5870"/>
      </reference>
      <reference anchor="RFC6068">
	<front>
	  <title>The 'mailto' URI Scheme</title>
	  <author initials="M." surname="Duerst"
		  fullname="M. Duerst">
	    <organization/>
	  </author>
	  <author initials="L." surname="Masinter" fullname="L. Masinter">
	    <organization/>
	  </author>
	  <author initials="J." surname="Zawinski" fullname="J. Zawinski">
	    <organization/>
	  </author>
	  <date year="2010" month="October"/>
	  <abstract>
	    <t>
	      This document defines the format of Uniform Resource
	      Identifiers (URIs) to identify resources that are
	      reached using Internet mail. It adds better
	      internationalization and compatibility with
	      Internationalized Resource Identifiers (IRIs; RFC 3987)
	      to the previous syntax of 'mailto' URIs (RFC
	      2368). [STANDARDS-TRACK]
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="RFC" value="6068"/>
	<seriesInfo name="DOI" value="10.17487/RFC6068"/>
      </reference>
      <reference anchor="RFC6838" target="http://www.rfc-editor.org/info/rfc6838">
	<front>
	  <title>
	    Media Type Specifications and Registration Procedures
	  </title>
	  <author initials="N." surname="Freed" fullname="N. Freed">
	    <organization/>
	  </author>
	  <author initials="J." surname="Klensin" fullname="J. Klensin">
	    <organization/>
	  </author>
	  <author initials="T." surname="Hansen" fullname="T. Hansen">
	    <organization/>
	  </author>
	  <date year="2013" month="January"/>
	  <abstract>
	    <t>
	      This document defines procedures for the specification
	      and registration of media types for use in HTTP, MIME,
	      and other Internet protocols. This memo documents an
	      Internet Best Current Practice.
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="BCP" value="13"/>
	<seriesInfo name="RFC" value="6838"/>
	<seriesInfo name="DOI" value="10.17487/RFC6838"/>
      </reference>
      <reference anchor="tz" target="https://www.iana.org/time-zones">
	<front>
	  <title>Time Zone Database</title>
	  <author>
	    <organization>IANA</organization>
	  </author>
	  <date year="1986"/>
	</front>
	<annotation>Last checked in August 27, 2015</annotation>
      </reference>
      <reference anchor="RFC7595" target="http://www.rfc-editor.org/info/rfc7595">
	<front>
	  <title>
	    Guidelines and Registration Procedures for URI Schemes
	  </title>
	  <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
	    <organization/>
	  </author>
	  <author initials="T." surname="Hansen" fullname="T. Hansen">
	    <organization/>
	  </author>
	  <author initials="T." surname="Hardie" fullname="T. Hardie">
	    <organization/>
	  </author>
	  <date year="2015" month="June"/>
	  <abstract>
	    <t>
	      This document updates the guidelines and
	      recommendations, as well as the IANA registration
	      processes, for the definition of Uniform Resource
	      Identifier (URI) schemes. It obsoletes RFC 4395.
	    </t>
	  </abstract>
	</front>
	<seriesInfo name="BCP" value="35"/>
	<seriesInfo name="RFC" value="7595"/>
	<seriesInfo name="DOI" value="10.17487/RFC7595"/>
      </reference>
      <reference anchor="ZXing">
	<front>
	  <title>ZXing Project</title>
	  <author fullname="Sean Owen" initials="S." surname="Owen">
	    <organization>Zebra Crossing team</organization>
	  </author>
	  <date day="27" month="November" year="2007"/>
	</front>
	<annotation>Last checked in July 27, 2015</annotation>
      </reference>
    </references>
  </back>
</rfc>