A simple way to publish an event is to share a link that points to an iCalendar 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.

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.

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.

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.

Several QR code readers (, ) 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 to add the event to the calendar.

While QR code does not dictate a format for calendar events, most readers implement the URI standard schemes and would benefit from this proposal.

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.

Several calendar systems provide a proprietary URL for event creation (, ). 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.

One way to use iCal files and avoid downloading it would be registering a handler for calendar MIME types (text/calendar ). 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 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.

Data URIs 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.

A custom URI scheme for events would behave similar to e-mail geo 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.

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:

which leads to the v-event URI:

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 :

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 , we can add the source URL ‘‘ and we would obtain the following URIs:

The iCal object in this case would be:

A QR code containing the first example () can be found at . It has been generated using the ZXing barcode generator().

For event publishers, the following extra requirements must me met:

• 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).

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.

For calendar data handlers, the following set of extra rules apply:

• 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.

• Calendar data handlers MUST retain sufficient information to determine that an event has changed so that it can inform the user.

• If a user deletes a previously downloaded event the handler should recognize that and ignore the event unless explicitly clicked on.

• 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 ) and any calendar application MUST understand these.