Subject: Re: [calsify] RFC proposal for a new calendar URI

From: Raphael Menderico <[email-masked]>
Date: Mon, 04 Apr 2016 13:53:13 +0000

Hi,

Bringing this topic up again.

Thanks in advance

Raphael

On Fri, Mar 18, 2016 at 2:53 PM Raphael Menderico <[email-masked]>
wrote:

> Dear calext WG participants,
>
> My name is Raphael Menderico, I work at Google and one of my duties has
> been to work on a new URI schema for calendar events. After discussions
> inside Google and with the industry group (CalConnect), a draft has been
> written and submitted to IETF (
> https://tools.ietf.org/html/draft-menderico-v-event-uri-00).
>
> I would like to ask the participants of this working group if there is
> interest on this new URI format for events being proposed. Any assistance,
> like comments or other ideas is really appreciated.
>
> Thanks in advance for your help
>
> Raphael Menderico
> Google
>

---

From: Evert Pot <[email-masked]>
Date: Tue, 5 Apr 2016 17:33:04 -0400

> 
> On Fri, Mar 18, 2016 at 2:53 PM Raphael Menderico <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     My name is Raphael Menderico, I work at Google and one of my duties
>     has been to work on a new URI schema for calendar events. After
>     discussions inside Google and with the industry group (CalConnect),
>     a draft has been written and submitted to IETF
>     (https://tools.ietf.org/html/draft-menderico-v-event-uri-00). 
> 
>     I would like to ask the participants of this working group if there
>     is interest on this new URI format for events being proposed. Any
>     assistance, like comments or other ideas is really appreciated.
> 

The biggest issue I have with the proposal, is that it effectively
duplicates the functionality of the data: URI scheme with a
Content-Type. At least from a standards perspective.

My understanding from the draft is that the problem with that, has to do
with browsers / operating systems not correctly redirecting to
calendaring applications based on their mime type.

Therefore I would say that this proposal is by definition not really a
'correct' implementation. It must be recognized as a workaround or hack
around limitations of browsers. That in itself is fine. We do that every
day. This is not unlike the webcal: scheme, which is non-standard, but
similar in the sense that webcal: is just http:, but is used as a trick
to get browsers to open external applications.

But my question is, has any attempt been made to correct the root cause
of this issue before creating the workaround?

Are these browser bugs? If so, have those bugs been reported? Was there
a response?
If it's not classified as a bug, but a new feature, maybe WhatWG is more
appropriate?

Lastly, if those options are exhausted, what about using a format such as :

v-event:data:...

This allows you to alternatively use a http or https url as such:

v-event:http:...
v-event:https:...

or even:

v-event:file:...

The benefit is that it separates the functionality to trigger an
external application, from the actual means to access the data.

Evert

---

From: "Tim Hare" <[email-masked]>
Date: Thu, 7 Apr 2016 21:37:18 -0400

I'm not on the calext list, just calsify, however I would like to express
some idea about it

1. This seems like yet another encoding of iCalendar data - we would have
the standard "text" version,  xCal, and now a URI scheme
2. I am not sure URIs are the place to store data, mailto: and geo:
notwithstanding.  Basically it seems to me we would be using it to store
data in an anchor tag, withing an HTML page - I'm not a fan of putting the
data within the markup, except for attribute information in XML.
3. Doesn't the browser still need to extract the iCalendar VEVENT data, put
it in some object or serialized temporary file, and pass it to a 'helper'
application ?  So I don't see how it solved the issue of handling the
iCalendar data any differently than a link to an iCalendar file or opening
an xCalendar document.
4. Since webcal: already exists, why not build on that work somehow?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: calsify [mailto:[email-masked]] On Behalf Of Evert Pot
Sent: Tuesday, April 5, 2016 5:33 PM
To: [email-masked]
Subject: Re: [calsify] RFC proposal for a new calendar URI

v-event:data:...

v-event:http:...
v-event:https:...

or even:

v-event:file:...

Evert

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: Raphael Menderico <[email-masked]>
Date: Fri, 08 Apr 2016 08:15:34 +0000

> a response?

We checked and the support for RegisterContentHandler (which we would need
to embed data properly on links) is quite limited:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-bugs/e3f_ReGmtnY
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/RegisterContentHandler

It seems to be by design, at least from the investigation we did. In this
case we are looking to get a use case that can be used as a proof of
concept to show browser applications that support for
RegisterContentHandler needs to be widespread. In the meantime, we can only
rely on RegisterProtocolHandler, hence the proposal.

> external application, from the actual means to access the data.

I have no strong opinion about this, in theory it covers what we want with
given the user some other options. When it has been designed we just wanted
to keep it as simple as possible while still making the required calendar
features available that would not be covered by something simpler.

> the standard "text" version,  xCal, and now a URI scheme

It is not another encoding, just a variation of the text version.

> data within the markup, except for attribute information in XML.

Some CSS transformations are only available to embedded data (like changes
based on the URI type). I also disagree with that data should not be
embedded, I believe it is easier to develop if the data you are storing is
small enough to be embedded, it is easier to spot that these are not in
sync for instance. It behaves similarly to a lambda (or data URI, if its
support was more widespread).

> iCalendar data any differently than a link to an iCalendar file or opening

We actually designed it on purpose to have a similar handling than iCal,
but to be embedded instead. The advantage is not having to store these
files when this option is not available (for instance, on QR codes, CMS, or
countries with really bad internet connection that would benefit with data
being embedded on the page and downloaded at once). Note that data: already
exists and, if its support was more widespread, we would be using it
instead.

> 4. Since webcal: already exists, why not build on that work somehow?

Two reasons:
a) avoid poluting webcal
b) the fact that this could be done using data if support was more
widespread, so we can update only this part without having to change webcal
back.

