Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3133A7F8D9 for ; Wed, 31 May 2006 14:50:16 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DDB6D142293; Wed, 31 May 2006 14:50:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) References: Content-Type: multipart/alternative; boundary=Apple-Mail-1--993678338 Message-Id: From: Lisa Dusseault Date: Wed, 31 May 2006 14:50:13 -0700 To: CalDAV DevList , HTTP working group , WebDav WG , Atom-Protocol WG X-Mailer: Apple Mail (2.749.3) Cc: Sam Hartman Subject: [Ietf-caldav] Fwd: [Ietf-http-auth] Who is interested in a BOF at IETF 66 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 21:50:16 -0000 --Apple-Mail-1--993678338 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI -- Sam's ideas involve solving some authentication problems for HTTP-based applications (that don't necessarily use HTML signin forms) as well as for just browsers. Lisa Begin forwarded message: > From: Sam Hartman > Date: May 31, 2006 2:19:27 PM PDT > To: ietf-http-auth@lists.osafoundation.org > Subject: [Ietf-http-auth] Who is interested in a BOF at IETF 66 > > > > Hi. So far, there has not been a lot of interest expressed in my BOF > proposal. I'm surprised by that given general interest in working on > the problem expressed at IETF 65. > > It would be good to know who is interested in working on this problem > and who is interested in attending a BOF to discuss chartering a WG > sooner rather than later. The BOF scheduling deadline is Monday. > > --Sam > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth --Apple-Mail-1--993678338 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI -- Sam's ideas involve = solving some authentication problems for HTTP-based applications (that = don't necessarily use HTML signin forms) as well as for just = browsers.

Lisa

Begin = forwarded message:

From: = Sam Hartman <hartmans-ietf@mit.edu>=
Date: May 31, 2006 2:19:27 PM = PDT
Subject: [Ietf-http-auth] Who is = interested in a BOF at IETF 66



Hi.=A0 = So far, there has not been a lot of interest expressed in my = BOF
proposal.=A0 I'm surprised by that given = general interest in working on
the problem = expressed at IETF 65.
It would be good to know who is = interested in working on this problem
and who = is interested in attending a BOF to discuss chartering a WG
sooner rather than later.=A0 The BOF scheduling deadline = is Monday.

--Sam

Ietf-http-auth mailing list

= --Apple-Mail-1--993678338-- Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F249A7F8A5 for ; Wed, 31 May 2006 12:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E422F142293 for ; Wed, 31 May 2006 12:39:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08566-08 for ; Wed, 31 May 2006 12:39:00 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4269914226D for ; Wed, 31 May 2006 12:39:00 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id o2so55329uge for ; Wed, 31 May 2006 12:38:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=i/mQ/Z2z6lQyZjQH09KIAXZaIdOHfBR2ZzWlkDf+6XQSq6qU6Quy1wV1WHFNZDukjJkTX8mM2RSXC8RULwvbav39sSPd2V3QQ9BE/epSriayrA5cWApnW9+GudHFq5V+l+Le3IK+D248GF+4MsYeN4F6ziSWmPPvyrdKgY6viBE= Received: by 10.78.40.10 with SMTP id n10mr41821hun; Wed, 31 May 2006 12:38:58 -0700 (PDT) Received: by 10.78.48.18 with HTTP; Wed, 31 May 2006 12:38:58 -0700 (PDT) Message-ID: <6f64bf7f0605311238n1760fb74y6f9ef81763eb7176@mail.gmail.com> Date: Wed, 31 May 2006 15:38:58 -0400 From: "Robert Yates" To: calatom-adhoc-l@calconnect.org, Ietf-caldav@osafoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Subject: [Ietf-caldav] CalAtom presentation X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 19:39:05 -0000 All, I have posted the CalAtom presentation that Dan went through at the CalConnect meeting in Cambridge. It is available here http://robubu.com/CalAtom/CalAtom.html. I am still not too happy with searching but I think that a9's opensearch may help, Rob Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 138937F73E for ; Tue, 30 May 2006 14:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 05AE2142288 for ; Tue, 30 May 2006 14:01:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30242-03 for ; Tue, 30 May 2006 14:01:23 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF1A5142281 for ; Tue, 30 May 2006 14:01:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BDB043F73D5 for ; Tue, 30 May 2006 22:57:56 +0200 (CEST) Received: from [10.84.42.118] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 8E1F43F73BE for ; Tue, 30 May 2006 22:57:56 +0200 (CEST) In-Reply-To: <007401c683e7$684b30c0$6501a8c0@corp.usa.net> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com><28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com><447C1A80.7040700@gmx.de> <1F01125F-56F3-4D04-84A3-44F1349A7244@opengroupware.org> <007401c683e7$684b30c0$6501a8c0@corp.usa.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 23:01:09 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 21:01:25 -0000 On May 30, 2006, at 2:48PM, Chris Bryant wrote: >> Actually I think that vfb-GET is complementory to CalDAV and >> doesn't need to be specified in there. Very much like iCalendar- >> over-HTTP which is also likely to be implemented by server >> vendors in addition. > > If vendors are likely to implement free-busy via GET, what defines > how that will be done, or is each vendor going to decide that on > their own? If clients hope to use that method, doesn't it make > sense to try to make it reasonably standard? Is there a way to put > things like this into the spec as optional, with some way to query > what features the server supports? Hm, well referring and using vfb URLs is almost an implied standard. Vfb is standardized in iCalendar, GET/URLs are standardized and even discovery is standardized (some LDAP RFC, was it even in inetOrgPerson?). This doesn't allow for query parameters, but this might already be considered "advanced usage" which would validate a REPORT (the way it usually works with vfb files is that the user decides a range which he makes available to others). Greets, Helge Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 358907F72B; Tue, 30 May 2006 11:39:13 -0700 (PDT) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E479D14228E; Tue, 30 May 2006 11:39:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) To: IETF-iCalendar , CalDAV DevList Message-Id: <8AA3DBC2-0F8A-4713-92A3-9EDB86107E12@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-20-1055929559 References: From: Lisa Dusseault Date: Tue, 30 May 2006 11:38:57 -0700 X-Mailer: Apple Mail (2.749.3) Subject: [Ietf-caldav] Fwd: Atompub WG meeting at the Montreal IETF X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 18:39:13 -0000 --Apple-Mail-20-1055929559 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI: Calendar format standards and relationship to AtomPub is tentatively on the AtomPub WG agenda in Montreal. Lisa Begin forwarded message: > From: Paul Hoffman > Date: May 23, 2006 1:49:20 PM PDT > To: Atom WG , atom-protocol@imc.org > Subject: Atompub WG meeting at the Montreal IETF > > > Greetings again. The Atompub WG will have our first (and maybe > last!) face-to-face meeting at the upcoming IETF meeting in > Montreal at the beginning of July. > > The timing of us having our first WG meeting may seem odd, given > the fact that we completed the Atom format document long ago, and > are making good progress on the publishing protocol. However, there > are reasons other than "moving documents forwards" for WGs to meet. > Lisa Dusseault, our Area Director, asked us to have a meeting so > that people active in the Atompub WG can have more interaction with > the IETF, and vice versa. There is interest in the Atom format from > other WGs, and there may be interest in the Atom publishing > protocol as well. > > I propose the following agenda, which should fit well into a one- > hour slot: > > - Intro: 10 mins > - Brief overview of protocol status: 10 mins > - Use of Atom format in other WGs: 30 mins > - draft-saintandre-atompub-notify > - Overlap with calendar formats > - Overlap with mail > > Note that we are explicitly *not* going to discuss extensions to > the Atom format at this WG meeting because they are not part of the > WG charter. Lisa has said that she may help arrange a BoF session > on creating a new Working Group for Atom extensions, and having at > least a higher-level discussion of what extensions are out there > would be appropriate in that BoF. But, to use asterisks again, such > discussion is *not* part of the Atompub WG meeting. > > See for details about > the IETF meeting. I will let the WG know when there are preliminary > and near-permanent agendas for the meeting. It would be good to > meet some of you there! > > --Paul Hoffman, Director > --Internet Mail Consortium > --Apple-Mail-20-1055929559 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI: Calendar format standards = and relationship to AtomPub is tentatively on the AtomPub WG agenda in = Montreal.

Lisa

Begin = forwarded message:

From: = Paul Hoffman <phoffman@imc.org>
Date: = May 23, 2006 1:49:20 PM PDT
To: Atom WG = <atom-syntax@imc.org>, = atom-protocol@imc.org
Subject: = Atompub WG meeting at the Montreal = IETF

=

The timing of us having our = first WG meeting may seem odd, given the fact that we completed the Atom = format document long ago, and are making good progress on the publishing = protocol. However, there are reasons other than "moving documents = forwards" for WGs to meet. Lisa Dusseault, our Area Director, asked us = to have a meeting so that people active in the Atompub WG can have more = interaction with the IETF, and vice versa. There is interest in the Atom = format from other WGs, and there may be interest in the Atom publishing = protocol as well.

I propose the following agenda, which should fit = well into a one-hour slot:

- Intro: 10 mins
- Brief overview of protocol status: 10 = mins
- Use of Atom format in other = WGs: 30 mins
=A0 - = draft-saintandre-atompub-notify
=A0 - Overlap with calendar = formats
=A0 - Overlap with mail

Note = that we are explicitly *not* going to discuss extensions to the Atom = format at this WG meeting because they are not part of the WG charter. = Lisa has said that she may help arrange a BoF session on creating a new = Working Group for Atom extensions, and having at least a higher-level = discussion of what extensions are out there would be appropriate in that = BoF. But, to use asterisks again, such discussion is *not* part of the = Atompub WG meeting.
See <http://www.ietf.org/mee= tings/IETF-66.html> for details about the IETF meeting. I will = let the WG know when there are preliminary and near-permanent agendas = for the meeting. It would be good to meet some of you there!

--Paul = Hoffman, Director
--Internet Mail = Consortium

=

= --Apple-Mail-20-1055929559-- Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4902C7F6F9 for ; Tue, 30 May 2006 10:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 38FDB142290 for ; Tue, 30 May 2006 10:09:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30025-06 for ; Tue, 30 May 2006 10:09:29 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BEBA1142286 for ; Tue, 30 May 2006 10:09:29 -0700 (PDT) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4UH9R6s002709; Tue, 30 May 2006 10:09:27 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id B11B0324017; Tue, 30 May 2006 10:09:26 -0700 (PDT) In-Reply-To: <447C1A80.7040700@gmx.de> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com> <447C1A80.7040700@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <250619A7-0A7A-4AC9-BBD3-669F150D31EB@wsanchez.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 10:09:25 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 17:09:31 -0000 Funny you mention Subversion. At ApacheCon in Germany last year, at the conference hotel, I couldn't update some of my Subversion working copies. Subversions useless error messages didn't help, but having much of the Subversion team sitting at my table proved useful. ;-) It turns out the hotel had some kind of goofy firewall setup which pooched outbound REPORT requests. For what it's worth, I've never encountered that problem elsewhere, and in that case, I just switched to HTTPS to work around it, as you say. -wsv On May 30, 2006, at 3:12 AM, Julian Reschke wrote: > I've been supporting WebDAV components for a *very* large company > for several years, and I don't remember a single case where we had > to deal with intermediates screwing up "new" HTTP methods. That may > be caused by the type of customers we had, but anyway. > > *If* there is a problem, switching to HTTPS solves it anyway. > > Finally, keep in mind that Subversion (ra_dav) uses the same > methods and doesn't seem to have a problem here... Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B6E467F799 for ; Tue, 30 May 2006 05:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A82A7142285 for ; Tue, 30 May 2006 05:49:00 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07757-08 for ; Tue, 30 May 2006 05:48:58 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0486D14226C for ; Tue, 30 May 2006 05:48:58 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id BC38BB7 for ; Tue, 30 May 2006 12:48:55 +0000 (GMT) Received: from ca28 [165.212.11.128] by cmsout03.mbox.net via smtad (C8.MAIN.3.27X); Tue, 30 May 2006 12:48:56 GMT X-USANET-Source: 165.212.11.128 IN cbryant-ical@corp.usa.net ca28 X-USANET-MsgId: XID697kedmW50467X03 Received: from cbryantlt2 [165.212.225.1] by ca28 (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 804kedmW20222M28; Tue, 30 May 2006 12:48:53 GMT X-USANET-Auth: 165.212.225.1 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <007401c683e7$684b30c0$6501a8c0@corp.usa.net> From: "Chris Bryant" To: "CalDAV DevList" References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com><28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com><447C1A80.7040700@gmx.de> <1F01125F-56F3-4D04-84A3-44F1349A7244@opengroupware.org> Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 08:48:52 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID804kedmW30222X28 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 12:49:00 -0000 ----- Original Message ----- From: "Helge Hess" Sent: Tuesday, May 30, 2006 6:26 AM > Actually I think that vfb-GET is complementory to CalDAV and doesn't need > to be specified in there. Very much like iCalendar-over-HTTP which is > also likely to be implemented by server vendors in addition. If vendors are likely to implement free-busy via GET, what defines how that will be done, or is each vendor going to decide that on their own? If clients hope to use that method, doesn't it make sense to try to make it reasonably standard? Is there a way to put things like this into the spec as optional, with some way to query what features the server supports? Chris Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CE12E7F799 for ; Tue, 30 May 2006 05:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BFA3D142285 for ; Tue, 30 May 2006 05:48:23 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10128-09 for ; Tue, 30 May 2006 05:48:23 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by laweleka.osafoundation.org (Postfix) with ESMTP id E180014226C for ; Tue, 30 May 2006 05:48:22 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 36so1262991wra for ; Tue, 30 May 2006 05:48:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=q5uB+q2/JGf+rHwjIt2qH2xAROnH9pFZJ9u4d4RmIzStA1LtlLFeM130dxTwWd3BpI95Tn+l/7PRivb+7CCA7V8qjI20N3Z0qlse3qZwTTIw5DL1xaG7WSvS6DCPKMqlB2jfVLsWcjQXmNKcn4FqgtIlHR6mgIEbqp1RwkYE/5c= Received: by 10.65.189.2 with SMTP id r2mr1642304qbp; Tue, 30 May 2006 05:48:19 -0700 (PDT) Received: from ?9.33.78.47? ( [129.33.1.37]) by mx.gmail.com with ESMTP id z21sm1157277qbc.2006.05.30.05.48.18; Tue, 30 May 2006 05:48:18 -0700 (PDT) Message-ID: <447C3F10.2050405@gmail.com> Date: Tue, 30 May 2006 08:48:16 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> <447B7D61.7030002@adevsoft.com> <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> <447BABB8.3080803@gmail.com> <52B15376-60D9-44BB-85BC-C96AA650D8A2@opengroupware.org> In-Reply-To: <52B15376-60D9-44BB-85BC-C96AA650D8A2@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, RCVD_IN_SORBS_WEB X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 12:48:23 -0000 Helge Hess wrote: > On 30. Mai 2006, at 04:19 Uhr, Robert Yates wrote: > >> I think it depends what you are going to be doing with the freebusy >> time once you have parsed it. One of the things that we frequently >> do with freebusy time is convert it to (x)html for rendering. If >> the freebusy time was in xml then one xslt script, utilizing xpath, >> is all you need. > > > Or a similiarily complex (trivial) JavaScript. Really, its just > freebusy, not full iCalendar. Do you have an example which really > uses XSLT (or even DOM) to convert a freebusy into HTML??? > I don't have an example and it is a fair point that this is not the strongest of arguments. What I was getting at is that there are reasons for using xml that are beyond just parsing. XSLT is one example of this but there are others such as XML signing and XML encryption. From a purely parsing perspective, if you already have an iCal parser then there is probably not much in it. However there are more to data formats than just parsing. Rob Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 661DE7F858 for ; Tue, 30 May 2006 03:29:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 58ACF142281 for ; Tue, 30 May 2006 03:29:36 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17956-08 for ; Tue, 30 May 2006 03:29:33 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8519C14227F for ; Tue, 30 May 2006 03:29:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id DAA283F66FE for ; Tue, 30 May 2006 12:26:06 +0200 (CEST) Received: from [192.168.0.233] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 605353EF2C9 for ; Tue, 30 May 2006 12:26:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <447C1A80.7040700@gmx.de> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com> <447C1A80.7040700@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F01125F-56F3-4D04-84A3-44F1349A7244@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 12:26:44 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 10:29:36 -0000 On 30. Mai 2006, at 12:12 Uhr, Julian Reschke wrote: > Finally, keep in mind that Subversion (ra_dav) uses the same > methods and doesn't seem to have a problem here... Actually this is the sample case where its widely known that there are problems. Its even documented in the Subversion FAQ: http://subversion.tigris.org/faq.html#proxy I occasionally ran into this issue a few years (~2-4?) ago when working at client sites. But the issue seems to have vanished in the meantime (probably proxy stuff got updated), at least I don't remember having problems with Svn connects lately. Anyway, not using WebDAV methods for Cal*DAV* would be absurd for obvious reasons ;-) Actually I think that vfb-GET is complementory to CalDAV and doesn't need to be specified in there. Very much like iCalendar-over-HTTP which is also likely to be implemented by server vendors in addition. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7EEBB7F874 for ; Tue, 30 May 2006 03:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 70F6B142285 for ; Tue, 30 May 2006 03:12:20 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06592-03 for ; Tue, 30 May 2006 03:12:19 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 61A97142281 for ; Tue, 30 May 2006 03:12:19 -0700 (PDT) Received: (qmail invoked by alias); 30 May 2006 10:12:17 -0000 Received: from p508FAE4A.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.174.74] by mail.gmx.net (mp010) with SMTP; 30 May 2006 12:12:17 +0200 X-Authenticated: #1915285 Message-ID: <447C1A80.7040700@gmx.de> Date: Tue, 30 May 2006 12:12:16 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jay Batson Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com> In-Reply-To: <28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 10:12:20 -0000 Jay Batson schrieb: > IT MUST WORK THROUGH EXISTING FIREWALLS, no questions asked, no user or > IT manager intervention required. > > I don't know what the level of firewall transparency / non-transparency > of REPORT is. But we should find out before we put CalDAV into stone. > If there is some reasonable chance that the REPORT method will not work > through a standard enterprise Stateful Multi-layer Inspection firewall > (e.g. Checkpoint, Cisco), it should NOT be used in the specification. I've been supporting WebDAV components for a *very* large company for several years, and I don't remember a single case where we had to deal with intermediates screwing up "new" HTTP methods. That may be caused by the type of customers we had, but anyway. *If* there is a problem, switching to HTTPS solves it anyway. Finally, keep in mind that Subversion (ra_dav) uses the same methods and doesn't seem to have a problem here... > I don't care what anybody says: Firewall vendors are TRULY SLOW to > implement new stuff for protocol examination. They have a massive > backlog of things for which support has been requested, and they *only* > do the ones that are hugely, hugely visible and on which they think they > can get people to pay for in a software upgrade. > > Compare with SIP: This IETF SIP protocol has truly massive telecom / > datacom industry attention, and yet 9 years after the first draft of > SIP, and numerous RFCs later, it is *still* not supported natively in > most major firewalls. It is a significant factor blocking the > deployment of many SIP-based products and services. Well, SIP is different in that it isn't HTTP. The only thing "special" in WebDAV/CalDAV is the use of HTTP methods not defined in RFC2616, and as far as I can tell, this causes no problems at all. > I'm going to go out on a limb and say that if your firewall doesn't let > REPORT through today, you won't see it get through for at least 5 years > or more. CalDAV doesn't need that. I guess it would be helpful if you could actually point to existing implementations having that problem. Saying that there may be some isn't really helpful... > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 64DE47F700 for ; Tue, 30 May 2006 03:06:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 556D8142285 for ; Tue, 30 May 2006 03:06:51 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19123-09 for ; Tue, 30 May 2006 03:06:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 57880142281 for ; Tue, 30 May 2006 03:06:48 -0700 (PDT) Received: (qmail invoked by alias); 30 May 2006 10:06:46 -0000 Received: from p508FAE4A.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.174.74] by mail.gmx.net (mp036) with SMTP; 30 May 2006 12:06:46 +0200 X-Authenticated: #1915285 Message-ID: <447C1934.90007@gmx.de> Date: Tue, 30 May 2006 12:06:44 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Robert Yates Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> <447B7D61.7030002@adevsoft.com> <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> <447BABB8.3080803@gmail.com> In-Reply-To: <447BABB8.3080803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, TW_LH X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 10:06:51 -0000 Robert Yates schrieb: > Helge Hess wrote: > >> On 30. Mai 2006, at 01:01 Uhr, Kervin L. Pierre wrote: >> >>> (i) DOM and XPath gives manipulating XML a strong >>> advantage. >> >> >> Do you really need this for _freebusy_? I mean its just two time >> items and a status ... ;-) >> > I think it depends what you are going to be doing with the freebusy time > once you have parsed it. One of the things that we frequently do with > freebusy time is convert it to (x)html for rendering. If the freebusy > time was in xml then one xslt script, utilizing xpath, is all you need. > You can even do this in the browser using xmlhttprequest to issue an > HTTP GET and retrieve the response. > > Another advantages of using an HTTP GET method and XML payloads for > freebusy lookups is that browsers support both of them. No browser that > I know of supports the REPORT method in its XMLHttpRequest options. The IE6? Firefox? > soon to be standard for XMLHttpRequest > http://www.w3.org/TR/XMLHttpRequest/#dfn-open also does not support it. That's still under discussion. And btw this is exactly the reason why I'm so opposed to have Xhr only support a subset of HTTP: it restricts other standards bodies to choose the HTTP extension points they want (Lisa: I think the IESG really should take a position in the W3C webapi mailing list regarding this topic). > All the browsers also contain an XML parser and an XSLT processor. > Wouldn't we want browsers to be able to easily make freebusy time > lookups. The browser as a client seems like a really important use case > to me. Best regards, Julian Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E0A97F700; Mon, 29 May 2006 21:35:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F31014226F; Mon, 29 May 2006 21:35:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02940-08; Mon, 29 May 2006 21:35:38 -0700 (PDT) Received: from plumcanary.com (sync.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3CF7014226D; Mon, 29 May 2006 21:35:38 -0700 (PDT) Received: from [192.168.0.2] (c-24-61-128-227.hsd1.ma.comcast.net [24.61.128.227]) by plumcanary.com (8.12.11.20060308/8.12.10) with ESMTP id k4U4ZWOs022016; Tue, 30 May 2006 00:35:33 -0400 In-Reply-To: <44775A08.3030200@gmail.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28F06C17-8E3E-4FD5-89A0-36C0F2D5E7A0@plumcanary.com> Content-Transfer-Encoding: 7bit From: Jay Batson Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 00:35:35 -0400 To: Robert Yates X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 04:35:40 -0000 I'm late to the reply here, a couple of days having elapsed. However, it doesn't appear the issue is closed. So here's my 2 cents: The iCalendar vs. XML data format issue is one I don't feel overly strongly about. I tend to favor iCalendar for all the reasons already stated, but would support an optional XML representation, and possible use of HTTP ACCEPT header to request the server to return whatever I prefer (if it can handle it). However, the HUGE item for me is: On May 26, 2006, at 3:42 PM, Robert Yates wrote: > I agree that the format is one of the points that I am raising, but > it is not the only one. Calendar implementors don't presently have > in their toolkits client or server libraries for the REPORT http > method. Additionally, customers may not have firewall policies that > allow non http 1.1 methods through. At present, we are concerned > about using PUT and DELETE http methods as there are firewall > issues even with those (from the AtomPub list http://www.imc.org/ > atom-protocol/mail-archive/msg04436.html). I am uncertain as to the > implications of mandating REPORT. > > My main point is that the majority of web applications today follow > a certain style for their apis. Conforming to that style means that > tooling and libraries are readily available and that firewalls will > let the traffic through. Diverging from this safety of numbers > leads to additional work for developers and customers. It can and > should be done, but only if there are concrete benefits in doing so. I just lived through a 7-year effort to work on SIP-based products. After busting our buns for 7 years to create a truly-great-IETF- protocol, Skype made us all look like fools in one short effort. They did several things right, but one of the key rules was: IT MUST WORK THROUGH EXISTING FIREWALLS, no questions asked, no user or IT manager intervention required. I don't know what the level of firewall transparency / non- transparency of REPORT is. But we should find out before we put CalDAV into stone. If there is some reasonable chance that the REPORT method will not work through a standard enterprise Stateful Multi-layer Inspection firewall (e.g. Checkpoint, Cisco), it should NOT be used in the specification. I don't care what anybody says: Firewall vendors are TRULY SLOW to implement new stuff for protocol examination. They have a massive backlog of things for which support has been requested, and they *only* do the ones that are hugely, hugely visible and on which they think they can get people to pay for in a software upgrade. Compare with SIP: This IETF SIP protocol has truly massive telecom / datacom industry attention, and yet 9 years after the first draft of SIP, and numerous RFCs later, it is *still* not supported natively in most major firewalls. It is a significant factor blocking the deployment of many SIP-based products and services. I'm going to go out on a limb and say that if your firewall doesn't let REPORT through today, you won't see it get through for at least 5 years or more. CalDAV doesn't need that. Please, please - somebody do a quick look into this, and consider firewall transparency a "must resolve" issue before solidifying anything in CalDAV. If there is even a shred of doubt, implement this using *** only *** GET and POST. In don't consider the presence of / lack of toolkits or libraries for clients or servers a meaningful factor; if the RFC settles down, the appropriate stuff will appear soon enough in either commercially or in open source. All that is important is making it through firewalls. -jb ------------- Jay Batson batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3F3207F768 for ; Mon, 29 May 2006 20:34:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3004A142267 for ; Mon, 29 May 2006 20:34:55 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18660-02 for ; Mon, 29 May 2006 20:34:51 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by laweleka.osafoundation.org (Postfix) with ESMTP id BD4B2142264 for ; Mon, 29 May 2006 20:34:51 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc12) with SMTP id <20060530033450m1200j1v24e>; Tue, 30 May 2006 03:34:50 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Mon, 29 May 2006 23:34:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <52B15376-60D9-44BB-85BC-C96AA650D8A2@opengroupware.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaDkMwid0REzZeUQNaMIqQVwvxiwAACHAHg Message-Id: <20060530033451.BD4B2142264@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.8 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID, TW_LH, TW_VF X-Spam-Level: * X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 03:34:55 -0000 I have to differ here. Displaying free/busy in a UI is the least important use case I can think of. The really important use case for free/busy is in scheduling (i.e. meetings), between calendar implementations. While display of free/busy is nice, that implies human scheduling; I'd like to have my UA and your UA (through are respective calendar applications) at least make a good 'first guess' before asking me. I can still see that XML has advantages for exchanging free/busy between programs - available parsers and tools, etcetera - but they aren't overwhelming, to me. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Helge Hess Sent: Monday, May 29, 2006 10:26 PM To: CalDAV DevList Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? On 30. Mai 2006, at 04:19 Uhr, Robert Yates wrote: > I think it depends what you are going to be doing with the freebusy > time once you have parsed it. One of the things that we frequently > do with freebusy time is convert it to (x)html for rendering. If > the freebusy time was in xml then one xslt script, utilizing xpath, > is all you need. Or a similiarily complex (trivial) JavaScript. Really, its just freebusy, not full iCalendar. Do you have an example which really uses XSLT (or even DOM) to convert a freebusy into HTML??? > You can even do this in the browser using xmlhttprequest to issue > an HTTP GET and retrieve the response. Same for vfb. > Another advantages of using an HTTP GET method and XML payloads for > freebusy lookups is that browsers support both of them. I'm very much in favor of using HTTP GET. But using XML in the payload (_for freebusy_) doesn't help you a lot. Parsing the vfb is as easy as using XSLT (probably much easier). > No browser that I know of supports the REPORT method in its > XMLHttpRequest options. The soon to be standard for XMLHttpRequest > http://www.w3.org/TR/XMLHttpRequest/#dfn-open also does not support > it. All the browsers also contain an XML parser and an XSLT processor. > Wouldn't we want browsers to be able to easily make freebusy time > lookups. The browser as a client seems like a really important use > case to me. Not for me so much but apparently a lot of people think its a smart idea ;-) Anyway, as mentioned I'm in favor of GET, but not necessarily of replacing the payload format. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org _______________________________________________ Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 207067F781 for ; Mon, 29 May 2006 19:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1226A14225E for ; Mon, 29 May 2006 19:28:53 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09843-01 for ; Mon, 29 May 2006 19:28:50 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54EC3142269 for ; Mon, 29 May 2006 19:28:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5FDBE3F1DBB for ; Tue, 30 May 2006 04:25:21 +0200 (CEST) Received: from [192.168.0.233] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 003913F1A9D for ; Tue, 30 May 2006 04:25:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <447BABB8.3080803@gmail.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> <447B7D61.7030002@adevsoft.com> <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> <447BABB8.3080803@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52B15376-60D9-44BB-85BC-C96AA650D8A2@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 04:26:00 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, TW_LH, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 02:28:53 -0000 On 30. Mai 2006, at 04:19 Uhr, Robert Yates wrote: > I think it depends what you are going to be doing with the freebusy > time once you have parsed it. One of the things that we frequently > do with freebusy time is convert it to (x)html for rendering. If > the freebusy time was in xml then one xslt script, utilizing xpath, > is all you need. Or a similiarily complex (trivial) JavaScript. Really, its just freebusy, not full iCalendar. Do you have an example which really uses XSLT (or even DOM) to convert a freebusy into HTML??? > You can even do this in the browser using xmlhttprequest to issue > an HTTP GET and retrieve the response. Same for vfb. > Another advantages of using an HTTP GET method and XML payloads for > freebusy lookups is that browsers support both of them. I'm very much in favor of using HTTP GET. But using XML in the payload (_for freebusy_) doesn't help you a lot. Parsing the vfb is as easy as using XSLT (probably much easier). > No browser that I know of supports the REPORT method in its > XMLHttpRequest options. The soon to be standard for XMLHttpRequest > http://www.w3.org/TR/XMLHttpRequest/#dfn-open also does not support > it. All the browsers also contain an XML parser and an XSLT processor. > Wouldn't we want browsers to be able to easily make freebusy time > lookups. The browser as a client seems like a really important use > case to me. Not for me so much but apparently a lot of people think its a smart idea ;-) Anyway, as mentioned I'm in favor of GET, but not necessarily of replacing the payload format. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3B4667F72D for ; Mon, 29 May 2006 19:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2085C142269 for ; Mon, 29 May 2006 19:19:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08277-01 for ; Mon, 29 May 2006 19:19:39 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by laweleka.osafoundation.org (Postfix) with ESMTP id 974A214225E for ; Mon, 29 May 2006 19:19:39 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 36so1181864wra for ; Mon, 29 May 2006 19:19:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dSYboqD27B3WpUMgC0PWUT2P6D5v8BZjUV3+Qr5dlnNMT5r16A7lbMM/zgdM1QP57hbP0PZS4a4luJouEpyN/XsN7M+YYBUkK+s2Jda9To1VzM/iuCxvVa+ilnB1ZQ1YgA42sJfDlBifNzWsVhibFo/o84faGizC31mTEeE9Qm4= Received: by 10.65.220.5 with SMTP id x5mr1422295qbq; Mon, 29 May 2006 19:19:39 -0700 (PDT) Received: from ?192.168.1.3? ( [66.30.206.61]) by mx.gmail.com with ESMTP id q14sm1075933qbq.2006.05.29.19.19.38; Mon, 29 May 2006 19:19:38 -0700 (PDT) Message-ID: <447BABB8.3080803@gmail.com> Date: Mon, 29 May 2006 22:19:36 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> <447B7D61.7030002@adevsoft.com> <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> In-Reply-To: <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, TW_LH X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 02:19:40 -0000 Helge Hess wrote: > On 30. Mai 2006, at 01:01 Uhr, Kervin L. Pierre wrote: > >> (i) DOM and XPath gives manipulating XML a strong >> advantage. > > > Do you really need this for _freebusy_? I mean its just two time > items and a status ... ;-) > I think it depends what you are going to be doing with the freebusy time once you have parsed it. One of the things that we frequently do with freebusy time is convert it to (x)html for rendering. If the freebusy time was in xml then one xslt script, utilizing xpath, is all you need. You can even do this in the browser using xmlhttprequest to issue an HTTP GET and retrieve the response. Another advantages of using an HTTP GET method and XML payloads for freebusy lookups is that browsers support both of them. No browser that I know of supports the REPORT method in its XMLHttpRequest options. The soon to be standard for XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#dfn-open also does not support it. All the browsers also contain an XML parser and an XSLT processor. Wouldn't we want browsers to be able to easily make freebusy time lookups. The browser as a client seems like a really important use case to me. Rob Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6B25C7F74E for ; Mon, 29 May 2006 16:32:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BD96142273 for ; Mon, 29 May 2006 16:32:53 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08430-08 for ; Mon, 29 May 2006 16:32:50 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 86CB8142272 for ; Mon, 29 May 2006 16:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id B93F53F6725 for ; Tue, 30 May 2006 01:29:20 +0200 (CEST) Received: from [192.168.0.233] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 551FD3F655C for ; Tue, 30 May 2006 01:29:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <447B7D61.7030002@adevsoft.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> <447B7D61.7030002@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7740205D-8995-483E-A015-5B08651D8F7F@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Tue, 30 May 2006 01:29:59 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 23:32:53 -0000 On 30. Mai 2006, at 01:01 Uhr, Kervin L. Pierre wrote: > (i) DOM and XPath gives manipulating XML a strong > advantage. Do you really need this for _freebusy_? I mean its just two time items and a status ... ;-) > libical, jical, etc. are all very mature libraries > but hopefully there will be some migration path in > the future for client/server developers who'd want to > make the leap to XML only. Well, XML is just the syntax (you can easily write a DOM builder/SAX driver for the iCal/vCard tag format, indeed this is how we do it). What makes iCalendar parsing hard is mostly the semantics (eg decoding/calculating recurrences, dealing with timezones), XML doesn't help here at all. Anyway, I would also favor XML. But there are almost no points for it when we consider iCalendar _freebusy_ and few if we consider full iCalendar. In the same run you would instantly loose access to the existing infrastructure. So personally I'm OK with the current setup. Require iCalendar in CalDAV. And if server implementors want to do something in addition (JSON or XML or whatever), they can still do this by using HTTP 'accept'. I'm not sure I correctly followed the arguments by Lisa on 'accept'. Can't we require CalDAV clients to send a specific 'accept' header? (eg disallow */* ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B69D57F70B for ; Mon, 29 May 2006 15:59:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A83D814226D for ; Mon, 29 May 2006 15:59:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22338-08 for ; Mon, 29 May 2006 15:59:40 -0700 (PDT) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by laweleka.osafoundation.org (Postfix) with SMTP id 04BA714226C for ; Mon, 29 May 2006 15:59:39 -0700 (PDT) Received: (qmail 46414 invoked from network); 29 May 2006 22:59:39 -0000 Received: from unknown (HELO ?192.168.1.3?) (kervin@adevsoft.com@72.156.251.193 with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 29 May 2006 22:59:39 -0000 Message-ID: <447B7D61.7030002@adevsoft.com> Date: Mon, 29 May 2006 19:01:53 -0400 From: "Kervin L. Pierre" Organization: Adevsoft Inc User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, TW_VF X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 22:59:42 -0000 Hello, Helge Hess wrote: > Personally I think iCalendar freebusy files are sufficiently simple to > parse, no need to go for XML here. Especially because a lot of > infrastructure already works-with / deploys vfb over HTTP/FTP. > I think any chance there is to replace iCalendar with a XML grammer should be considered. (i) DOM and XPath gives manipulating XML a strong advantage. (ii) Also, although not pressing issue, but _eventually_ moving from iCalendar to a XML grammar would allow CalDAV clients to have a single parser dependency instead of two. Ultimately simplifying CalDAV software just a bit. libical, jical, etc. are all very mature libraries but hopefully there will be some migration path in the future for client/server developers who'd want to make the leap to XML only. Best regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6425A7F838 for ; Mon, 29 May 2006 12:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 55A58142272 for ; Mon, 29 May 2006 12:44:06 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20997-02 for ; Mon, 29 May 2006 12:44:04 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by laweleka.osafoundation.org (Postfix) with ESMTP id EEE4F142279 for ; Mon, 29 May 2006 12:44:03 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 9so1168089nzo for ; Mon, 29 May 2006 12:44:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bHrhPqEecuHbsFRW8Ztd1kc5ay500++8i6HBoajOPKH2ew8ZJ+o1m/hDcntC4t/A0kA9MmTqxM9Bvk2p7/xZv0fXpx5WbD8ipYDC5JK0j+ZliYilqZdRHHc1PpUIKMMTDfWLrjn/BLESmPCcFvNsLrfUoZGEgEwtRSRcsMv8IfE= Received: by 10.36.20.8 with SMTP id 8mr3386862nzt; Mon, 29 May 2006 12:44:03 -0700 (PDT) Received: by 10.37.22.19 with HTTP; Mon, 29 May 2006 12:44:03 -0700 (PDT) Message-ID: <29a761a00605291244t35c1c500t726280cea9244f4f@mail.gmail.com> Date: Mon, 29 May 2006 12:44:03 -0700 From: "Brian Moseley" Sender: ixjonez@gmail.com To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> X-Google-Sender-Auth: f17a6df6aaf235a3 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 19:44:06 -0000 On 5/29/06, Helge Hess wrote: > Personally I think iCalendar freebusy files are sufficiently simple > to parse, no need to go for XML here. Especially because a lot of > infrastructure already works-with / deploys vfb over HTTP/FTP. i'd be fine with that as well. GET vs REPORT is the important issue to me. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8DB8D7F74A for ; Mon, 29 May 2006 12:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7EA6C142279 for ; Mon, 29 May 2006 12:39:56 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19376-05 for ; Mon, 29 May 2006 12:39:54 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D3AC142272 for ; Mon, 29 May 2006 12:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id AEBB73F552A for ; Mon, 29 May 2006 21:36:49 +0200 (CEST) Received: from [10.84.42.118] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 51F2F3F4EC3 for ; Mon, 29 May 2006 21:36:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Mon, 29 May 2006 21:39:44 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, TW_VF X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 19:39:56 -0000 On May 29, 2006, at 9:25 PM, Brian Moseley wrote: > On 5/26/06, Robert Yates wrote: >> While one of the points raised is around data formats, I don't >> want to >> loose the original question, namely, "should freebusy lookup >> utilize the >> http GET method and return an xml payload in its response?". I >> would be >> very interested in implementors views on this. > i strongly agree that this approach has a lot of benefits, and i plan > for cosmo to support some version of it, even if not specified by a > standard, though that would obviously be preferable. BTW: Exchange also supports some XML format for freebusy. I think its used primarily by Outlook Web Access, but was also used in the Ximian Exchange Connector, which is why we also have(/had?) support for that in OGo. Personally I think iCalendar freebusy files are sufficiently simple to parse, no need to go for XML here. Especially because a lot of infrastructure already works-with / deploys vfb over HTTP/FTP. Greets, Helge Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D76187F838 for ; Mon, 29 May 2006 12:25:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C9552142279 for ; Mon, 29 May 2006 12:25:44 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02008-09 for ; Mon, 29 May 2006 12:25:44 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CA04142278 for ; Mon, 29 May 2006 12:25:44 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 9so1164990nzo for ; Mon, 29 May 2006 12:25:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GD1RO/kMdQ8OT3g7g7m4TTmKKyUNGunsh7qhYGhL+B8oSCwoW45qESgFcrn7lnm+G6smMDy5aNYWsOYqkluGGWL3wFQ8VEPrNQMToYUdgq7IQnEy0gOST5uDM16l92H/tGpM3O3FA/TRcDxAgrS0C8FATrreBWYufbc6F1bUp1s= Received: by 10.36.84.10 with SMTP id h10mr3356407nzb; Mon, 29 May 2006 12:25:43 -0700 (PDT) Received: by 10.37.22.19 with HTTP; Mon, 29 May 2006 12:25:43 -0700 (PDT) Message-ID: <29a761a00605291225s74508b43ve57a11f9bf955a27@mail.gmail.com> Date: Mon, 29 May 2006 12:25:43 -0700 From: "Brian Moseley" Sender: ixjonez@gmail.com To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? In-Reply-To: <44775A08.3030200@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> X-Google-Sender-Auth: dd500c67740b0106 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 19:25:45 -0000 On 5/26/06, Robert Yates wrote: > While one of the points raised is around data formats, I don't want to > loose the original question, namely, "should freebusy lookup utilize the > http GET method and return an xml payload in its response?". I would be > very interested in implementors views on this. i strongly agree that this approach has a lot of benefits, and i plan for cosmo to support some version of it, even if not specified by a standard, though that would obviously be preferable. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E09447F84E for ; Mon, 29 May 2006 12:16:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D1481142278 for ; Mon, 29 May 2006 12:16:51 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11580-01 for ; Mon, 29 May 2006 12:16:50 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54E1E142273 for ; Mon, 29 May 2006 12:16:50 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 9so1163461nzo for ; Mon, 29 May 2006 12:16:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CRcUmOZxqFXvTIkPSqmWJ6xgEFNBAH65BQjX1magIsn69bMiDvGTVqIod8iY0KlxTE9D8tGVzlw45qoEMZSC6uFBunQKgSgkX6ar5Fg10r03wRpxLmY+OCCBXJkg8rWwpWiNR8fxioC396W8gb67FpDvhpmx74SuN8Sx1G7c2Cc= Received: by 10.36.221.50 with SMTP id t50mr3341153nzg; Mon, 29 May 2006 12:16:49 -0700 (PDT) Received: by 10.37.22.19 with HTTP; Mon, 29 May 2006 12:16:49 -0700 (PDT) Message-ID: <29a761a00605291216j7de8778el2a23f5d3c845d480@mail.gmail.com> Date: Mon, 29 May 2006 12:16:49 -0700 From: "Brian Moseley" Sender: ixjonez@gmail.com To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? In-Reply-To: <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> X-Google-Sender-Auth: 1ba92668e87dc3f4 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 19:16:52 -0000 On 5/26/06, Lisa Dusseault wrote: > Has the balance shifted? Are there more implementors interested in > CalDAV who don't have iCalendar libraries? Knowing that most > calendar software out there does export/import of iCal and thus > already has those libraries, do you believe that the balance of > effort calculations win out for a new format? it's not just icalendar. there still aren't mature webdav client libraries in the languages i work with most frequently (java, perl, php). it's almost trivial to write a client in any of those languages that can retrieve and process hcalendar via atom, but it's orders of magnitude more work to do icalendar over caldav. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A9847F7F9 for ; Mon, 29 May 2006 12:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C9E3142278 for ; Mon, 29 May 2006 12:14:17 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17029-02 for ; Mon, 29 May 2006 12:14:16 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC789142273 for ; Mon, 29 May 2006 12:14:16 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 9so1162979nzo for ; Mon, 29 May 2006 12:14:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=suv5og2sYj99GloG/BvGZYE9R5t+yljrDt4RXpUbMmgy1aoZ4o6nRu3jhVzjObXKg8V1xn9zwY6On4GBlclCQ9gk4McoIkjRA9evWuqW3OS9u5sGjYuJ2yjp5lqdeE7ix5qB5q4R3aFzvcsJMPZIRwrFJc/D3HEEAPnJvJFdD8o= Received: by 10.36.220.12 with SMTP id s12mr398394nzg; Mon, 29 May 2006 12:14:16 -0700 (PDT) Received: by 10.37.22.19 with HTTP; Mon, 29 May 2006 12:14:16 -0700 (PDT) Message-ID: <29a761a00605291214n30e8c7er7ec26a1b97a8c4ae@mail.gmail.com> Date: Mon, 29 May 2006 12:14:16 -0700 From: "Brian Moseley" Sender: ixjonez@gmail.com To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? In-Reply-To: <2F2E410E-2725-440F-A7EA-0140789E0CC9@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <173317D1-9F51-40C8-BB5F-70060A39BADB@osafoundation.org> <29a761a00605291116m4e7be0ecm5f4e5635194af7da@mail.gmail.com> <2F2E410E-2725-440F-A7EA-0140789E0CC9@osafoundation.org> X-Google-Sender-Auth: a7ea004f2628d360 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 19:14:17 -0000 On 5/29/06, Lisa Dusseault wrote: > We can't put a note or requirement in CalDAV about any > *specific* other format, because those aren't standardized yet, and > there's rules about what documents you can reference in a Proposed > Standard. that's the part that was unclear, thanks. perhaps the caldav home page could specify alternate formats and their generally accepted media types that, while not necessarily formally standardized by the ietf, are known to be in use by one or more clients and servers. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1B5AF7F83C; Mon, 29 May 2006 11:34:39 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F3D5C142274; Mon, 29 May 2006 11:34:38 -0700 (PDT) In-Reply-To: <29a761a00605291116m4e7be0ecm5f4e5635194af7da@mail.gmail.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <173317D1-9F51-40C8-BB5F-70060A39BADB@osafoundation.org> <29a761a00605291116m4e7be0ecm5f4e5635194af7da@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F2E410E-2725-440F-A7EA-0140789E0CC9@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Mon, 29 May 2006 11:34:33 -0700 To: "Brian Moseley" X-Mailer: Apple Mail (2.749.3) Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 18:34:39 -0000 An HTTP client may indicate to a server which format it prefers using the Accept header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html The server could choose to ignore it and return whatever format it has, but in case both the client and the server have an alternate format they agree on, this allows the client to ask for the alternate format. This doesn't need mentioning in CalDAV because it's specified in HTTP, to the extent that a client can ask for any format it feels like. We can't put a note or requirement in CalDAV about any *specific* other format, because those aren't standardized yet, and there's rules about what documents you can reference in a Proposed Standard. Lisa On May 29, 2006, at 11:16 AM, Brian Moseley wrote: > On 5/29/06, Lisa Dusseault wrote: >> Cyrus & Bernard & I have been talking about this a long time as a way >> to transition to something even more XML friendly. I hadn't thought >> it needed to be mentioned in this spec because so far there's only >> one ACCEPT-able format. > > can you elaborate? i don't understand what you mean. > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6D5F27F749 for ; Mon, 29 May 2006 11:16:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F5BE142278 for ; Mon, 29 May 2006 11:16:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03939-10 for ; Mon, 29 May 2006 11:16:04 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.192]) by laweleka.osafoundation.org (Postfix) with ESMTP id E922B142273 for ; Mon, 29 May 2006 11:16:03 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 9so1151902nzo for ; Mon, 29 May 2006 11:16:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PuVYA2OO2rfVCKRm5RXHbnfCeONLcejZWZXlrXIWzPNpiQV8y9+38RG/po0OXPzk+bNL6fpkabP1kuRJD9KIDlqsgenjojjql+EKaNj3a6mATjzkV0mi6dbSlL9awb5gXhVncSP7S+77iVKFWYPncejbYuBBF/WqjzjMgVwivLE= Received: by 10.37.14.18 with SMTP id r18mr3292008nzi; Mon, 29 May 2006 11:16:01 -0700 (PDT) Received: by 10.37.22.19 with HTTP; Mon, 29 May 2006 11:16:01 -0700 (PDT) Message-ID: <29a761a00605291116m4e7be0ecm5f4e5635194af7da@mail.gmail.com> Date: Mon, 29 May 2006 11:16:01 -0700 From: "Brian Moseley" Sender: ixjonez@gmail.com To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? In-Reply-To: <173317D1-9F51-40C8-BB5F-70060A39BADB@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> <173317D1-9F51-40C8-BB5F-70060A39BADB@osafoundation.org> X-Google-Sender-Auth: f870a3b27a78ee25 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 18:16:04 -0000 On 5/29/06, Lisa Dusseault wrote: > Cyrus & Bernard & I have been talking about this a long time as a way > to transition to something even more XML friendly. I hadn't thought > it needed to be mentioned in this spec because so far there's only > one ACCEPT-able format. can you elaborate? i don't understand what you mean. Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F9F47F868 for ; Mon, 29 May 2006 11:04:53 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F56D142260; Mon, 29 May 2006 11:04:53 -0700 (PDT) In-Reply-To: References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <173317D1-9F51-40C8-BB5F-70060A39BADB@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Mon, 29 May 2006 11:04:42 -0700 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.749.3) Cc: Jim Whitehead , Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 18:04:53 -0000 Cyrus & Bernard & I have been talking about this a long time as a way =20= to transition to something even more XML friendly. I hadn't thought =20 it needed to be mentioned in this spec because so far there's only =20 one ACCEPT-able format. Lisa On May 29, 2006, at 10:57 AM, Wilfredo S=E1nchez Vega wrote: > This does bring up one issue. > > Perhaps we should provide guidance/encouragement in the CalDAV =20 > spec on the use of the Accept header. As far as I know, most web =20 > clients do not provide a useful Accept header, which is problematic =20= > when a server can render a calendar component resource in both =20 > iCalendar and (eg.) hCalendar forms. > > -wsv > > > On May 26, 2006, at 3:13 PM, Jim Whitehead wrote: > >>> p.s. For the data format, my personal belief is that data models =20 >>> should be available in many formats. The hard work is actually =20 >>> producing and agreeing on the data model, mapping it to different =20= >>> representations is the easy bit. I would encourage the group to =20 >>> think about producing an xml representation for iCal. As well as =20= >>> being more consumable it has a standard approach for character =20 >>> encodings and allows the elements to be mixed with elements from =20 >>> other namespaces e.g. Location. >> >> I agree with this. The difficulty is not with the parsing, but =20 >> with the representation of the data model. I would like to see a =20 >> migration path to XML over time, as the ICalendar format is a =20 >> historical anomaly, a data format that gathered sufficient =20 >> internal momentum to not immediately be converted to XML. XML is =20 >> clearly a better long-term representation strategy, as it offers =20 >> better extensibility, and there is more tool support for XML. > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7F7307F866 for ; Mon, 29 May 2006 10:57:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 70C8E142287 for ; Mon, 29 May 2006 10:57:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18935-08 for ; Mon, 29 May 2006 10:57:23 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E3C8A142286 for ; Mon, 29 May 2006 10:57:23 -0700 (PDT) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4THvMbF024662; Mon, 29 May 2006 10:57:22 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id 7105C10; Mon, 29 May 2006 10:57:22 -0700 (PDT) In-Reply-To: References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Mon, 29 May 2006 10:57:21 -0700 To: Jim Whitehead X-Mailer: Apple Mail (2.749.3) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 17:57:25 -0000 This does bring up one issue. Perhaps we should provide guidance/encouragement in the CalDAV spec on the use of the Accept header. As far as I know, most web clients do not provide a useful Accept header, which is problematic when a server can render a calendar component resource in both iCalendar and (eg.) hCalendar forms. -wsv On May 26, 2006, at 3:13 PM, Jim Whitehead wrote: >> p.s. For the data format, my personal belief is that data models >> should be available in many formats. The hard work is actually >> producing and agreeing on the data model, mapping it to different >> representations is the easy bit. I would encourage the group to >> think about producing an xml representation for iCal. As well as >> being more consumable it has a standard approach for character >> encodings and allows the elements to be mixed with elements from >> other namespaces e.g. Location. > > I agree with this. The difficulty is not with the parsing, but with > the representation of the data model. I would like to see a > migration path to XML over time, as the ICalendar format is a > historical anomaly, a data format that gathered sufficient internal > momentum to not immediately be converted to XML. XML is clearly a > better long-term representation strategy, as it offers better > extensibility, and there is more tool support for XML. Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 007C47F87F for ; Fri, 26 May 2006 15:31:27 -0700 (PDT) Received: from [192.168.1.101] (ppp-71-139-173-73.dsl.snfc21.pacbell.net [71.139.173.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BADBE142273; Fri, 26 May 2006 15:31:26 -0700 (PDT) In-Reply-To: <4476F3D3.1040902@gmail.com> References: <4476F3D3.1040902@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49AA2966-7E10-4C2C-A5E8-08DB432CAC59@osafoundation.org> Content-Transfer-Encoding: 7bit From: Bobby Rullo Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Fri, 26 May 2006 15:31:21 -0700 To: Robert Yates X-Mailer: Apple Mail (2.750) Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 22:31:27 -0000 Robert, I have been working on a CalDAV library for java called....CalDAV4j. Documentation is sparse, as is functionality, but we're working on that. It does REPORT, but not freebusy yet. It uses ical4j (which is not daunting as it seems at first and is pretty well maintained) and is based of the WebDAV Slide Client library. Perhaps that could give you a good starting point. http://wiki.osafoundation.org/bin/view/Projects/CalDAV4jHome bobby On May 26, 2006, at 5:25 AM, Robert Yates wrote: > At yesterday's CalConnect roundtable I was encouraged to > participate in this mailing list. There were several interesting > discussions and in one of them it was pointed out to me that one of > the first integration points that is needed in Calendaring is > freebusy lookups. This makes a lot of sense to me. I went to the > CalDav spec to invetigate how hard it would be. > > Section 7.9.1 http://ietfreport.isoc.org/idref/draft-dusseault- > caldav/#page-65 has a very easy to understand example, so I then > went to look for java libraries for a consumer to use, the gory > details of this quest I describe here http://robubu.com/?p=8. In > summary, the http client of choice i.e. jakarta commons httpclient > does not support the REPORT http method. The only thing I could > find that did was a Slide WebDav library last updated in 2004. > This however has a dependency on a version of httpClient that is > end of life'd. I also would not want to write and maintain my own > iCal parser and so I went off to find one of those. I did > eventually find iCal4j, but I would then need to learn how to use > the parser, it's api is somewhat daunting, and get approval to ship > it from my legal department. > > Contrast this with an approach such as > > GET /bernard/work? > report=freebusy&start=20060104T140000Z&end=20060105T220000Z > Host: cal.example.com > > response > > HTTP/1.1 200 OK > Date: Fri, 11 Nov 2006 09:32:12 GMT > Content-Type: application/calendar+xml > Content-Length: xxxx > > > 2.0 > -//hacksw/handcal//NONSGML 1.0//EN > > 20060104T140000Z > 20060105T220000Z > 20060104T150000Z/PT1H > 20060104T190000Z/PT1H > > > > I can use httpClient (the up to date and suppported one) and java's > built in xml parser, something that I and others have done many > time before, no new learning curve. I can also quickly and easily > find approaches in ruby, php and python. > > It seems to me that something like freebusy time lookups needs to > be easily consumable. I was strongly encouraged yesterday to urge > my employer into adopting CalDav. Making a case would be much > simpler if end of life'd libraries, custom parsers and potentially > special firewall considerations for our customers weren't required. > Is it worth considering reports that utilize the GET http method > and payloads in xml format? > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0D0547F6F7; Fri, 26 May 2006 15:13:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1CFE142272; Fri, 26 May 2006 15:13:37 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32463-09; Fri, 26 May 2006 15:13:35 -0700 (PDT) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4DE91142270; Fri, 26 May 2006 15:13:35 -0700 (PDT) Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.6/8.13.1) with ESMTP id k4QMDXDh018172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 May 2006 15:13:33 -0700 (PDT) In-Reply-To: <44775A08.3030200@gmail.com> References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Whitehead Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Fri, 26 May 2006 15:13:32 -0700 To: Robert Yates , Ietf-caldav@osafoundation.org X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 22:13:38 -0000 On May 26, 2006, at 12:42 PM, Robert Yates wrote: > I agree that the format is one of the points that I am raising, but > it is not the only one. Calendar implementors don't presently have > in their toolkits client or server libraries for the REPORT http > method. It depends on the Calendar implementor. The Bedework project appears to have access to such a library. The Open Source Applications Foundation seems to have one too. But, hey, these are just open source projects, and hence don't have access to the same resource base as large software development organizations. > Additionally, customers may not have firewall policies that allow > non http 1.1 methods through. They may also have firewall policies that do not allow proprietary Calendar access protocols to go through. This issue is a bit of a red herring. If this is really a problem, then organizations can use a Web-based UI like Bedework, and users can access CalDAV via the Web UI. > At present, we are concerned about using PUT and DELETE http > methods as there are firewall issues even with those (from the > AtomPub list http://www.imc.org/atom-protocol/mail-archive/ > msg04436.html). Firewall issues tend to affect a new protocol for a period of about 1-3 years, during which time existing firewall implementations and deployment practice adapts to the new protocol. A protocol such as CalDAV has an expected lifespan of decades, and perhaps hundreds of years. > p.s. For the data format, my personal belief is that data models > should be available in many formats. The hard work is actually > producing and agreeing on the data model, mapping it to different > representations is the easy bit. I would encourage the group to > think about producing an xml representation for iCal. As well as > being more consumable it has a standard approach for character > encodings and allows the elements to be mixed with elements from > other namespaces e.g. Location. I agree with this. The difficulty is not with the parsing, but with the representation of the data model. I would like to see a migration path to XML over time, as the ICalendar format is a historical anomaly, a data format that gathered sufficient internal momentum to not immediately be converted to XML. XML is clearly a better long- term representation strategy, as it offers better extensibility, and there is more tool support for XML. That all said, I believe the correct current path is to make use of iCalendar, so that existing Calendaring applications can transition to CalDAV. These applications currently use iCalendar, and have access to parsing libraries. - Jim Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D7697F90A for ; Fri, 26 May 2006 13:55:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EABE14226D for ; Fri, 26 May 2006 13:55:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28900-02 for ; Fri, 26 May 2006 13:55:29 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id F32A714226B for ; Fri, 26 May 2006 13:55:28 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by cmsout01.mbox.net (Postfix) with ESMTP id E41A778022 for ; Fri, 26 May 2006 20:55:27 +0000 (GMT) Received: from uadvg137.cms.usa.net [165.212.11.137] by cmsout01.mbox.net via smtad (C8.MAIN.3.27X); Fri, 26 May 2006 20:55:28 GMT X-USANET-Source: 165.212.11.137 IN cbryant-ical@corp.usa.net uadvg137.cms.usa.net X-USANET-MsgId: XID299keZu4C5420X01 Received: from cbryantlt2 [165.212.225.1] by uadvg137.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 887keZu4Z0344M37; Fri, 26 May 2006 20:55:25 GMT X-USANET-Auth: 165.212.225.1 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <001d01c68106$b6356fa0$6501a8c0@corp.usa.net> From: "Chris Bryant" To: References: <4476F3D3.1040902@gmail.com><416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> <44775A08.3030200@gmail.com> Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Fri, 26 May 2006 16:55:24 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID887keZu4A0344X37 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 20:55:31 -0000 I'd be happy to see the freebusy retrieval available via GET, but I'd also like to see the entire REPORT method optional. It seems to me that many fat clients could perform typical synchronization with the server without using the REPORT methods at all. Implementation of the server would be much simpler without the reports, so simple client-server synchronization could be possible with a fairly low amount of effort. The reports really make the server much more complex and although they have a benefit for many applications, they are not really essential for synching. Personally, I'd prefer to see the freebusy data returned in ical form, not xml. Chris ----- Original Message ----- From: "Robert Yates" Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? > Lisa Dusseault wrote: > >> I see what's being proposed here as a tradeoff of what's easiest for >> some people, vs. easiest for others. I most often see those tradeoffs >> as "easy for client" vs. "easy for server", but that's not the division >> here. Instead, it's "easy for existing calendar software" vs. "easy for >> new, post-CalDAV calendar software". >> >> Since most of the participation in CalConnect and CalDAV has been from >> people who already had iCalendar libraries, which they were already >> using for calendar import and export and sometimes for iMIP/ iTIP, >> naturally the focus in CalDAV to date has been about re-using code from >> existing investments and not creating unnecessary new work. Usually >> that's a wise approach. >> >> Has the balance shifted? Are there more implementors interested in >> CalDAV who don't have iCalendar libraries? Knowing that most calendar >> software out there does export/import of iCal and thus already has those >> libraries, do you believe that the balance of effort calculations win >> out for a new format? > > I agree that the format is one of the points that I am raising, but it is > not the only one. Calendar implementors don't presently have in their > toolkits client or server libraries for the REPORT http method. > Additionally, customers may not have firewall policies that allow non http > 1.1 methods through. At present, we are concerned about using PUT and > DELETE http methods as there are firewall issues even with those (from the > AtomPub list http://www.imc.org/atom-protocol/mail-archive/msg04436.html). > I am uncertain as to the implications of mandating REPORT. > > My main point is that the majority of web applications today follow a > certain style for their apis. Conforming to that style means that tooling > and libraries are readily available and that firewalls will let the > traffic through. Diverging from this safety of numbers leads to additional > work for developers and customers. It can and should be done, but only if > there are concrete benefits in doing so. > > While one of the points raised is around data formats, I don't want to > loose the original question, namely, "should freebusy lookup utilize the > http GET method and return an xml payload in its response?". I would be > very interested in implementors views on this. > > Thanks, > > Rob > > p.s. For the data format, my personal belief is that data models should be > available in many formats. The hard work is actually producing and > agreeing on the data model, mapping it to different representations is the > easy bit. I would encourage the group to think about producing an xml > representation for iCal. As well as being more consumable it has a > standard approach for character encodings and allows the elements to be > mixed with elements from other namespaces e.g. Location. Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3C9837F7C6 for ; Fri, 26 May 2006 12:42:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2E379142280 for ; Fri, 26 May 2006 12:42:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17097-09 for ; Fri, 26 May 2006 12:42:03 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by laweleka.osafoundation.org (Postfix) with ESMTP id 293C2142278 for ; Fri, 26 May 2006 12:42:03 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id i20so175817wra for ; Fri, 26 May 2006 12:42:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WVnNLIijM9lGVud3dEngyTc/f5CSsaAU2Etl8lqsMk8qE3NFGVxdRdH3rnX4oZqUsfubCknAJLVgdT9nB52GD595Dni0+392YaLCi9I+xIxrxLr+AM1ChnLS04USyeb7ABdAxFn2OsFYaRmYRzvZsn0oRzjJ2zPixHSq01+88O0= Received: by 10.54.86.11 with SMTP id j11mr871201wrb; Fri, 26 May 2006 12:42:02 -0700 (PDT) Received: from ?9.33.157.42? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 38sm1085195wrl.2006.05.26.12.42.01; Fri, 26 May 2006 12:42:02 -0700 (PDT) Message-ID: <44775A08.3030200@gmail.com> Date: Fri, 26 May 2006 15:42:00 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> In-Reply-To: <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, RCVD_IN_SORBS_WEB X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 19:42:04 -0000 Lisa Dusseault wrote: > I see what's being proposed here as a tradeoff of what's easiest for > some people, vs. easiest for others. I most often see those > tradeoffs as "easy for client" vs. "easy for server", but that's not > the division here. Instead, it's "easy for existing calendar > software" vs. "easy for new, post-CalDAV calendar software". > > Since most of the participation in CalConnect and CalDAV has been > from people who already had iCalendar libraries, which they were > already using for calendar import and export and sometimes for iMIP/ > iTIP, naturally the focus in CalDAV to date has been about re-using > code from existing investments and not creating unnecessary new > work. Usually that's a wise approach. > > Has the balance shifted? Are there more implementors interested in > CalDAV who don't have iCalendar libraries? Knowing that most > calendar software out there does export/import of iCal and thus > already has those libraries, do you believe that the balance of > effort calculations win out for a new format? I agree that the format is one of the points that I am raising, but it is not the only one. Calendar implementors don't presently have in their toolkits client or server libraries for the REPORT http method. Additionally, customers may not have firewall policies that allow non http 1.1 methods through. At present, we are concerned about using PUT and DELETE http methods as there are firewall issues even with those (from the AtomPub list http://www.imc.org/atom-protocol/mail-archive/msg04436.html). I am uncertain as to the implications of mandating REPORT. My main point is that the majority of web applications today follow a certain style for their apis. Conforming to that style means that tooling and libraries are readily available and that firewalls will let the traffic through. Diverging from this safety of numbers leads to additional work for developers and customers. It can and should be done, but only if there are concrete benefits in doing so. While one of the points raised is around data formats, I don't want to loose the original question, namely, "should freebusy lookup utilize the http GET method and return an xml payload in its response?". I would be very interested in implementors views on this. Thanks, Rob p.s. For the data format, my personal belief is that data models should be available in many formats. The hard work is actually producing and agreeing on the data model, mapping it to different representations is the easy bit. I would encourage the group to think about producing an xml representation for iCal. As well as being more consumable it has a standard approach for character encodings and allows the elements to be mixed with elements from other namespaces e.g. Location. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D25E97F914 for ; Fri, 26 May 2006 12:37:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4980142273 for ; Fri, 26 May 2006 12:37:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11228-09 for ; Fri, 26 May 2006 12:37:39 -0700 (PDT) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by laweleka.osafoundation.org (Postfix) with ESMTP id 11730142272 for ; Fri, 26 May 2006 12:37:38 -0700 (PDT) To: ietf-caldav@osafoundation.org Date: Fri, 26 May 2006 15:26:03 -0400 Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Message-ID: <2139345@uncensored.citadel.org> From: "IGnatius T Foobar" Organization: Uncensored X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 19:37:40 -0000 >Has the balance shifted? Are there more implementors interested in >CalDAV who don't have iCalendar libraries? Knowing that most >calendar software out there does export/import of iCal and thus >already has those libraries, do you believe that the balance of >effort calculations win out for a new format? If you're looking for votes, tally one up over here for "strongly in favor of leveraging existing iCalendar libraries/software." There's an awful lot of calendar software out there, and it's all going to have to be retrofitted for CalDAV if you want CalDAV to be adopted in any meaningful capacity. The current draft is already quite complex -- please don't make it any more complex than it already is. Art Cancro Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5EEA97F79A for ; Fri, 26 May 2006 11:10:01 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 328D314228A; Fri, 26 May 2006 11:10:01 -0700 (PDT) In-Reply-To: <4476F3D3.1040902@gmail.com> References: <4476F3D3.1040902@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <416179D5-9148-432B-B3F9-DF687B3534BC@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Fri, 26 May 2006 11:09:51 -0700 To: Robert Yates X-Mailer: Apple Mail (2.749.3) Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 18:10:01 -0000 I see what's being proposed here as a tradeoff of what's easiest for some people, vs. easiest for others. I most often see those tradeoffs as "easy for client" vs. "easy for server", but that's not the division here. Instead, it's "easy for existing calendar software" vs. "easy for new, post-CalDAV calendar software". Since most of the participation in CalConnect and CalDAV has been from people who already had iCalendar libraries, which they were already using for calendar import and export and sometimes for iMIP/ iTIP, naturally the focus in CalDAV to date has been about re-using code from existing investments and not creating unnecessary new work. Usually that's a wise approach. Has the balance shifted? Are there more implementors interested in CalDAV who don't have iCalendar libraries? Knowing that most calendar software out there does export/import of iCal and thus already has those libraries, do you believe that the balance of effort calculations win out for a new format? Lisa On May 26, 2006, at 5:25 AM, Robert Yates wrote: > At yesterday's CalConnect roundtable I was encouraged to > participate in this mailing list. There were several interesting > discussions and in one of them it was pointed out to me that one of > the first integration points that is needed in Calendaring is > freebusy lookups. This makes a lot of sense to me. I went to the > CalDav spec to invetigate how hard it would be. > > Section 7.9.1 http://ietfreport.isoc.org/idref/draft-dusseault- > caldav/#page-65 has a very easy to understand example, so I then > went to look for java libraries for a consumer to use, the gory > details of this quest I describe here http://robubu.com/?p=8. In > summary, the http client of choice i.e. jakarta commons httpclient > does not support the REPORT http method. The only thing I could > find that did was a Slide WebDav library last updated in 2004. > This however has a dependency on a version of httpClient that is > end of life'd. I also would not want to write and maintain my own > iCal parser and so I went off to find one of those. I did > eventually find iCal4j, but I would then need to learn how to use > the parser, it's api is somewhat daunting, and get approval to ship > it from my legal department. > > Contrast this with an approach such as > > GET /bernard/work? > report=freebusy&start=20060104T140000Z&end=20060105T220000Z > Host: cal.example.com > > response > > HTTP/1.1 200 OK > Date: Fri, 11 Nov 2006 09:32:12 GMT > Content-Type: application/calendar+xml > Content-Length: xxxx > > > 2.0 > -//hacksw/handcal//NONSGML 1.0//EN > > 20060104T140000Z > 20060105T220000Z > 20060104T150000Z/PT1H > 20060104T190000Z/PT1H > > > > I can use httpClient (the up to date and suppported one) and java's > built in xml parser, something that I and others have done many > time before, no new learning curve. I can also quickly and easily > find approaches in ruby, php and python. > > It seems to me that something like freebusy time lookups needs to > be easily consumable. I was strongly encouraged yesterday to urge > my employer into adopting CalDav. Making a case would be much > simpler if end of life'd libraries, custom parsers and potentially > special firewall considerations for our customers weren't required. > Is it worth considering reports that utilize the GET http method > and payloads in xml format? > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 171B37F915 for ; Fri, 26 May 2006 10:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0870014227B for ; Fri, 26 May 2006 10:14:26 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31223-02 for ; Fri, 26 May 2006 10:14:24 -0700 (PDT) Received: from wilson.acpub.duke.edu (wilson.acpub.duke.edu [152.3.233.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 65CB6142280 for ; Fri, 26 May 2006 10:14:24 -0700 (PDT) Received: from [152.3.125.37] (dyn-152-3-125-37.oit.duke.edu [152.3.125.37]) by wilson.acpub.duke.edu (8.12.11.20060308/8.12.10-20060308/Duke-5.0.0) with ESMTP id k4QHELwI004923; Fri, 26 May 2006 13:14:21 -0400 (EDT) In-Reply-To: <4476F3D3.1040902@gmail.com> References: <4476F3D3.1040902@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael R Gettes Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Date: Fri, 26 May 2006 13:14:19 -0400 To: Robert Yates X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 17:14:26 -0000 Of course these are all reasonable ideas especially if it keeps a community based standards development process viable and prevents or limits vendors from developing alternate solutions. I think it is great that you investigated these kinds of issues, not so much as standards issues, but more standards adoption issues. As CalDAV is in last call - can we consider extensions to GET at this time or is this just not feasible now? I hope the answer is that we can try and address. /mrg On May 26, 2006, at 8:25, Robert Yates wrote: > It seems to me that something like freebusy time lookups needs to > be easily consumable. I was strongly encouraged yesterday to urge > my employer into adopting CalDav. Making a case would be much > simpler if end of life'd libraries, custom parsers and potentially > special firewall considerations for our customers weren't required. > Is it worth considering reports that utilize the GET http method > and payloads in xml format? Return-Path: X-Original-To: Ietf-caldav@osafoundation.org Delivered-To: Ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 804887F8E1 for ; Fri, 26 May 2006 05:26:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7036B142281 for ; Fri, 26 May 2006 05:26:37 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23925-08 for ; Fri, 26 May 2006 05:26:34 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by laweleka.osafoundation.org (Postfix) with ESMTP id AFE95142280 for ; Fri, 26 May 2006 05:26:34 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id i20so74015wra for ; Fri, 26 May 2006 05:26:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=MpG5Uf2WF08scz1My8+Q4O2tHaK+ds8/q6bSzm3DSy6Hf0wFag0UQfDFXyDScojgqjda5r8KDiU93KPe080jMs8eJOZ6Wrw+8xRLMNPVPhHpAQzUtEwCY+jp1hiWkDsE45pTYJKM+V+I48J0LS+xi6CnWdOmguYAB4dAhoKCMtg= Received: by 10.54.141.18 with SMTP id o18mr471721wrd; Fri, 26 May 2006 05:26:01 -0700 (PDT) Received: from ?192.168.1.3? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 24sm598489wrl.2006.05.26.05.25.59; Fri, 26 May 2006 05:26:00 -0700 (PDT) Message-ID: <4476F3D3.1040902@gmail.com> Date: Fri, 26 May 2006 08:25:55 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, URIBL_SBL X-Spam-Level: Subject: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 12:26:37 -0000 At yesterday's CalConnect roundtable I was encouraged to participate in this mailing list. There were several interesting discussions and in one of them it was pointed out to me that one of the first integration points that is needed in Calendaring is freebusy lookups. This makes a lot of sense to me. I went to the CalDav spec to invetigate how hard it would be. Section 7.9.1 http://ietfreport.isoc.org/idref/draft-dusseault-caldav/#page-65 has a very easy to understand example, so I then went to look for java libraries for a consumer to use, the gory details of this quest I describe here http://robubu.com/?p=8. In summary, the http client of choice i.e. jakarta commons httpclient does not support the REPORT http method. The only thing I could find that did was a Slide WebDav library last updated in 2004. This however has a dependency on a version of httpClient that is end of life'd. I also would not want to write and maintain my own iCal parser and so I went off to find one of those. I did eventually find iCal4j, but I would then need to learn how to use the parser, it's api is somewhat daunting, and get approval to ship it from my legal department. Contrast this with an approach such as GET /bernard/work?report=freebusy&start=20060104T140000Z&end=20060105T220000Z Host: cal.example.com response HTTP/1.1 200 OK Date: Fri, 11 Nov 2006 09:32:12 GMT Content-Type: application/calendar+xml Content-Length: xxxx 2.0 -//hacksw/handcal//NONSGML 1.0//EN 20060104T140000Z 20060105T220000Z 20060104T150000Z/PT1H 20060104T190000Z/PT1H I can use httpClient (the up to date and suppported one) and java's built in xml parser, something that I and others have done many time before, no new learning curve. I can also quickly and easily find approaches in ruby, php and python. It seems to me that something like freebusy time lookups needs to be easily consumable. I was strongly encouraged yesterday to urge my employer into adopting CalDav. Making a case would be much simpler if end of life'd libraries, custom parsers and potentially special firewall considerations for our customers weren't required. Is it worth considering reports that utilize the GET http method and payloads in xml format? Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DC0C87F737 for ; Tue, 23 May 2006 13:05:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC8AA14228D for ; Tue, 23 May 2006 13:05:09 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26384-02 for ; Tue, 23 May 2006 13:05:09 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0DE5814227E for ; Tue, 23 May 2006 13:05:09 -0700 (PDT) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4NK56w6003869 for ; Tue, 23 May 2006 14:05:07 -0600 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4NK54Tr017600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 23 May 2006 14:05:05 -0600 Message-ID: <44736AFF.6040500@oracle.com> Date: Tue, 23 May 2006 16:05:19 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: multipart/mixed; boundary="------------030906020501030104030802" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-desruisseaux-caldav-sched-01.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2006 20:05:10 -0000 This is a multi-part message in MIME format. --------------030906020501030104030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-desruisseaux-caldav-sched-01.txt Date: Tue, 23 May 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scheduling Extensions to CalDAV Author(s) : B. Desruisseaux, et al. Filename : draft-desruisseaux-caldav-sched-01.txt Pages : 35 Date : 2006-5-23 This document specifies a set of methods, headers and resource types that define the scheduling extension to the CalDAV protocol. CalDAV itself extends WebDAV, which extends HTTP. The new protocol elements defined here allow interoperable scheduling operations on a CalDAV repository. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-desruisseaux-caldav-sched-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-desruisseaux-caldav-sched-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030906020501030104030802 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-01.txt" Content-Type: text/plain Content-ID: <2006-5-23120544.I-D@ietf.org> --------------030906020501030104030802 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail."; filename*1="txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------030906020501030104030802-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8580A7F768 for ; Thu, 18 May 2006 17:17:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 759AB14229C for ; Thu, 18 May 2006 17:17:27 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23912-05; Thu, 18 May 2006 17:17:26 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id ECA50142295; Thu, 18 May 2006 17:17:25 -0700 (PDT) In-Reply-To: <446D08EE.8030300@gmx.de> References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> <446C011C.1030907@gmx.de> <15026E1D-33E2-424C-86FA-1B8A1192729D@osafoundation.org> <446D08EE.8030300@gmx.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AA6BFFA-B0F6-48D6-904C-A22AAFD646D7@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application Date: Thu, 18 May 2006 17:17:22 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 00:17:27 -0000 On May 18, 2006, at 4:53 PM, Julian Reschke wrote: > Lisa Dusseault schrieb: > >> Besides I'm pretty sure the overlap between calendar app people >> and TAG people is nearly coincidental and not large. If TAG has >> surveyed application developer interest groups like this one, I'd >> be interested to hear that. > > I'm not sure what you're talking about... The initial question was > whether it's more appropriate to define a new URI scheme (in > addition to http), rather than using a new MIME type to dispatch > from the browser. Are you saying that this is outside the scope of > the W3C TAG? Or alternatively, do you think it would be wise if > IETF and W3C recommend different approaches? Not at all. I'm hoping the discussion converges and that both groups are aware of the interest/activities of the other group. Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BB24D7F75B for ; Thu, 18 May 2006 16:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AAB4814228F for ; Thu, 18 May 2006 16:53:26 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19335-06 for ; Thu, 18 May 2006 16:53:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id B1900142297 for ; Thu, 18 May 2006 16:53:23 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2006 23:53:22 -0000 Received: from p508FC2A6.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.194.166] by mail.gmx.net (mp030) with SMTP; 19 May 2006 01:53:22 +0200 X-Authenticated: #1915285 Message-ID: <446D08EE.8030300@gmx.de> Date: Fri, 19 May 2006 01:53:18 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> <446C011C.1030907@gmx.de> <15026E1D-33E2-424C-86FA-1B8A1192729D@osafoundation.org> In-Reply-To: <15026E1D-33E2-424C-86FA-1B8A1192729D@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 23:53:26 -0000 Lisa Dusseault schrieb: > I thought TAG and other W3C mailing lists were not open participation? It varies. The TAG list is open. > Besides I'm pretty sure the overlap between calendar app people and TAG > people is nearly coincidental and not large. If TAG has surveyed > application developer interest groups like this one, I'd be interested > to hear that. I'm not sure what you're talking about... The initial question was whether it's more appropriate to define a new URI scheme (in addition to http), rather than using a new MIME type to dispatch from the browser. Are you saying that this is outside the scope of the W3C TAG? Or alternatively, do you think it would be wise if IETF and W3C recommend different approaches? Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ECC717F749; Thu, 18 May 2006 10:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC82F14229B; Thu, 18 May 2006 10:38:53 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09841-08; Thu, 18 May 2006 10:38:51 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 384FB142294; Thu, 18 May 2006 10:38:51 -0700 (PDT) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4IHcmjZ024770; Thu, 18 May 2006 10:38:48 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 89BAE4CB; Thu, 18 May 2006 10:38:48 -0700 (PDT) In-Reply-To: <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Going from browser to application Date: Thu, 18 May 2006 10:38:47 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.749.3) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 17:38:54 -0000 Got it, OK. I misunderstood you as meaning to solve the issue for existing resources. New new dispatching resource as the URI you link to may be useful, I agree. -wsv On May 17, 2006, at 5:20 PM, Lisa Dusseault wrote: > > Wilfredo, > > I don't quite make sense of your scenario as an application of the > davmount scheme. What I meant to convey, was that calendars might > also usefully be advertised in Web pages and other content that > contains links. That's where the HTML comes in. > > If I were to follow Julian's example for calendaring but start > from scratch (leaving aside the alternative of actually extending > davmount), here's what I might propose, combining workflow and > examples with mechanics: > > 1. An HTTP URL for a "calendar info file" would appear online on > my Web page (or in an email, or in a Web page listing several > peoples' calendars). > > E.g. My Calendar > > 2. The "calendar info file" would be a *new* resource beyond those > already described in CalDAV. It might be a sibling resource of a > CalDAV calendar collection (though it could live anywhere, even a > different server modulo security considerations). It would have a > MIME type something like application/caldav-calendar+xml (assuming > XML) so that the browser would be caused to dispatch the whole file > to an application registered as handling that MIME type. > > 3. Inside it would be at a minimum, the URL of the calendar that > was advertised -- because when this file is downloaded by a > browser, the browser sends the file to a calendar application that > doesn't know the URL where the file came from! We might also think > of additional helpful information that could go in that file, e.g. > even before the calendar application does an OPTIONS or a PROPFIND > on the href given, the calendar application might want to prompt > the user depending on the possibilities: > > "Opening: calendar for 'Lisa Dusseault'. Do you want to view, > subscribe or import?" > > thus the insides of the file might look like this (omitting > namespaces and other niceties, and inventing capabilities out of > thin air): > > Lisa Dusseault > > http://example.com/users/lisa/calendars/work/ href> > http://example.com/users/lisa/ > calendars/work.atom > http://example.com/users/lisa/calendars/ > work.ics > > > > Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 83F097F73E for ; Thu, 18 May 2006 09:49:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 74E7714229B for ; Thu, 18 May 2006 09:49:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23440-07; Thu, 18 May 2006 09:49:31 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0088A142294; Thu, 18 May 2006 09:49:30 -0700 (PDT) In-Reply-To: <446C011C.1030907@gmx.de> References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> <446C011C.1030907@gmx.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15026E1D-33E2-424C-86FA-1B8A1192729D@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application Date: Thu, 18 May 2006 09:49:26 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 16:49:31 -0000 On May 17, 2006, at 10:07 PM, Julian Reschke wrote: > > Well, that discussion is already on the W3C's TAG agenda, see > . So > it's probably best to move it over to the TAG mailing list. I'm > sure they'll be happy to get feedback :-) I thought TAG and other W3C mailing lists were not open participation? Besides I'm pretty sure the overlap between calendar app people and TAG people is nearly coincidental and not large. If TAG has surveyed application developer interest groups like this one, I'd be interested to hear that. Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DA1A97F73E for ; Wed, 17 May 2006 22:07:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CB01D14228D for ; Wed, 17 May 2006 22:07:46 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28461-06 for ; Wed, 17 May 2006 22:07:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id EA7BD142270 for ; Wed, 17 May 2006 22:07:45 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2006 05:07:44 -0000 Received: from p508FC2A6.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.194.166] by mail.gmx.net (mp012) with SMTP; 18 May 2006 07:07:44 +0200 X-Authenticated: #1915285 Message-ID: <446C011C.1030907@gmx.de> Date: Thu, 18 May 2006 07:07:40 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mike Shaver Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 05:07:47 -0000 Mike Shaver schrieb: > But how is this related to "a browser might be able to display this, > but the user may wish to have another application handle it instead"? > I'm a little lost, I fear. You're not sending back something that you > expect a browser to display (other than via the default-XML > presentation it might provide), as I understand your example. > > If the question is "should we have a descriptor format for > calendars?", then I think a MIME type makes a lot of sense for > indicating that that's what you're handing back, but that doesn't seem > like a strategic direction. (I have to say that I do sort of like > protocol schemes for some of these cases, because you're talking about > how to get a calendar resource -- "my free-busy for this month" -- and > not what the format of the resulting data is. If the http: scheme had > a standard way to encode method and request payload, that would be > even more nicely pure, but here we are.) Well, that discussion is already on the W3C's TAG agenda, see . So it's probably best to move it over to the TAG mailing list. I'm sure they'll be happy to get feedback :-) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 477967F732 for ; Wed, 17 May 2006 22:01:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 377F0142270 for ; Wed, 17 May 2006 22:01:10 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31458-10 for ; Wed, 17 May 2006 22:01:07 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 9B97B14228D for ; Wed, 17 May 2006 22:01:06 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2006 05:01:04 -0000 Received: from p508FC2A6.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.194.166] by mail.gmx.net (mp020) with SMTP; 18 May 2006 07:01:04 +0200 X-Authenticated: #1915285 Message-ID: <446BFF8C.6090208@gmx.de> Date: Thu, 18 May 2006 07:01:00 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> In-Reply-To: <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 05:01:10 -0000 Lisa Dusseault schrieb: > ... Hi Lisa, yes, that's a good summary of how a mechanism similar to davmount could be applied to opening the calender application from inside a Web browsing session. As you pointed out, the presence of the URI in the entity body is important, because with today's browsers, the base URL of the document being opened isn't communicated to "helper" applications. Note this is why Atom 1.0 can get away with passing the feed document to a feed reader application (it contains a "self" link), while the various RSS types can't (without extension). Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2D10B7F870 for ; Wed, 17 May 2006 18:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1EEFA142289 for ; Wed, 17 May 2006 18:33:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22361-10 for ; Wed, 17 May 2006 18:33:55 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77F61142285 for ; Wed, 17 May 2006 18:33:55 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id o67so468919pye for ; Wed, 17 May 2006 18:33:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h9nh8R9+PmcWNAPNlrA5cxWcz0b7B5NBlVZxxHLO3NtympiKuA2rA5NdpinutvFCVOoG/FvIi8C9ka8fVztdQ+m2Wv4st0Sqopg/6cQlMhnPl3DQK0Dzn1SgISC+4+1fFyrCtGeoY3T6wfd1cos5NvEeOq31Zpt7Yg8OD+sUkrQ= Received: by 10.35.60.15 with SMTP id n15mr187360pyk; Wed, 17 May 2006 18:33:54 -0700 (PDT) Received: by 10.35.106.4 with HTTP; Wed, 17 May 2006 18:33:54 -0700 (PDT) Message-ID: Date: Thu, 18 May 2006 03:33:54 +0200 From: "Mike Shaver" To: "Lisa Dusseault" Subject: Re: [Ietf-caldav] Going from browser to application In-Reply-To: <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 01:33:58 -0000 On 5/18/06, Lisa Dusseault wrote: > I don't quite make sense of your scenario as an application of the davmou= nt > scheme. What I meant to convey, was that calendars might also usefully = be > advertised in Web pages and other content that contains links. That's wh= ere > the HTML comes in. But how is this related to "a browser might be able to display this, but the user may wish to have another application handle it instead"? I'm a little lost, I fear. You're not sending back something that you expect a browser to display (other than via the default-XML presentation it might provide), as I understand your example. If the question is "should we have a descriptor format for calendars?", then I think a MIME type makes a lot of sense for indicating that that's what you're handing back, but that doesn't seem like a strategic direction. (I have to say that I do sort of like protocol schemes for some of these cases, because you're talking about how to get a calendar resource -- "my free-busy for this month" -- and not what the format of the resulting data is. If the http: scheme had a standard way to encode method and request payload, that would be even more nicely pure, but here we are.) Mike Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E910B7F511 for ; Wed, 17 May 2006 18:29:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA3B3142270 for ; Wed, 17 May 2006 18:29:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02181-03 for ; Wed, 17 May 2006 18:29:38 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by laweleka.osafoundation.org (Postfix) with SMTP id 121EB142285 for ; Wed, 17 May 2006 18:29:37 -0700 (PDT) Received: (qmail 45332 invoked from network); 18 May 2006 01:29:37 -0000 Received: from unknown (HELO ?192.168.1.4?) (kervin@adevsoft.com@72.156.251.193 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 18 May 2006 01:29:36 -0000 Message-ID: <446BCE08.3060502@adevsoft.com> Date: Wed, 17 May 2006 21:29:44 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> In-Reply-To: <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 01:29:43 -0000 Hello, Have we or should we rule out... caldav://example.com/users/lisa/calendars/ ? Which I guess was how this was handled in the past. Best regards, Kervin Lisa Dusseault wrote: > > Wilfredo, > > I don't quite make sense of your scenario as an application of the > davmount scheme. What I meant to convey, was that calendars might also > usefully be advertised in Web pages and other content that contains > links. That's where the HTML comes in. > > If I were to follow Julian's example for calendaring but start from > scratch (leaving aside the alternative of actually extending davmount), > here's what I might propose, combining workflow and examples with mechanics: > > 1. An* HTTP URL* for a "calendar info file" would appear online on my > Web page (or in an email, or in a Web page listing several peoples' > calendars). > > E.g. href="http://example.com/users/lisa/calendars/work-calendar-info.xml">My > Calendar > > 2. The "calendar info file" would be a *new* resource beyond those > already described in CalDAV. It might be a sibling resource of a CalDAV > calendar collection (though it could live anywhere, even a different > server modulo security considerations). It would have a MIME type > something like *application/caldav-calendar+xml* (assuming XML) so that > the browser would be caused to dispatch the whole file to an application > registered as handling that MIME type. > > 3. Inside it would be at a minimum, *the URL of the calendar that was > advertised *-- because when this file is downloaded by a browser, the > browser sends the file to a calendar application that doesn't know the > URL where the file came from! We might also think of additional helpful > information that could go in that file, e.g. even before the calendar > application does an OPTIONS or a PROPFIND on the href given, the > calendar application might want to prompt the user depending on the > possibilities: > > "Opening: calendar for 'Lisa Dusseault'. Do you want to view, > subscribe or import?" > > thus the insides of the file might look like this (omitting namespaces > and other niceties, and inventing capabilities out of thin air): > > Lisa Dusseault > > http://example.com/users/lisa/calendars/work/ > http://example.com/users/lisa/calendars/work.atom > http://example.com/users/lisa/calendars/work.ics > > > > Lisa > > On May 17, 2006, at 11:11 AM, Wilfredo Sánchez Vega wrote: > >> Julian- >> >> I'm leaning with Mike at the moment, but maybe I don't understand >> how the davmount scheme would help me here. Specifically, I don't >> know what the client/server exchange would look like given that we >> aren't starting at a hypertext document as in the section 4 example in >> the mount draft. In the calendar case, you start with iCalendar text, >> not HTML: >> >> 1- Client retrieves representation of CalDAV resource >> "/calendars/wsanchez/par-tay.ics": >> >> GET /user42/inbox/ HTTP/1.1 >> Host: www.example.com >> >> 2- Server returns representation. >> >> HTTP/1.1 200 OK >> Content-Type: text/iCalendar >> Content-Length: xxx >> >> >> BEGIN:VCALENDAR >> .. >> END:VCALENDAR >> >> 3- What happens here? >> >> There is no link for the use to click on here. In your example, the >> server sent back some HTML. The user is shows that document, and has >> to then click on a link to make the desired action happen. >> >> In our case, the browser got some iCalendar data, and there's really >> no good place for the server to shove in a link, nor would it really >> want to if it could. >> >> Now as an alternate example, the client might start with the >> calendar collection resource, rather than with one of the iCalendar >> resources contained in it. The server is free to send back any data >> it wants to on a GET response in that case, so it could send back >> HTML. But a server might want to instead send back monolithic >> iCalendar data for the entire calendar so that existing calendar >> clients (eg. Apple's iCal) can use that URL. >> >> So that leaves a server having to choose between supporting a legacy >> calendar client, or supporting a generic (HTML-centric) web browser. >> Or doing a bunch of user-agent matching, because iCal wasn't smart >> enough to send an Accept: header and web browsers don't send useful >> Accept: headers. >> >> Am I misunderstanding how the mount scheme would fit in here? >> >> -wsv >> >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BCBDB7F877 for ; Wed, 17 May 2006 17:20:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AD652142270 for ; Wed, 17 May 2006 17:20:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10807-08; Wed, 17 May 2006 17:20:27 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 419EB14226C; Wed, 17 May 2006 17:20:27 -0700 (PDT) In-Reply-To: References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-14--46784401 Message-Id: <80161E22-4563-4082-9552-F800C34D7A5F@osafoundation.org> From: Lisa Dusseault Subject: Re: [Ietf-caldav] Going from browser to application Date: Wed, 17 May 2006 17:20:23 -0700 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_MESSAGE, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 00:20:32 -0000 --Apple-Mail-14--46784401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Wilfredo, I don't quite make sense of your scenario as an application of the =20 davmount scheme. What I meant to convey, was that calendars might =20 also usefully be advertised in Web pages and other content that =20 contains links. That's where the HTML comes in. If I were to follow Julian's example for calendaring but start from =20= scratch (leaving aside the alternative of actually extending =20 davmount), here's what I might propose, combining workflow and =20 examples with mechanics: 1. An HTTP URL for a "calendar info file" would appear online on my =20 Web page (or in an email, or in a Web page listing several peoples' =20 calendars). E.g. My Calendar 2. The "calendar info file" would be a *new* resource beyond those =20 already described in CalDAV. It might be a sibling resource of a =20 CalDAV calendar collection (though it could live anywhere, even a =20 different server modulo security considerations). It would have a =20 MIME type something like application/caldav-calendar+xml (assuming =20 XML) so that the browser would be caused to dispatch the whole file =20 to an application registered as handling that MIME type. 3. Inside it would be at a minimum, the URL of the calendar that was =20= advertised -- because when this file is downloaded by a browser, the =20 browser sends the file to a calendar application that doesn't know =20 the URL where the file came from! We might also think of additional =20 helpful information that could go in that file, e.g. even before the =20 calendar application does an OPTIONS or a PROPFIND on the href given, =20= the calendar application might want to prompt the user depending on =20 the possibilities: "Opening: calendar for 'Lisa Dusseault'. Do you want to view, =20= subscribe or import?" thus the insides of the file might look like this (omitting =20 namespaces and other niceties, and inventing capabilities out of thin =20= air): Lisa Dusseault = http://example.com/users/lisa/calendars/work/ = http://example.com/users/lisa/calendars/=20 work.atom = http://example.com/users/lisa/calendars/=20 work.ics Lisa On May 17, 2006, at 11:11 AM, Wilfredo S=E1nchez Vega wrote: > Julian- > > I'm leaning with Mike at the moment, but maybe I don't understand =20= > how the davmount scheme would help me here. Specifically, I don't =20 > know what the client/server exchange would look like given that we =20 > aren't starting at a hypertext document as in the section 4 example =20= > in the mount draft. In the calendar case, you start with iCalendar =20= > text, not HTML: > > 1- Client retrieves representation of CalDAV resource "/calendars/=20 > wsanchez/par-tay.ics": > > GET /user42/inbox/ HTTP/1.1 > Host: www.example.com > > 2- Server returns representation. > > HTTP/1.1 200 OK > Content-Type: text/iCalendar > Content-Length: xxx > =09 > BEGIN:VCALENDAR > .. > END:VCALENDAR > > 3- What happens here? > > There is no link for the use to click on here. In your example, =20 > the server sent back some HTML. The user is shows that document, =20 > and has to then click on a link to make the desired action happen. > > In our case, the browser got some iCalendar data, and there's =20 > really no good place for the server to shove in a link, nor would =20 > it really want to if it could. > > Now as an alternate example, the client might start with the =20 > calendar collection resource, rather than with one of the iCalendar =20= > resources contained in it. The server is free to send back any =20 > data it wants to on a GET response in that case, so it could send =20 > back HTML. But a server might want to instead send back monolithic =20= > iCalendar data for the entire calendar so that existing calendar =20 > clients (eg. Apple's iCal) can use that URL. > > So that leaves a server having to choose between supporting a =20 > legacy calendar client, or supporting a generic (HTML-centric) web =20 > browser. Or doing a bunch of user-agent matching, because iCal =20 > wasn't smart enough to send an Accept: header and web browsers =20 > don't send useful Accept: headers. > > Am I misunderstanding how the mount scheme would fit in here? > > -wsv > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav --Apple-Mail-14--46784401 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Wilfredo,

