idnits 2.17.1 draft-menderico-v-event-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...endar applications MUST recognize both...' RFC 2119 keyword, line 219: '... o MUST be a valid entity as specified by RFC 5545 [RFC5545], except...' RFC 2119 keyword, line 223: '...rt and End dates MUST contain timezone...' RFC 2119 keyword, line 226: '... o Timezones MUST be specified usin...' RFC 2119 keyword, line 227: '...z) [tz]. Also, VTIMEZONE entries MUST...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o 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. -- The document date (November 24, 2015) is 3076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RegisterContentHandler' is mentioned on line 162, but not defined == Missing Reference: 'RegisterProtocolHandler' is mentioned on line 188, but not defined Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Menderico, Ed. 3 Internet-Draft P. Schlup 4 Intended status: Informational L. Kristiansen 5 Expires: May 27, 2016 Google 6 November 24, 2015 8 v-event URI: An URI scheme for events. 9 draft-menderico-v-event-uri-00 11 Abstract 13 This document defines the format of Uniform Resource Identifiers 14 (URIs) for calendar events, allowing users to add these events to 15 their calendar application from any source that defines them, like 16 web sites and printed QR codes 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 27, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Calendar users currently often do not have the ability to quickly add 53 an event to theirdefault calendar app, when encountering event data 54 on a webpage, poster or mobile apps. In this sense events have 55 fallen behind other real world entities, like e-mail [RFC6068] and 56 geo coordinates [RFC5870] which allow for performing actions in 57 default apps when encountering these entities anywhere. This 58 recommendations document addresses the problem by proposing best 59 practices when embedding and publishing calendar data. We believe 60 that using a standardized URI scheme for event publishing will make 61 populating of users' calendars much simpler, will make developers' 62 lives easier and will increase calendar apps usage in general. A 63 major additional benefit of URIs is sharing of events on physical 64 media (for example via QR codes) or via URL. 66 2. Motivation and related work 68 2.1. Current event publishing practices 70 Many ways to add events to calendar apps have been developed due to 71 the lack of standardization. While these solve the basic need of 72 sharing events, it does so with limited reach, are harder to use and 73 limit adoption by new providers. We will briefly mention four common 74 ways: using a download link, hCalendar embedding, using VEVENTs in QR 75 codes and provider specific buttons. 77 2.1.1. Publish a link to an iCalendar file 79 A simple way to publish an event i sto share a link that points to an 80 iCalendar [RFC5545] file and provide a link to the user for 81 downloading it. In an ideal world, a user would click on the link 82 pointing to a file, the browser would recognize this link as a 83 calendar file and redirect it to the proper calendar application, 84 which would display the event information to the user, allowing 85 simple edit actions, and saving it to the calendar. 87 There are many problems with this method. Files must be hosted in a 88 server, which is not always feasible or easy, and need to be 89 maintained separately from the web pages they are linked from. This 90 poses unnecessary difficulty for blog and CMS users, especially when 91 compared to linking to email addresses or other web pages. 93 Furthermore, ICS files might not be recognized by the browser or 94 operating system, or the user might use a web-based calendar app 95 instead of a native one. Files might also contain malware and pose 96 additional risk, with some end users avoiding downloaded files 97 altogether. 99 One additional problem is coupling of the file and the entity it 100 represents. Currently the user needs to manually keep the event file 101 and all the links and descriptions with the same information in the 102 links about in sync. It is preferable to have this information close 103 together. Ideally the same tools used to generate a page could be 104 used to assure a link and the text information being displayed are 105 synchronized. 107 2.1.2. Current QR code implementations 109 Several QR code readers ([ZXing][i-nigma]) support calendar events to 110 be embedded in QR codes, but they have their own non-standard 111 implementation, usually a single VEVENT iCalendar component. They 112 work well on the mobile platform but rely on OS internals 113 [CalendarContract] to add the event to the calendar. 115 While QR code does not dictate a format for calendar events, most 116 readers implement the URI standard schemes and would benefit from 117 this proposal. 119 2.1.3. hCalendar 121 hCalendar [hCalendar] is a microformat for events that can be used to 122 annotate a web page or another document and indicate to readers that 123 an event is present. While microformats are useful for parsing and 124 styling, they are not meant to be used as links to an event and need 125 to be used in conjunction with the external ICS file method or a 126 proprietary browser extension. They usually require a complex 127 interaction between the website and the calendar application to get 128 it right. This also makes it not ideal for QR scanning, since the 129 annotations were not designed to represent the whole content of a 130 document. They are more appropriate as an annotation on a previously 131 structured text. 133 2.1.4. Custom calendar application link 135 Several calendar systems provide a proprietary URL for event creation 136 ([AddThisEvent][GoogleCalendar]). However, due to lack of standards, 137 applications must implement and link to these separately. This 138 burdens both content creators and web site users: content creators 139 must maintain individual links for each calendar application 140 provider, and end users must find and choose the appropriate one for 141 their own case. This consumes precious space on the page and 142 requires understanding of several APIs, making it difficult for a 143 developer that wants to just publish a simple event. Furthermore, 144 it's impossible to link to all calendar app providers, requiring a 145 combination of this method with the ICS file hosting method. 147 2.2. Alternative implementations 149 Tthough not currently used by the most popular calendar applications, 150 other implementations could theoretically converge into a standard. 151 We will talk briefly about the calendar mime type in combination with 152 RegisterContentHandler, data URI scheme and a custom URI scheme. 154 2.2.1. text/calendar MIME type in combination with 155 RegisterContentHandler 157 One way to use iCal files and avoid downloading it would be 158 registering a handler for calendar MIME [RFC6838] types (text/ 159 calendar [RFC5545]). Operating Systems know how to handle mime type 160 properly, and are able to redirect it to the right application. Web 161 browsers, on the other hand, still have limited capability to handle 162 it. The method RegisterContentHandler [RegisterContentHandler] 163 allows to send a given mime type file directly to a website, but so 164 far has only been implemented by Mozilla and only supports atom/xml 165 MIME type. 167 2.2.2. data URI 169 Data URIs [RFC2397] can be used to replace an external file in an 170 HTML. One advantage is that it gets embedded into the HTML and 171 removes the need of an external file, either a real file or emulated. 172 Unfortunately, browsers treat these the same way they treat files, 173 therefore they would still need to be downloaded or properly 174 redirected to an application, and RegisterContentHandler would need 175 to be implemented by browsers and QR readers before this approach can 176 be used. 178 2.2.3. Custom URI scheme 180 A custom URI scheme for events would behave similar to e-mail 181 [RFC6068] geo [RFC5870] and other schemes, where the resource 182 (e-mail, geo, or in this case, the event) is properly identified and 183 follows a specified protocol. An HTML page could publish an event 184 using this scheme (as it would with any other link format) or a print 185 page could embed it in an 2D-barcode. The user would have several 186 options of handling it: opening his application of choice, or 187 redirecting to a previously registered website 188 [RegisterProtocolHandler]. Support for URI schemes is widespread, 189 most Operating Systems and browsers support it and its associated 190 APIs. 192 3. The v-event URI scheme 194 In this section we will propose a custom URI schema that could be 195 implemented easily by any calendar application and developers alike. 196 We will also discuss some of its special requirements and provide 197 several examples 199 3.1. Syntax 201 The v-event URI scheme syntax is based on both iCalendar [RFC5545] 202 and data URI scheme [RFC2397], we intend to make it trivial for 203 people used to iCalendar syntax to implement this scheme, and also 204 make it consistent with other existing URI formats. The basic syntax 205 for the URI is: 207 v-event:[base64,] icalendar event 209 To be compatible with the generic URI syntax [RFC3986], the whole URI 210 needs to follow the percent encoding escaping. The iCalendar event 211 can be either written as an escaped text or, if base64 is specified, 212 converted to base64. Calendar applications MUST recognize both 213 formats to be compliant with this URI scheme For the iCalendar the 214 following restrictions apply: 216 o Exactly one entity in the VCALENDAR (VEVENT / VTODO) must be 217 specified. 219 o MUST be a valid entity as specified by RFC 5545 [RFC5545], except 220 for rules specified in this document that can violate the RFC 221 specification 223 o Start and End dates MUST contain timezone through the TZID param, 224 as described in section 3.8.2.2 and 3.8.2.4 of RFC 5545 [RFC5545] 226 o Timezones MUST be specified using one of the valid names from the 227 IANA timezone database (tz) [tz]. Also, VTIMEZONE entries MUST 228 NOT be added to the v-event URI or to the source files. All 229 calendar applications reading events will recognize these names 230 (see Section 3.4.2 for more details) 232 o The event MUST contain a UID, as specified by section 3.8.4.7 of 233 RFC 5545 [RFC5545] 235 o The VCALENDAR object MAY contain a SOURCE field 236 [CalDavExtensions], pointing to an ICS file that can contain extra 237 information about the event contained in the calendar. If the 238 source file and the entry contradict each other, the information 239 presented in the source MUST prevail. If the source is available, 240 the event contained in the source file MUST have the same UID as 241 the event expressed by the URI 243 o The URI size MUST fit in the medium you're choosing to transmit 244 it, For reference, URIs larger than 2048 characters are known to 245 not work properly on all browsers, and QR codes have a hard limit 246 of 2953 characters in its most permissive encoding. In practice, 247 we recommend limiting the URI to 1024 characters and our tests 248 have shown 500 characters are usually enough for most common 249 scenarios. 251 o LAST-MODIFIED field, as specified by section 3.8.7.3 of RFC 5545 252 [RFC5545] MUST be included to allow for changes to be detected by 253 calendar handler applications 255 3.2. URI Registration 257 The v-event URI will be registered with IANA as a provisional scheme, 258 to allow all calendar applications to use it. The authors are not 259 pursuing a permanent registration because they believe that this 260 scheme may be deprecated in the future in favor of a DATA URI scheme, 261 when browser implementations support that scheme with the same level 262 regular URIs are supported. 264 The following are the fields required by RFC 7595 [RFC7595] 266 o Scheme name: v-event 268 o Status: provisional 270 o Applications/protocols that use this scheme name: Hypertext (for 271 example, web pages, e-mail. QR code readers), calendar 272 applications. 274 o Contact: Raphael Menderico (menderico@google.com) 276 o Change Controller: CalConnect [CalConnect] 278 o References: this document, plus references in it 280 3.3. Examples 282 3.3.1. V-Event URI 101 - a simple example 284 In this first example, we will start with a simple event that follows 285 all the recommendations above. This event starts on March 23rd, 286 2233, at midnight and finishes at 11:59 PM at the same day, in 287 Eastern Time. It has been last modified on April 1st, 2015. From 288 these, we have the following icalendar event: 290 BEGIN:VCALENDAR 291 BEGIN:VEVENT 292 SUMMARY:James T. Kirk's birthday 293 DTSTART;TZID=US/Eastern:22330322T000000 294 DTEND;TZID=US/Eastern:22330322T235900 295 UID:8726bc91-a168-4c42-9568-a0e7d35724d6@example.com 296 LAST-MODIFIED:20150401T000000Z 297 END:VEVENT 298 END:VCALENDAR 300 which leads to the v-event URI: 302 v-event:BEGIN%3AVCALENDAR%0D%0ABEGIN%3AVEVENT%0D%0ASUMMARY 303 %3AJames%20T.%20Kirk%27s%20birthday%0D%0ADTSTART%3BTZID%3DUS 304 %2FEastern%3A22330322T000000%0D%0ADTEND%3BTZID%3DUS%2F 305 Eastern%3A22330322T235900%0D%0AUID%3A8726bc91-a168-4c42- 306 9568-a0e7d35724d6%40example.com%0D%0ALAST-MODIFIED%3A 307 20150401T000000Z%0D%0AEND%3AVEVENT%0D%0AEND%3AVCALENDAR 309 3.3.2. Base 64 encoding 311 As mentioned before, calendar applications also need to be able to 312 interpret base64 versions of the URIs, the example below represents 313 the same event described in Section 3.3.1: 315 v-event:base64,QkVHSU46VkNBTEVOREFSDQpCRUdJTjpWRVZFTlQNClNVTU1BU 316 lk6SmFtZXMgVC4gS2lyaydzIGJpcnRoZGF5DQpEVFNUQVJUO1RaSUQ9VVMvRWF 317 zdGVybjoyMjMzMDMyMlQwMDAwMDANCkRURU5EO1RaSUQ9VVMvRWFzdGVybjoyM 318 jMzMDMyMlQyMzU5MDANClVJRDo4NzI2YmM5MS1hMTY4LTRjNDItOTU2OC1hMGU 319 3ZDM1NzI0ZDZAZXhhbXBsZS5jb20NCkxBU1QtTU9ESUZJRUQ6MjAxNTA0MDFUM 320 DAwMDAwWg0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg== 322 3.3.3. Source link 324 A source link should be added if the URI cannot fit all information 325 about a given event or for any other reason you believe that an ICS 326 file may better suit your needs. For the same example in 327 Section 3.3.1, we can add the source URL 'http://www.example.com/ 328 kirk.ics' and we would obtain the following URIs: 330 v-event:BEGIN%3AVCALENDAR%0D%0ASOURCE%3Ahttp%3A%2F%2Fwww.example.com 331 %2Fkirk.ics%0D%0ABEGIN%3AVEVENT%0D%0ASUMMARY%3AJames%20T.%20Kirk%27 332 s%20birthday%0D%0ADTSTART%3BTZID%3DUS%2FEastern%3A22330322T000000%0D 333 %0ADTEND%3BTZID%3DUS%2FEastern%3A22330322T235900%0D%0AUID%3Af41cb1b 334 3-e071-425d-a200-5e1384a22758%40example.com%0D%0ALAST-MODIFIED%3A 335 20150401T000000Z%0D%0AEND%3AVEVENT%0D%0AEND%3AVCALENDAR 337 v-event:base64,QkVHSU46VkNBTEVOREFSDQpTT1VSQ0U6aHR0cDovL3d3dy5leGFtcGxlL 338 mNvbS9raXJrLmljcw0KQkVHSU46VkVWRU5UDQpTVU1NQVJZOkphbWVzIFQuIEtpcmsnc 339 yBiaXJ0aGRheQ0KRFRTVEFSVDtUWklEPVVTL0Vhc3Rlcm46MjIzMzAzMjJUMDAwMDAwD 340 QpEVEVORDtUWklEPVVTL0Vhc3Rlcm46MjIzMzAzMjJUMjM1OTAwDQpVSUQ6ZjQxY2Ix 341 YjMtZTA3MS00MjVkLWEyMDAtNWUxMzg0YTIyNzU4QGV4YW1wbGUuY29tDQpMQVNU 342 LU1PRElGSUVEOjIwMTUwNDAxVDAwMDAwMFoNCkVORDpWRVZFTlQNCkVORDpWQ0 343 FMRU5EQVI= 345 The iCal object in this case would be: 347 BEGIN:VCALENDAR 348 SOURCE:http://www.example.com/kirk.ics 349 BEGIN:VEVENT 350 SUMMARY:James T. Kirk's birthday 351 DTSTART;TZID=US/Eastern:22330322T000000 352 DTEND;TZID=US/Eastern:22330322T235900 353 UID:f41cb1b3-e071-425d-a200-5e1384a22758@example.com 354 LAST-MODIFIED:20150401T000000Z 355 END:VEVENT 356 END:VCALENDAR 358 3.3.4. QR code examples 360 A QR code containing the first example (Section 3.3.1) can be found 361 at https://goo.gl/lQXIwP. It has been generated using the ZXing 362 barcode generator([ZXing]). 364 3.4. Application requirements and best practices 366 3.4.1. Event publisher 368 For event publishers, the following extra requirements must me met: 370 o If your entry contains a SOURCE field pointing to an URI, the 371 publisher is responsible for keeping the link live and with up-to- 372 date information while the event information is relevant (i.e, the 373 link must exist until the event expires). 375 There are also some best practices that need to be followed by these 376 publishers in regard to UID generation and the LAST-MODIFIED field, 377 which are discussed in the following subsections. 379 3.4.1.1. UID generation 381 According to RFC 5545 [RFC5545], every event MUST be published with 382 an UID, so calendar applications can detect multiple occurrences of 383 it and remove them. The UID MUST be a globally unique identifier, 384 and the system generating the event must guarantee it is unique. The 385 recommended way is to generate an id that is internal to a given 386 system (for instance, a database incremental id, an UUID, or 387 something similar) and append the domain name or IP address at the 388 end, separating them by an @. 390 For example, all these are valid unique ids for domain example.com 391 that fit this recommendation and also RFC 5545 [RFC5545]: 393 o [1@example.com]: a simple numerical id, useful if you are creating 394 your first event and has no intention to create another or can 395 manage the ids manually. 397 o [user-29960401T080000Z-1@example.com]: An UID for an event from 398 user 'user' that starts April first, 2996, at 8:00 AM, and uses 399 the username and date as keys. 401 o [f47935ee-ec5e-4d87-ba26-05e970674a88@example.com]: a UID which 402 uses UUIDs based on RFC 4122 [RFC4122]. Theoretically, UUIDs are 403 themselves unique, but to conform with the recommendation we also 404 appended the domain name. 406 3.4.2. Calendar applications requirements 408 For calendar data handlers, the following set of extra rules apply: 410 o An event MUST only be handled by a calendar application after an 411 user performed an action, such as clicking on a link or scanning a 412 QR code. Events published using the URI SHOULD NOT be added 413 automatically. 415 o Calendar data handlers MUST retain sufficient information to 416 determine that an event has changed so that it can inform the 417 user. 419 o If a user deletes a previously downloaded event the handler should 420 recognize that and ignore the event unless explicitly clicked on. 422 o A calendar application must keep its timezone database always up- 423 to-date and adjust events accordingly. Timezones will be 424 specified by reference (i.e., their ISO names, according to [tz]) 425 and any calendar application MUST understand these. 427 4. Security and privacy considerations 429 Below are some guidelines applications implementing v-event URI 430 generators and parsers need to follow in order to avoid security and 431 privacy issues. 433 o Whenever a SOURCE link is available, the application MUST ask the 434 user whether to follow the link, since there may be costs 435 associated with downloading data and the user may want to perform 436 this operation in a different environment. 438 o Calendar applications MAY check a SOURCE link periodically to 439 check for changes, but MUST NOT update an event automatically 440 based on new information provided by the user. If new information 441 is available through the SOURCE link, calendar applications SHOULD 442 inform the user and ask for his consent before performing any 443 change in his calendar. 445 o Reading an v-event URI or following a SOURCE link and downloading 446 a file may pose a security thread if not carefully handled. 447 Particularly code reading these files should be careful to not get 448 exposed to common security bugs like buffer overflows. 450 o A SOURCE link SHOULD not be used only as a tracking mechanism, if 451 a link is provided there should be some extra information being 452 provided by it or at least the possibility that the information 453 will be updated if necessary 455 o A SOURCE link MUST not require a calendar account in any calendar 456 manager, and MUST NOT represent any form of event subscription by 457 a particular system. Any event subscription action REQUIRES user 458 acknowledgement and approval before being performed. 460 o Note that there is no hard limit on the size of a SOURCE file, but 461 it is expected that these contain information only about a single 462 event (i.e., one VEVENT) or recurring event (several VEVENTs with 463 the same RECURRENCE-ID) This has implications for both writers and 464 readers of these source files: 466 * Writers MUST always provided well-formed data that complies to 467 this document and, more generally, to iCalendar format 468 [RFC5545]. 470 * Readers can't rely on the size of an input to decide whether it 471 is valid or not, and SHOULD implement parsers that detect 472 inconsistencies. 474 5. Future work 476 As mentioned in section Section 2.2.2, the data URI scheme would be a 477 nice fit for providing an uniform format for specifying events in the 478 Web and printed media (QR and other formats), and we have only chosen 479 another method because data support is currently limited. 481 We plan to update this document with a data URI compatible format as 482 soon as its support is more widespread, allowing it to be used by 483 native applications, browser applications and physical media with the 484 same support currently available for regular URIs. The format 485 specified here is compatible with data URI and minimal changes would 486 be needed to convert from one format to another. 488 6. Acknowledgements 490 The authors would like to thank the members of CalConnect TC-EVENTPUB 491 committee for its contributions to this document, particularly Dave 492 Thewlis, Cyrus Daboo and Thomas Schaefer. 494 7. References 496 [AddThisEvent] 497 AddThisEvent, "AddThisEvent", 2012, 498 . 500 Last checked in August 26, 2015 502 [CalConnect] 503 CalConnect, "CalConnect: The Calendaring and Scheduling 504 Consortium", January 2004, . 506 Last checked in November 1, 2015 508 [CalendarContract] 509 Google Inc., "Android Calendar Contract", October 2011, < 510 http://developer.android.com/reference/android/provider/ 511 CalendarContract.html>. 513 Last checked in August 26, 2015 515 [CalDavExtensions] 516 Daboo, C., "New Properties for iCalendar", April 2015, 517 . 520 Last checked in August 26, 2015 522 [GoogleCalendar] 523 Google Inc., "Google Calendar", April 2006, < 524 http://calendar.google.com>. 526 Last checked in August 26, 2015 528 [hCalendar] 529 Celik, T. and B. Suda, "hCalendar Microformat", June 2005, 530 . 532 Last checked in July 27, 2015 534 [i-nigma] 3GVision, "i-nigma", August 2015. 536 Last checked in August 27, 2015 538 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 539 DOI 10.17487/RFC2397, August 1998. 541 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 542 Resource Identifier (URI): Generic Syntax", STD 66, 543 RFC 3986, DOI 10.17487/RFC3986, January 2005, 544 . 546 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 547 Unique IDentifier (UUID) URN Namespace", RFC 4122, 548 DOI 10.17487/RFC4122, July 2005, 549 . 551 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 552 Scheduling Core Object Specification (iCalendar)", 553 RFC 5545, DOI 10.17487/RFC5545, September 2009, 554 . 556 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 557 Identifier for Geographic Locations ('geo' URI)", 558 RFC 5870, DOI 10.17487/RFC5870, June 2010, 559 . 561 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 562 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010. 564 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 565 Specifications and Registration Procedures", BCP 13, 566 RFC 6838, DOI 10.17487/RFC6838, January 2013, 567 . 569 [tz] IANA, "Time Zone Database", 1986, . 572 Last checked in August 27, 2015 574 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 575 and Registration Procedures for URI Schemes", BCP 35, 576 RFC 7595, DOI 10.17487/RFC7595, June 2015, 577 . 579 [ZXing] Owen, S., "ZXing Project", November 2007. 581 Last checked in July 27, 2015 583 Authors' Addresses 585 Raphael Menderico (editor) 586 Google Inc. 587 Brandschenkestrasse 110 588 Zurich, ZH 8002 589 CH 591 Email: menderico@google.com 592 URI: http://www.google.com/ 594 Paulo Schlup 595 Google Inc. 596 Brandschenkestrasse 110 597 Zurich, ZH 8002 598 CH 600 Email: pschlup@google.com 601 URI: http://www.google.com/ 603 Lucia Kristiansen 604 Google Inc. 605 Brandschenkestrasse 110 606 Zurich, ZH 8002 607 CH 609 Email: lucka@google.com 610 URI: http://www.google.com/