From nobody Mon Apr 4 06:53:42 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC96D12D6CF for ; Mon, 4 Apr 2016 06:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d40zOKHyPWGs for ; Mon, 4 Apr 2016 06:53:31 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8325012D6BA for ; Mon, 4 Apr 2016 06:53:23 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id c4so54832742vkb.3 for ; Mon, 04 Apr 2016 06:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wBcRfU1A1r2+cw9Tb4cMnkZFjrBsXtfhKMrXTBEeVp0=; b=ECIyd7RhChMmLiAza227MOTFgHxOt7TfbQrhJFWGKbSAd9jHv5bpj7/Z2D7bovobui QGTjF/M6rStfpNLNjOT733umsuMAAWKxxwAyhROoDKAtNH3ZBOTVW1NN0YC5YEPvCAxs EBVZLiI+EXtcAj3OZUUN7lyiFtCsbcfCjVWQ1YdGpiuM7gf7x4ouNsTIFDokIvYJgRbN G5yr0FCSmSW3PgDAMWvDFbUOo8mImDOUn8gt9LsggjK48dJArfNUudd0Q6p8DXCTmqbY TcyGRLO9jG3QXn0ojUqlPxHI4aK0HYT/7En1T5eLt4bNf3OgKQ08DR4LTqVFkzgbkXj+ jVgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wBcRfU1A1r2+cw9Tb4cMnkZFjrBsXtfhKMrXTBEeVp0=; b=R+Xm9LE5Fmz560vVt8PrJ/GMyIchB8T3BSPrzJtGWg9O6d+PxY5B0suPiqhKg7/6ja l2BjakbDEh/1Dcojl2+WBqpH+oDGn77l5OKtZy8PNRYHNr+cIZfYRbFzCL/wxsxbF0Er zSzA9SDLtNKDzCW8eWZnpuU0tI8uDexKLnbFYUWAPy4/epzlXMhawPXLO9lBLa15k6/v EDYgGUo8A4lP+BSFv3sXlh9SUP+lJyvd6CYnVoBtu7oL6zH0ZCFL73dNcL2iRm2KA7nL +FobI6Emllj/4L9p3DMZWbWzhlPbX2oDqCyQkAkNZStGFwAROpCGmaoLjdvNlsi+lI5s xJKQ== X-Gm-Message-State: AD7BkJLaglK+JSLjwlrzZ2VX5ErSUk7MsBnDTxr6QWuXbyaerj7sBkNRLV7MoM2dX5G4BcRCT0snAPUZCOIhMcOH X-Received: by 10.31.172.135 with SMTP id v129mr5234147vke.154.1459778002531; Mon, 04 Apr 2016 06:53:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Raphael Menderico Date: Mon, 04 Apr 2016 13:53:13 +0000 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary=001a1143e3dc4b0b44052fa90dd8 Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:53:37 -0000 --001a1143e3dc4b0b44052fa90dd8 Content-Type: text/plain; charset=UTF-8 Hi, Bringing this topic up again. Thanks in advance Raphael On Fri, Mar 18, 2016 at 2:53 PM Raphael Menderico 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 > --001a1143e3dc4b0b44052fa90dd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Bringing this topic up again.
=

Thanks in advance

Raphael

On Fri, Mar 18, 2016= at 2:53 PM Raphael Menderico <m= enderico@google.com> wrote:
=
Dear cale= xt WG participants,
<= br>
My name is Raphae= l Menderico, I work at Google and one of my duties has been to work on a ne= w 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).=C2=A0

<= /div>
I would like to ask t= he participants of this working group if there is interest on this new URI = format for events being proposed. Any assistance, like comments or other id= eas is really appreciated.

Thanks in = advance for your help