I don't quite make sense of = your scenario as an application of the davmount scheme.=A0 =A0What I = meant to convey, was that calendars might also usefully be advertised in = Web pages and other content that contains links.=A0 That's where the = HTML comes in.

=A0If I were to follow = Julian's example for calendaring but start from scratch (leaving aside = the alternative of actually extending davmount), here's what I might = propose, combining workflow and examples with mechanics:

1.=A0An HTTP=A0 URL for a "calendar = info file" would appear online on my Web page (or in an email, or in a = Web page listing several peoples' calendars).=A0=A0


2.=A0The "calendar info file" would be a = *new* resource beyond those already described in CalDAV.=A0 It might be = a sibling resource of a CalDAV calendar collection (though it could live = anywhere, even a different server modulo security considerations).=A0=A0It= would have a MIME type something like = application/caldav-calendar+xml (assuming XML) so that the = browser would be caused to dispatch the whole file to an application = registered as handling that MIME type.

3.=A0 Inside it would be at a minimum, the = URL of the calendar that was advertised -- because when this file is = downloaded by a browser, the browser sends the file to a calendar = application that doesn't know the URL where the file came from!=A0=A0We = might also think of additional helpful information that could go in that = file, e.g. even before the calendar application does an OPTIONS or a = PROPFIND on the href given, the calendar application might want to = prompt the user depending on the possibilities:=A0

= =A0"Opening: calendar for 'Lisa Dusseault'.=A0 Do you want to = view, subscribe or import?"

thus the insides of the = file might look like this (omitting namespaces and other niceties, and = inventing capabilities out of thin air):
= <calendar-info>
<for>Lisa = Dusseault</for>
= <capabilities>
= <caldav><href>http://example.com/= users/lisa/calendars/work/</href></caldav>
= <atom-calendar-feed><href>http://example.= com/users/lisa/calendars/work.atom</href></atom-calendar-feed= >
= <full-icalendar><href>http://example.c= om/users/lisa/calendars/work.ics</href></full-icalendar>
= </capabilities>
=A0 = </calendar-info>
=A0
Lisa

<= DIV>On May 17, 2006, at 11:11 AM, Wilfredo S=E1nchez Vega = wrote:

Julian-

=A0 I'm leaning with Mike at the = moment, but maybe I don't understand how the davmount scheme would help = me here.=A0 Specifically, I = don't know what the client/server exchange would look like given that we = aren't starting at a hypertext document as in the section 4 example in = the mount draft.=A0 In the = calendar case, you start with iCalendar text, not HTML:

=A01- Client retrieves = representation of CalDAV resource = "/calendars/wsanchez/par-tay.ics":

GET /user42/inbox/ = HTTP/1.1

=A02- Server returns = representation.

HTTP/1.1 200 OK
Content-Type: = text/iCalendar
Content-Length: xxx


= BEGIN:VCALENDAR
= ..
END:VCALENDAR

=A03- What happens = here?

=A0 = There is no link for the use to click on here.=A0 In your example, the server = sent back some HTML.=A0 The = user is shows that document, and has to then click on a link to make the = desired action happen.
=A0 In our case, the browser got = some iCalendar data, and there's really no good place for the server to = shove in a link, nor would it really want to if it could.

=A0 Now as an alternate example, = the client might start with the calendar collection resource, rather = than with one of the iCalendar resources contained in it.=A0 The server is free to send = back any data it wants to on a GET response in that case, so it could = send back HTML.=A0 But a = server might want to instead send back monolithic iCalendar data for the = entire calendar so that existing calendar clients (eg. Apple's iCal) can = use that URL.

=A0 So = that leaves a server having to choose between supporting a legacy = calendar client, or supporting a generic (HTML-centric) web = browser.=A0 Or doing a = bunch of user-agent matching, because iCal wasn't smart enough to send = an Accept: header and web browsers don't send useful Accept: = headers.

=A0 Am = I misunderstanding how the mount scheme would fit in here?

= -wsv

Ietf-caldav mailing list -- Ietf-caldav@osafoundation.or= g
See http://ietf.webdav.org/caldav/= for more CalDAV resources
=

= --Apple-Mail-14--46784401-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 840147F7FC for ; Wed, 17 May 2006 11:11:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 75CCA142285 for ; Wed, 17 May 2006 11:11:30 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13475-03 for ; Wed, 17 May 2006 11:11:27 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CBD5B142288 for ; Wed, 17 May 2006 11:11:27 -0700 (PDT) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k4HIBM9s009475; Wed, 17 May 2006 11:11:22 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id A65A441; Wed, 17 May 2006 11:11:22 -0700 (PDT) In-Reply-To: <446B2874.8030405@gmx.de> References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> <446B2874.8030405@gmx.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Going from browser to application Date: Wed, 17 May 2006 11:11:21 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.749.3) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2006 18:11:30 -0000 Julian- I'm leaning with Mike at the moment, but maybe I don't understand how the davmount scheme would help me here. Specifically, I don't know what the client/server exchange would look like given that we aren't starting at a hypertext document as in the section 4 example in the mount draft. In the calendar case, you start with iCalendar text, not HTML: 1- Client retrieves representation of CalDAV resource "/calendars/ wsanchez/par-tay.ics": GET /user42/inbox/ HTTP/1.1 Host: www.example.com 2- Server returns representation. HTTP/1.1 200 OK Content-Type: text/iCalendar Content-Length: xxx BEGIN:VCALENDAR .. END:VCALENDAR 3- What happens here? There is no link for the use to click on here. In your example, the server sent back some HTML. The user is shows that document, and has to then click on a link to make the desired action happen. In our case, the browser got some iCalendar data, and there's really no good place for the server to shove in a link, nor would it really want to if it could. Now as an alternate example, the client might start with the calendar collection resource, rather than with one of the iCalendar resources contained in it. The server is free to send back any data it wants to on a GET response in that case, so it could send back HTML. But a server might want to instead send back monolithic iCalendar data for the entire calendar so that existing calendar clients (eg. Apple's iCal) can use that URL. So that leaves a server having to choose between supporting a legacy calendar client, or supporting a generic (HTML-centric) web browser. Or doing a bunch of user-agent matching, because iCal wasn't smart enough to send an Accept: header and web browsers don't send useful Accept: headers. Am I misunderstanding how the mount scheme would fit in here? -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DBF627F824 for ; Wed, 17 May 2006 06:43:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CDA39142288 for ; Wed, 17 May 2006 06:43:22 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29723-06 for ; Wed, 17 May 2006 06:43:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id BF0BB142285 for ; Wed, 17 May 2006 06:43:20 -0700 (PDT) Received: (qmail invoked by alias); 17 May 2006 13:43:19 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 17 May 2006 15:43:19 +0200 X-Authenticated: #1915285 Message-ID: <446B2874.8030405@gmx.de> Date: Wed, 17 May 2006 15:43:16 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mike Shaver Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2006 13:43:23 -0000 Mike Shaver schrieb: > On 5/17/06, Julian Reschke wrote: >> Mike Shaver schrieb: >> > >> > Content-disposition: attachment? >> > >> > I'm not exactly sure why a browser can't be the thing that handles it >> > correctly, but C-d:a is how servers are supposed to indicate "probably >> > want the user to pick where this goes", by my recollection. >> >> Yep, but I'm not sure how this helps here. Sending that header will >> cause user agents to display a download dialog. What we're looking for >> is something that triggers automatic invocation of a non-browser >> application for a specific URL. > > It will cause user agents to display a "how do I handle this?" dialog, > which includes selection of a helper app in most (all?) browsers that > support C-d:a. And if you want another app to handle some content, we > call that a helper app. :) But to make this work, the content would need to contain the information that that helper application needs to do it's work. That is, minimally the URL (*). In general, HTML content won't contain that, in even if it would (extension, or something like a base attribute), the helper app would then need to parse the HTML, right? Somehow it seems more straightforward to me to dump all information that is needed into a specific XML format, and let the helper app extract all the information it needs. BTW: this will make the information bookmarkable, and it also allows storing the information in a local file, and to active it without any browser interaction (so you can store something like "Mount my documents on portal.davmount" and just double-click it to active it). (*) Note that this is one of the reasons why the "feed" scheme people have been talking about wouldn't be needed with Atom, as each feed contains a "self" link. >> > I don't like MIME type for this, since as you say it's the same data >> > (in the same format), which seems to me to have the same undesirable >> > characteristics as using a different scheme for data that comes over >> > HTTP. >> >> Depends on how you use the MIME type. The one I defined in >> is >> used to transport information about how to "mount" an HTTP URL in the >> system's WebDAV client. That information includes a base URL (mount >> target), a child collection to be displayed (which may be below the >> mount target), plus additional information (such as account). > > That doesn't sound like the use case that Lisa was describing: Well, it's the use case I had to solve, and which I documented in that Internet Draft (which in turn triggered Lisa's mail). >> > On 5/16/06, Lisa Dusseault wrote: >> >> When the same data can be viewed either as a Web page or as data to >> >> be consumed by an application, there's a general issue over how to >> >> get the user from one to the other. Typically it's how you get the >> >> user from browser to specialized application. > > You're not talking about the same data being viewed as a web page, > you're talking about sending a different kind of data, it seems. Like > sending a playlist rather than an audio file, perhaps. > > (If a browser has WebDAV manipulation capability, which doesn't seem > entirely implausible to me, we're back in the same situation. > Content-disposition-style hints would be more appropriate here, > because you really are talking about how the content should be > dispatched, not what the structure or format or "type" of the content > that you're sending. Hm. If the use case I mentioned above can be implemented using Content-Disposition in a way that it works in all current browsers, I'm interested. As far as I can tell, I'll still need a MIME type to dispatch to a specific helper application, though (in which case I'm not sure what the benefit is over the solution I already have). Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 93C137F85D for ; Wed, 17 May 2006 06:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8235414226B for ; Wed, 17 May 2006 06:08:46 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23606-06 for ; Wed, 17 May 2006 06:08:42 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id 332C314226E for ; Wed, 17 May 2006 06:08:42 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so256052pyu for ; Wed, 17 May 2006 06:08:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XgNR8wlGm/GXN4WNkEKwD3ABQ518Obzsu3wylBOx5cbTfzuCYBNrmHxcBNPHFMPNUIbJhtkockxkifcYFMoSQ+ZGDUmOwo3Z1QF2qSoCaWhmAEbgdvNFsvA5IkFJxbtV0AySKo5/is75xytlCmqO/NrKpq9RMXzovVZ0yWO5EvQ= Received: by 10.35.15.11 with SMTP id s11mr1030241pyi; Wed, 17 May 2006 06:08:41 -0700 (PDT) Received: by 10.35.106.4 with HTTP; Wed, 17 May 2006 06:08:41 -0700 (PDT) Message-ID: Date: Wed, 17 May 2006 15:08:41 +0200 From: "Mike Shaver" To: "Julian Reschke" Subject: Re: [Ietf-caldav] Going from browser to application In-Reply-To: <446B147B.50306@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <446B147B.50306@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2006 13:08:46 -0000 On 5/17/06, Julian Reschke wrote: > Mike Shaver schrieb: > > > > Content-disposition: attachment? > > > > I'm not exactly sure why a browser can't be the thing that handles it > > correctly, but C-d:a is how servers are supposed to indicate "probably > > want the user to pick where this goes", by my recollection. > > Yep, but I'm not sure how this helps here. Sending that header will > cause user agents to display a download dialog. What we're looking for > is something that triggers automatic invocation of a non-browser > application for a specific URL. It will cause user agents to display a "how do I handle this?" dialog, which includes selection of a helper app in most (all?) browsers that support C-d:a. And if you want another app to handle some content, we call that a helper app. :) > > I don't like MIME type for this, since as you say it's the same data > > (in the same format), which seems to me to have the same undesirable > > characteristics as using a different scheme for data that comes over > > HTTP. > > Depends on how you use the MIME type. The one I defined in > is > used to transport information about how to "mount" an HTTP URL in the > system's WebDAV client. That information includes a base URL (mount > target), a child collection to be displayed (which may be below the > mount target), plus additional information (such as account). That doesn't sound like the use case that Lisa was describing: > > On 5/16/06, Lisa Dusseault wrote: > >> When the same data can be viewed either as a Web page or as data to > >> be consumed by an application, there's a general issue over how to > >> get the user from one to the other. Typically it's how you get the > >> user from browser to specialized application. You're not talking about the same data being viewed as a web page, you're talking about sending a different kind of data, it seems. Like sending a playlist rather than an audio file, perhaps. (If a browser has WebDAV manipulation capability, which doesn't seem entirely implausible to me, we're back in the same situation. Content-disposition-style hints would be more appropriate here, because you really are talking about how the content should be dispatched, not what the structure or format or "type" of the content that you're sending. Mike Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B8F3C7F82D for ; Wed, 17 May 2006 05:18:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9E1514227E for ; Wed, 17 May 2006 05:18:08 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32311-02 for ; Wed, 17 May 2006 05:18:07 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 52745142271 for ; Wed, 17 May 2006 05:18:07 -0700 (PDT) Received: (qmail invoked by alias); 17 May 2006 12:18:06 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 17 May 2006 14:18:06 +0200 X-Authenticated: #1915285 Message-ID: <446B147B.50306@gmx.de> Date: Wed, 17 May 2006 14:18:03 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mike Shaver Subject: Re: [Ietf-caldav] Going from browser to application References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2006 12:18:08 -0000 Mike Shaver schrieb: > On 5/16/06, Lisa Dusseault wrote: >> When the same data can be viewed either as a Web page or as data to >> be consumed by an application, there's a general issue over how to >> get the user from one to the other. Typically it's how you get the >> user from browser to specialized application. > > Content-disposition: attachment? > > I'm not exactly sure why a browser can't be the thing that handles it > correctly, but C-d:a is how servers are supposed to indicate "probably > want the user to pick where this goes", by my recollection. Yep, but I'm not sure how this helps here. Sending that header will cause user agents to display a download dialog. What we're looking for is something that triggers automatic invocation of a non-browser application for a specific URL. > I don't like MIME type for this, since as you say it's the same data > (in the same format), which seems to me to have the same undesirable > characteristics as using a different scheme for data that comes over > HTTP. Depends on how you use the MIME type. The one I defined in is used to transport information about how to "mount" an HTTP URL in the system's WebDAV client. That information includes a base URL (mount target), a child collection to be displayed (which may be below the mount target), plus additional information (such as account). Note sure how you would do that using response headers... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D116C7F85D for ; Tue, 16 May 2006 22:53:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C1B4814227E for ; Tue, 16 May 2006 22:53:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17409-03 for ; Tue, 16 May 2006 22:53:47 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C033142272 for ; Tue, 16 May 2006 22:53:47 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so170725pyu for ; Tue, 16 May 2006 22:53:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sFVuIN1NoVQSN9Ba1/sE5egx/KCgj63oE6KgV8VE3lGjA+qG0XMSoiuLFD/XYFvI9kBab6aREBVlsB/29s/RFgfKmTqf1+eb6yCIOoaTUNTIlVkAIkXkaK1RezaAGt3eAypA34UwS4/vOHcm00E/VlBm1XCdeza1kzo8OZOckkw= Received: by 10.35.99.5 with SMTP id b5mr658330pym; Tue, 16 May 2006 22:53:46 -0700 (PDT) Received: by 10.35.106.4 with HTTP; Tue, 16 May 2006 22:53:46 -0700 (PDT) Message-ID: Date: Wed, 17 May 2006 07:53:46 +0200 From: "Mike Shaver" To: "Lisa Dusseault" Subject: Re: [Ietf-caldav] Going from browser to application In-Reply-To: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2006 05:53:48 -0000 On 5/16/06, Lisa Dusseault wrote: > When the same data can be viewed either as a Web page or as data to > be consumed by an application, there's a general issue over how to > get the user from one to the other. Typically it's how you get the > user from browser to specialized application. Content-disposition: attachment? I'm not exactly sure why a browser can't be the thing that handles it correctly, but C-d:a is how servers are supposed to indicate "probably want the user to pick where this goes", by my recollection. I don't like MIME type for this, since as you say it's the same data (in the same format), which seems to me to have the same undesirable characteristics as using a different scheme for data that comes over HTTP. Mike Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BE7CF7F7E2 for ; Tue, 16 May 2006 13:47:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B002614228D for ; Tue, 16 May 2006 13:47:00 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06080-08; Tue, 16 May 2006 13:47:00 -0700 (PDT) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 30A5E14227E; Tue, 16 May 2006 13:47:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 16 May 2006 13:46:49 -0700 To: CalDAV DevList X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-5.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] Going from browser to application X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2006 20:47:00 -0000 When the same data can be viewed either as a Web page or as data to be consumed by an application, there's a general issue over how to get the user from one to the other. Typically it's how you get the user from browser to specialized application. Julian Reschke addresses this problem for WebDAV in this document It uses a new MIME type to prompt the browser to launch an appropriate application. Contrast that with the approach used in Apple's iCal, where they created a new scheme for data that's actually available via HTTP. I thought I'd post about this here in case there are reviews of Julian's document or thoughts on applicability for calendars. Lisa