---

From: Evert Pot <[email-masked]>
Date: Sat, 9 Apr 2016 00:07:22 -0400

On 2016-04-08 04:15 AM, Raphael Menderico wrote:
> We checked and the support for RegisterContentHandler (which we would
> need to embed data properly on links) is quite limited:
> It seems to be by design, at least from the investigation we did. In
> this case we are looking to get a use case that can be used as a proof
> of concept to show browser applications that support for
> RegisterContentHandler needs to be widespread. In the meantime, we can
> only rely on RegisterProtocolHandler, hence the proposal.
>  
> 

The point that was missed from this was, we _have_ a URI scheme that
covers the required features, it's just not handled the way you want it
in browsers.

Your proposal is a workaround, but does not fix the underlying problem.
The links you posted just describe the status quo.

What if other people need this feature for a different data type? Should
everyone register a URI scheme for every mime type? I'd say that the
answer to that surely is no

So the logical place to solve your problem is not to register an URI
scheme to work around that flaw, but to solve it in the browser. Hence
my question: what attempts have been made to solve this in the browser?
WhatWG might be a better starting point. This is useful as a universal
feature beyond calendaring.

Why do you suppose that webcal: webcals: and feed: were all rejected as
standards? You're going to run into the same wall.

Evert

---

From: Raphael Menderico <[email-masked]>
Date: Mon, 11 Apr 2016 09:16:58 +0000

> standards? You're going to run into the same wall.

The problem we found with this is that, from the standards perspective,
there is a solution, but browser manufactures (Google included) have
security concerns that are not present for plain URIs. So, not sure if
going to WhatWG would help (except for raising awareness of the problem).
Is that what you're recommending ?

The URI itself was never designed as something permanent, and the goal was
indeed to update the RFC later to use data instead, we believed that it
would be possible to publish this as a recommendation document, which would
be "fixed" when data spec became more widespread. Do you believe it would
be possible to publish it if we recommended using data (so, as a method for
publishing calendar events on browsers, with the rules like SOURCE handling
and others) but with a footnote that data is not available on most browsers
and the temporary fix is to use v-event? Note that in this case the URI
itself would not be part of the specification, only the handling rules.