Raphael Menderico
Google
--001a1143e3dc4b0b44052fa90dd8-- From nobody Tue Apr 5 14:33:19 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21CC12D0A2 for ; Tue, 5 Apr 2016 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=lpGPTgDJ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Bg1oVRQh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yVlc7S0t7Fr for ; Tue, 5 Apr 2016 14:33:14 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7710912DA3A for ; Tue, 5 Apr 2016 14:33:07 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DC5A8208BA for ; Tue, 5 Apr 2016 17:33:06 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 05 Apr 2016 17:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=APXFIU7LpkmUXT0B7DHyVEv68fs=; b=lpGPTg DJ4AJ7frZd33PQatmQcgj45xZ7L70T4bwg96Y3l2nMozTy+YmMieaH/qLshPOzb+ V0pimZf9CIkeL0Omccqm3w9qF9+Hzx4zWSnQTFVWoY/2hnDhCr5CcKyVdAekkd6S /tu98wFx3Ohmpnap8Dc7bV+uhdSwRYQsfZBig= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=APXFIU7LpkmUXT0 B7DHyVEv68fs=; b=Bg1oVRQhnAweqdlheTKo24V3Z+SijZt5Z4rE3X2rC4uNjGk c32CEQ8//q7TLVUTLDA/PcVQmwI8YeCtg9RQNmUZBDYYgkdvECBsWWHM57klRzS4 tHqv/+8vgVTcKlSDaVtHNAZpNEzLwn7uDMVIBDv+JnDQporGI3qnU8MFuhWU= X-Sasl-enc: wotsteTNbsN7j9nnHQUinFfkjsaHJBnBhtbBaF9UTj2i 1459891986 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.118.8.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 853FC680135 for ; Tue, 5 Apr 2016 17:33:06 -0400 (EDT) To: calsify@ietf.org References: From: Evert Pot Message-ID: <57042F10.6050602@evertpot.com> Date: Tue, 5 Apr 2016 17:33:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:33:17 -0000 > > On Fri, Mar 18, 2016 at 2:53 PM Raphael Menderico > 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 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 nobody Thu Apr 7 18:37:24 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CFC12D6AC for ; Thu, 7 Apr 2016 18:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVHLZUhIM0SA for ; Thu, 7 Apr 2016 18:37:20 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF42012D5CD for ; Thu, 7 Apr 2016 18:37:20 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by comcast with SMTP id oLMOa4hqssK9moLMOaaxZM; Fri, 08 Apr 2016 01:37:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460079440; bh=gMkqQ85O31ogKVGDg1Imp76z+79p4SjCpU5/obYYZr8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=LW+joio7i2gIXNul3Mtmb70u+GbWGA8PTmhdJM4gbE8b+cHOBedRuxelLPBmiMLTi LpkfMpM3zFSSma1sx2GT/L5s9H3ymVO+BFIKQ5BXdh7ur2a+E8V/vcpxHUtTuI3+Iu CUbLnl/tcV4avmztU4O0G8O1THl/zhOPMsq/QVHu+ZgswmtgXiZE8oAXZZAfAd8lGc MEvFHSA56aTpRZ3PoQsEyoGvksuP3ZuoQqaDTrYc+T59YSbTYrO+EcLDy+SeZXpnor t420QwbE+hOduPYQzDpdw+6o/lfZw0AjeGr9eDxs2EtEtDJa09Inqu8woyyGVrD0UK mqtFNtxguSxnA== Received: from THARE ([73.42.15.222]) by resomta-po-16v.sys.comcast.net with comcast id fddK1s0034nTr3d01ddKpY; Fri, 08 Apr 2016 01:37:20 +0000 From: "Tim Hare" To: "'Evert Pot'" , References: <57042F10.6050602@evertpot.com> In-Reply-To: <57042F10.6050602@evertpot.com> Date: Thu, 7 Apr 2016 21:37:18 -0400 Message-ID: <006c01d19137$30e30c30$92a92490$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHWoQBxrpSditeDIOwyx0jfMsTWJwIRI5q8AKYu7K6fX27FMA== Content-Language: en-us Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:37:22 -0000 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:calsify-bounces@ietf.org] On Behalf Of Evert Pot Sent: Tuesday, April 5, 2016 5:33 PM To: calsify@ietf.org Subject: Re: [calsify] RFC proposal for a new calendar URI > > On Fri, Mar 18, 2016 at 2:53 PM Raphael Menderico > 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 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Apr 8 01:15:48 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03F212D505 for ; Fri, 8 Apr 2016 01:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zZ3ce3kKH2 for ; Fri, 8 Apr 2016 01:15:45 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2212512D1E2 for ; Fri, 8 Apr 2016 01:15:45 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id k1so129611993vkb.0 for ; Fri, 08 Apr 2016 01:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tdBfh+noF1Z6CIMb6+POzYDGHxMDHbs3jObJH/XVD9w=; b=oZ2CEgODb1a6q2eXwmIAi7NdKPARGonBPmriI2gu2Xc2psmaLKnpqMToBrpN3VqSy4 GXvQ0fAshBZbFOCETCwyCo1aZ0oZpjUb2s/646xpVI6m6TReCdqtVFNeHJaziVd1Uvh6 4I5CNyTjYtNkal8/90f1FUIMIAMS0oZnr0Z95/D1dbfjeuTOPsJTwWpOuYX6FzGdkkDC 1HeN1IYzZfpL10Z7GWX+cl9tyXBKPbfBjrDjGrroLHqfG7E+YyuMwiuxt0U3HSDItpKe 3/UnzS/tz5IVKUwkgjocaZqf5dag/E4KA/Aik3Hy2kHznnfurhWjLmlf57jZtK0XxZN3 1o9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tdBfh+noF1Z6CIMb6+POzYDGHxMDHbs3jObJH/XVD9w=; b=FRf1mKTdf9TF+0xkkpKvzZRloDLdcdJP+qFcjE63vDdTNF6rEdqu4kLNDh2SN5CCxR ZZCkd/t8MdXzHOe3DINrIYlbqMJECQYs+2KPpQgAwRhGCau3Vq9Rm61qsE8rYJTvCR76 Bgj+rQFBOuqFp1sxblsGabFvXh1lI3G1IcwVOrp4YslIukzgmpUgIBd2FdiqtGJZVT/z 9dfRKx7O1eU4C4SzD28XqGNTVrL8rabgIQqvuJp6++WeSsY4VMEzOEyX10dmpeMGNRbP IECYvkUwPerTuIX53jBy5yaiROj/c/3yliOwSWmboBM/RttLC2v40QwLS7DoksTMEoGU xlxg== X-Gm-Message-State: AD7BkJL3DDCzhUyb2yWPAjyszg9qS9UCSxHlumkSEXeO28kPsgcXjiu5BT1GRYH2QTPiZUEHE7AaWMXJ2J3QvR+c X-Received: by 10.31.108.136 with SMTP id j8mr3486914vki.105.1460103344129; Fri, 08 Apr 2016 01:15:44 -0700 (PDT) MIME-Version: 1.0 References: <57042F10.6050602@evertpot.com> <006c01d19137$30e30c30$92a92490$@comcast.net> In-Reply-To: <006c01d19137$30e30c30$92a92490$@comcast.net> From: Raphael Menderico Date: Fri, 08 Apr 2016 08:15:34 +0000 Message-ID: To: Tim Hare , Evert Pot , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a114784c229d32c052ff4cdfb Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:15:48 -0000 --001a114784c229d32c052ff4cdfb Content-Type: text/plain; charset=UTF-8 > > 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? > 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. > 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. > 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. On Fri, Apr 8, 2016 at 3:37 AM Tim Hare wrote: > 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 > It is not another encoding, just a variation of the text version. > 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. > 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). > 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. > 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. > Evert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a114784c229d32c052ff4cdfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The biggest issue I have with the pr= oposal, is that it effectively
duplicates the functionality of the data:= URI scheme with a
Content-Type. At least from a standards perspective.<= br>
My understanding from the draft is that the problem with that, has t= o do
with browsers / operating systems not correctly redirecting to
c= alendaring applications based on their mime type.

Therefore I would = say that this proposal is by definition not really a
'correct' i= mplementation. It must be recognized as a workaround or hack
around limi= tations 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 brow= sers to open external applications.

But my question is, has any atte= mpt been made to correct the root cause
of this issue before creating th= e workaround?
Are these browser bugs? If s= o, have those bugs been reported? Was there
a response?
=

We checked and the support for RegisterContentHand= ler (which we would need to embed data properly on links) is quite limited:=

It seems to be by design, at lea= st 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 th= at support for RegisterContentHandler needs to be widespread. In the meanti= me, we can only rely on RegisterProtocolHandler, hence the proposal.
<= div>=C2=A0
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:d= ata:...

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 t= o trigger an
external application, from the actual means to access the d= ata.

I have no strong opinion about thi= s, 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.

=
On Fri, Apr 8, 2016 at 3:37 AM Tim Hare <TimHare@comcast.net> wrote:
I'm not on the calext list, just calsify, howe= ver 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,=C2=A0 xCal, and now a URI scheme
=

It is not another encoding, just a variati= on of the text version.
=C2=A0
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 'helpe= r'
application ?=C2=A0 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<= br> an xCalendar document.

We actually desi= gned 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 s= upport was more widespread, we would be using it instead.=C2=A0
= =C2=A0
4. Since webcal: already exists, why not build on that work somehow?

Two reasons:
a) avoid poluting webc= al
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 w= ebcal back.
=C2=A0
Evert

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a114784c229d32c052ff4cdfb-- From nobody Fri Apr 8 21:07:28 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C6312D0C4 for ; Fri, 8 Apr 2016 21:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=eF6XsDP0; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=hHlXSO9A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AehUJBv8N5h8 for ; Fri, 8 Apr 2016 21:07:24 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F3D12D6F1 for ; Fri, 8 Apr 2016 21:07:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C3EC42125E for ; Sat, 9 Apr 2016 00:07:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 09 Apr 2016 00:07:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=gPKQHj8dI87lgPc3msse9k1Zobs=; b=eF6XsD P0PBXXwwZ1JxVo0B8CXPv4rcjzUZHKhs1y1MX2jfOz59tGttv89iA6pAtZC+zE1s um/8Mk86QgHzjpZvY+4ArclCwkQRZD9rCEA4zGcaByKcnN4cPAkS/FyyGQRlBggW jqAsLSBLgo/LTmRvgPK8Y/mDNTfuKZq9G96EA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=gPKQHj8dI87lgPc 3msse9k1Zobs=; b=hHlXSO9A+JlRf/sHZgQFJBtpUQ9XBAg3rLv2xLF8HBBeCyK /ikMMs3Xqu3xIClXEcpfRDWXY8ca5XVwX0N/hINC0VopgG9DqA+hry+n88HY9WRw MguFxVkY9LZL4sdXZqf0nLpVy+xHtkUPFuV51MkCo7+xNWA6NW2cfuAezpHc= X-Sasl-enc: 7qbYwLPhVDgdFNNIUVVxJcSbuXBwukSaiEifMgwELWVY 1460174842 Received: from [192.168.0.20] (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.118.8.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 79B51C00012; Sat, 9 Apr 2016 00:07:22 -0400 (EDT) To: Raphael Menderico , calsify@ietf.org References: <57042F10.6050602@evertpot.com> <006c01d19137$30e30c30$92a92490$@comcast.net> From: Evert Pot Message-ID: <57087FFA.8050806@evertpot.com> Date: Sat, 9 Apr 2016 00:07:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 04:07:27 -0000 On 2016-04-08 04:15 AM, Raphael Menderico wrote: > 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? > > > 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. > > > 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 : 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 nobody Mon Apr 11 02:17:13 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CAE12DC80 for ; Mon, 11 Apr 2016 02:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUeUmy3OyyPK for ; Mon, 11 Apr 2016 02:17:09 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139F012D8A7 for ; Mon, 11 Apr 2016 02:17:09 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id k1so204370524vkb.0 for ; Mon, 11 Apr 2016 02:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OP6BKFr6Gij6/VdonsiMjGoogxvzULLeZI/inT1oqfs=; b=pQA1eAtwnIfiYYB/A4J6AT9W0EX4qh/BdlyeBRJ/uyTrKnp88uW288+N2INq/+xRxM oqPnuYXcnHbZD3Xk5U8lhcwOoxga6NcX4hu355B8NiwZ2u88KYVrhEsNdhUUjBd+NWjJ vEcmf7Fx0yt+XI3LpjSCjDDDgiDoUmElotj868Q38qDBUvhqsfVjdVIz/4kHtEc+gmqG J0talKjicfsyhyBQqzxVlCDoJB4ahNoeYw7cwdWrcF9PbuSmxU4XEZ/luUWSkymvuT/O v77SYpIVY6ZLeY9YktmrB3S9vSs6z4Yd1mi06T4A4j/0nSqysxyQpCs6sZPEamnzdlYe t1tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OP6BKFr6Gij6/VdonsiMjGoogxvzULLeZI/inT1oqfs=; b=BHkOdEvXkbR5JP1L2L4szEnf+1Vtmd9Ylxcv7ekBMjb0Y2xT7QXewHDwzm1FaqHuIH wPjLM23tXd6OFSkMh4xAkgwjdZP94FgxI8qt4iXAFFroIiJ7iL+/NRWh07o+UoAw3yzP 3OLkMtAE0DjTzWgb1ZX+BELqm07xpgv431ZBqz1uk2jaNllGNZAMjgpK7/VPHi0+rdN+ W5/HQ2bnI7dv6PzNG7i7ZzXesg2P46OV7Q9YUUU8vJaPgADUn4i9lpfac8HDIZgE1UcL TJRNCMD8XsHivVr2hI1LGM9rKf+PU0YcBKgnXjKjOrCSlljSLVwWDJRe+noDapzHQTaD yh1g== X-Gm-Message-State: AD7BkJK4wk48O3xRAMgZZT9ce0WF7O23bk9gZqdMvan1ZSf1dNhIN9R6JGGf7BTpDVoCvrd2sqS6ZX4P5X0S/+fL X-Received: by 10.176.6.40 with SMTP id f37mr9668699uaf.137.1460366227966; Mon, 11 Apr 2016 02:17:07 -0700 (PDT) MIME-Version: 1.0 References: <57042F10.6050602@evertpot.com> <006c01d19137$30e30c30$92a92490$@comcast.net> <57087FFA.8050806@evertpot.com> In-Reply-To: <57087FFA.8050806@evertpot.com> From: Raphael Menderico Date: Mon, 11 Apr 2016 09:16:58 +0000 Message-ID: To: Evert Pot , calsify@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1246e042f2fe05303202c4 Archived-At: Subject: Re: [calsify] RFC proposal for a new calendar URI X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 09:17:12 -0000 --94eb2c1246e042f2fe05303202c4 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 9, 2016 at 6:07 AM Evert Pot wrote: > > > On 2016-04-08 04:15 AM, Raphael Menderico wrote: > > 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? > > > > > > 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. > > > > > > 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 : > > > 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. > 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. > Evert > > > --94eb2c1246e042f2fe05303202c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat= , Apr 9, 2016 at 6:07 AM Evert Pot <m= e@evertpot.com> wrote:


On 2016-04-08 04:15 AM, Raphael Menderico wrote:
>=C2=A0 =C2=A0 =C2=A0The biggest issue I have with the proposal, is that= it effectively
>=C2=A0 =C2=A0 =C2=A0duplicates the functionality of the data: URI schem= e with a
>=C2=A0 =C2=A0 =C2=A0Content-Type. At least from a standards perspective= .
>
>=C2=A0 =C2=A0 =C2=A0My understanding from the draft is that the problem= with that, has to do
>=C2=A0 =C2=A0 =C2=A0with browsers / operating systems not correctly red= irecting to
>=C2=A0 =C2=A0 =C2=A0calendaring applications based on their mime type.<= br> >
>=C2=A0 =C2=A0 =C2=A0Therefore I would say that this proposal is by defi= nition not really a
>=C2=A0 =C2=A0 =C2=A0'correct' implementation. It must be recogn= ized as a workaround or hack
>=C2=A0 =C2=A0 =C2=A0around limitations of browsers. That in itself is f= ine. We do that every
>=C2=A0 =C2=A0 =C2=A0day. This is not unlike the webcal: scheme, which i= s non-standard, but
>=C2=A0 =C2=A0 =C2=A0similar in the sense that webcal: is just http:, bu= t is used as a trick
>=C2=A0 =C2=A0 =C2=A0to get browsers to open external applications.
>
>=C2=A0 =C2=A0 =C2=A0But my question is, has any attempt been made to co= rrect the root cause
>=C2=A0 =C2=A0 =C2=A0of this issue before creating the workaround?
>
>=C2=A0 =C2=A0 =C2=A0Are these browser bugs? If so, have those bugs been= reported? Was there
>=C2=A0 =C2=A0 =C2=A0a response?
>
>
> We checked and the support for RegisterContentHandler (which we would<= br> > need to embed data properly on links) is quite limited:
> https://groups.= google.com/a/chromium.org/forum/#!topic/chromium-bugs/e3f_ReGmtnY
> https://develo= per.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.
>
>
>=C2=A0 =C2=A0 =C2=A0If it's not classified as a bug, but a new feat= ure, maybe WhatWG is more
>=C2=A0 =C2=A0 =C2=A0appropriate?
>
>=C2=A0 =C2=A0 =C2=A0Lastly, if those options are exhausted, what about = using a format
>=C2=A0 =C2=A0 =C2=A0such as :


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.

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 ?=C2=A0

The= URI itself was never designed as something permanent, and the goal was ind= eed 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 &q= uot;fixed" when data spec became more widespread. Do you believe it wo= uld 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 han= dling and others) but with a footnote that data is not available on most br= owsers 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.=
=C2=A0
Evert


--94eb2c1246e042f2fe05303202c4-- From nobody Fri Apr 15 06:45:22 2016 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFC12DBD6 for ; Fri, 15 Apr 2016 06:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1u7NF04XZz8 for ; Fri, 15 Apr 2016 06:45:20 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7652512DB53 for ; Fri, 15 Apr 2016 06:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1460727919; d=isode.com; s=selector; i=@isode.com; bh=0Qc7TcD4DRySp1HwvuPACO2gobM8MqOFgFfU7CeT6Ts=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=jrq4pCakGl+mBZrsHcznS2lNfbYc4q9TOmeCPEWzIvyt03mpdzp0nG5z1S7gPcCpcQt3zR cVEiHBnt5OPoROI/aslslGLs6colMT/hcyKS/bX7zhV76RJu39Q3lXwi1XpmtvXKlim1d0 p1CapWvwjDr2IOUgDG0C8c/zWXaV8Gw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 15 Apr 2016 14:45:19 +0100 To: calsify@ietf.org From: Alexey Melnikov Message-ID: <5710EFF8.1030709@isode.com> Date: Fri, 15 Apr 2016 14:43:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [calsify] Looking for a new co-chair X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 13:45:21 -0000 Hi, To introduce myself: I am the new Responsible Area Director for the WG. Amanda doesn't have enough time to manage the WG in addition to her regular job, so I am looking for a new co-chair to replace her. Donald Eastlake will remain as the experienced co-chair. If you have suggestions (including self-nominations), please email me directly. Thank you, Alexey