From ietf-calsify-bounces@osafoundation.org Mon Aug 4 23:21:22 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DA03A6C12 for ; Mon, 4 Aug 2008 23:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62aNn4kvM7Wg for ; Mon, 4 Aug 2008 23:21:21 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 9E5F93A6C3B for ; Mon, 4 Aug 2008 23:21:06 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 496427F526; Mon, 4 Aug 2008 23:21:33 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 18FCB7F522 for ; Mon, 4 Aug 2008 23:21:32 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 606AF142206 for ; Mon, 4 Aug 2008 23:21:31 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 DayMhteUzKZq for ; Mon, 4 Aug 2008 23:21:20 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 61E211421FF for ; Mon, 4 Aug 2008 23:21:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m756Kv1E021749 for ; Tue, 5 Aug 2008 09:21:17 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 09:20:59 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 09:20:56 +0300 Received: from [172.21.41.245] (esdhcp041245.research.nokia.com [172.21.41.245]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m756KsH5028437 for ; Tue, 5 Aug 2008 09:20:54 +0300 From: Aki Niemi To: "ietf-calsify@osafoundation.org" Content-Type: text/plain Organization: Nokia Devices R&D Date: Tue, 05 Aug 2008 09:20:52 +0300 Message-Id: <1217917252.7851.2.camel@little.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2008 06:20:56.0158 (UTC) FILETIME=[6B6F6FE0:01C8F6C3] X-Nokia-AV: Clean Subject: [Ietf-calsify] FYI: Nomcom 2008-9 Call for Volunteers X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org If you are qualified (have attended 3 out of past 5 meetings), please consider volunteering for the Nomcom: https://datatracker.ietf.org/ann/nomcom/1617/ Cheers, Aki -- Aki Niemi Maemo Software, Nokia Devices R&D _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Aug 21 16:30:14 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9FD3A699A for ; Thu, 21 Aug 2008 16:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHRTfOtvZFgU for ; Thu, 21 Aug 2008 16:30:12 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id CA2D43A67BD for ; Thu, 21 Aug 2008 16:30:09 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 0F4D280DBD; Thu, 21 Aug 2008 16:29:24 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 39C0780DBA for ; Thu, 21 Aug 2008 16:29:23 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 35826142247 for ; Thu, 21 Aug 2008 16:29:22 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 0iPx-OB1JDhS for ; Thu, 21 Aug 2008 16:29:16 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 06862142224 for ; Thu, 21 Aug 2008 16:29:16 -0700 (PDT) Message-Id: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> From: Lisa Dusseault To: ietf-calsify list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 21 Aug 2008 16:29:16 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] ADD is really optional --? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org I'm doing AD Review of iTIP and the way I read specs like this by default is that if there are a bunch of methods that can be sent around between agents, all of them must be supported. However, for the ADD method, iTIP specifies a way for a receiving client not to really support it -- return a REQUEST-STATUS of 3.14 followed by a REFRESH request. Is ADD routinely supported by iTIP implementations or is this exception used in practice? Lisa _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 01:12:48 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8022A3A692A for ; Fri, 22 Aug 2008 01:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.914 X-Spam-Level: X-Spam-Status: No, score=-7.914 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKq7m8b5V4Az for ; Fri, 22 Aug 2008 01:12:47 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 9C2D13A67D4 for ; Fri, 22 Aug 2008 01:12:47 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 8D86080D2E; Fri, 22 Aug 2008 01:12:10 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E7D380D2E for ; Fri, 22 Aug 2008 01:12:08 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2768514222B for ; Fri, 22 Aug 2008 01:12:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 TB6RaI7bpcQO for ; Fri, 22 Aug 2008 01:11:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id DFC961421FB for ; Fri, 22 Aug 2008 01:11:54 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 08:11:53 -0000 Received: from p508FFFBC.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.255.188] by mail.gmx.net (mp065) with SMTP; 22 Aug 2008 10:11:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Fcjtl/FVFrtr+YUccP4VPX0ivStdcFbkBiNdThT F6QfDIQ4DVIW6X Message-ID: <48AE74C0.3090809@gmx.de> Date: Fri, 22 Aug 2008 10:11:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi, I've got a quick question about the iCalendar format, or actually an idea. If I serve an iCalendar resource through HTTP, what I really want is to allow the client not only to read it (display it in a calendar application), but also to *subscribe* to it, for which I obviously need the URI. Apple, years ago, "solved" this (and potentially some other use cases) with their custom "webcal" URI scheme. (I note that this URI scheme hasn't been registered with IANA.) The Atom WG was smarter, by allowing the format to carry a "self" URI, for subscription (see ). Bernard already pointed me to the URL property (), but what I'm looking for is a Calendar property, not a Component property (I think). Is something like that possible in iCalendar? If not, could/should it be added? (Separate document?) BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 01:26:14 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52ACB3A67EE for ; Fri, 22 Aug 2008 01:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.094 X-Spam-Level: X-Spam-Status: No, score=-4.094 tagged_above=-999 required=5 tests=[AWL=2.506, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucRgUwLTfZho for ; Fri, 22 Aug 2008 01:26:13 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 4A4693A677E for ; Fri, 22 Aug 2008 01:26:13 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id CD94180D96; Fri, 22 Aug 2008 01:25:31 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 68B7580D95 for ; Fri, 22 Aug 2008 01:25:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 649FD14222B for ; Fri, 22 Aug 2008 01:25:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 S3M3QSYFRvp3 for ; Fri, 22 Aug 2008 01:25:17 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 63A091421FB for ; Fri, 22 Aug 2008 01:25:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BE7D010F0985 for ; Fri, 22 Aug 2008 10:25:18 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id 0150910F0622 for ; Fri, 22 Aug 2008 10:24:47 +0200 (CEST) Message-Id: <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AE74C0.3090809@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 10:24:43 +0200 References: <48AE74C0.3090809@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Julian, I'm not sure what you mean by 'subscribe' in the context. Do you want some kind of feed which is based on the iCal format? That is, subsequent GETs on that feed URL only return changed items? Subscribe in the iCal-over-HTTP context is just using that URL, cache it and do proper if-none-match: etag requests to keep it up to date. Thats no different to the subscription of regular RSS feeds. I don't think that adding such URLs to the content format is good. It blurs the boundaries between protocol (HTTP) and the payload (iCal). Greets, Helge PS: I never understood why Apple needed the 'webcal' URI scheme. I guess it was just a quick hack. It was probably easier to activate an OSX application by URL than by the content-type of the URL entity. On 22.08.2008, at 10:11, Julian Reschke wrote: > I've got a quick question about the iCalendar format, or actually an > idea. > > If I serve an iCalendar resource through HTTP, what I really want is > to allow the client not only to read it (display it in a calendar > application), but also to *subscribe* to it, for which I obviously > need the URI. > > Apple, years ago, "solved" this (and potentially some other use > cases) with their custom "webcal" URI scheme. (I note that this URI > scheme hasn't been registered with IANA.) > > The Atom WG was smarter, by allowing the format to carry a "self" > URI, for subscription (see >). > > Bernard already pointed me to the URL property ( >), but what I'm looking for is a Calendar property, not a Component > property (I think). > > Is something like that possible in iCalendar? If not, could/should > it be added? (Separate document?) -- Helge Hess http://helgehess.eu/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 01:47:42 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7064E3A699C for ; Fri, 22 Aug 2008 01:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.892 X-Spam-Level: X-Spam-Status: No, score=-7.892 tagged_above=-999 required=5 tests=[AWL=-1.293, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6vmivOh2DVS for ; Fri, 22 Aug 2008 01:47:41 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 647C63A688B for ; Fri, 22 Aug 2008 01:47:41 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 7B28480DBE; Fri, 22 Aug 2008 01:47:11 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2BCF880D79 for ; Fri, 22 Aug 2008 01:47:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2801414222B for ; Fri, 22 Aug 2008 01:47:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 1eupIICSZvcm for ; Fri, 22 Aug 2008 01:46:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id E28971421FB for ; Fri, 22 Aug 2008 01:46:55 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 08:46:55 -0000 Received: from p508FFFBC.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.255.188] by mail.gmx.net (mp045) with SMTP; 22 Aug 2008 10:46:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+w8rcJKsywtrQZZWt4BMDYOF6x+Ws1l9nJDz3TWl MC1E14ZZBAaOg8 Message-ID: <48AE7CF4.1070109@gmx.de> Date: Fri, 22 Aug 2008 10:46:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> In-Reply-To: <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Helge Hess wrote: > Julian, > > I'm not sure what you mean by 'subscribe' in the context. Do you want > some kind of feed which is based on the iCal format? That is, subsequent > GETs on that feed URL only return changed items? No, not a feed. Just the current state of the calendar. Exactly what you get when you subscribe (for instance) to a Google Calendar in Thunderbird, using "http" (not caldav). > Subscribe in the iCal-over-HTTP context is just using that URL, cache it > and do proper if-none-match: etag requests to keep it up to date. Thats > no different to the subscription of regular RSS feeds. > > I don't think that adding such URLs to the content format is good. It > blurs the boundaries between protocol (HTTP) and the payload (iCal). But it's the only way of opening the calendar in an application other than the browser *and* giving that application the original URL (at least in the operating systems I'm aware of). > Greets, > Helge > > PS: I never understood why Apple needed the 'webcal' URI scheme. I guess > it was just a quick hack. It was probably easier to activate an OSX > application by URL than by the content-type of the URL entity. It addresses exactly this problem. If the iCalendar object doesn't contain the URL it came from, the calendar application lacks that essential piece of information. BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 05:07:31 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D273A682C for ; Fri, 22 Aug 2008 05:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sf74aweymYI for ; Fri, 22 Aug 2008 05:07:26 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 442293A6823 for ; Fri, 22 Aug 2008 05:07:26 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id BA11A80DC2; Fri, 22 Aug 2008 05:06:50 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0556880D3F for ; Fri, 22 Aug 2008 05:06:49 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F3FFC142233 for ; Fri, 22 Aug 2008 05:06:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 Rpa0z8r5hwF3 for ; Fri, 22 Aug 2008 05:06:36 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by laweleka.osafoundation.org (Postfix) with ESMTP id 26E5A14222A for ; Fri, 22 Aug 2008 05:06:35 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 5PA61a00916AWCUA9Q6cXV; Fri, 22 Aug 2008 12:06:36 +0000 Received: from THare ([71.203.105.66]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 5Q6V1a00F1RyUCv8SQ6bBW; Fri, 22 Aug 2008 12:06:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=4lsWnCqjEnIA:10 a=7FhwB9M-7j8A:10 a=PFsjAnyDAAAA:8 a=VkrFwHKdAb8ac-Q_ckYA:9 a=SJqFrJ2rlxo3mFn7wC4A:7 a=xuLO5RUyktVzUXU5vGjL8u3HzaUA:4 a=nMy-LcBKloIA:10 a=YewFc9KQ5U8A:10 a=f3vTY2RCmVgA:10 From: "Tim Hare" To: "'Julian Reschke'" , "'Helge Hess'" Subject: RE: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) Date: Fri, 22 Aug 2008 08:06:31 -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: <48AE7CF4.1070109@gmx.de> Thread-Index: AckEM6vccdqhrG2fR4GKWLRABci2BQAGywAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Message-Id: <20080822120636.26E5A14222A@laweleka.osafoundation.org> Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org If you want a subscription experience, you could embed the URL of the .ics file in an Atom feed, couldn't you, and take advantage of the "self" property for the feed? As an aside, there's a TC-XML at Calconnect.org which is discussing XML representation of iCalendar; this sort of thing might be of interest to them. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Julian Reschke Sent: Friday, August 22, 2008 4:47 AM To: Helge Hess Cc: IETF-iCalendar Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) Helge Hess wrote: > Julian, > > I'm not sure what you mean by 'subscribe' in the context. Do you want > some kind of feed which is based on the iCal format? That is, > subsequent GETs on that feed URL only return changed items? No, not a feed. Just the current state of the calendar. Exactly what you get when you subscribe (for instance) to a Google Calendar in Thunderbird, using "http" (not caldav). > Subscribe in the iCal-over-HTTP context is just using that URL, cache > it and do proper if-none-match: etag requests to keep it up to date. > Thats no different to the subscription of regular RSS feeds. > > I don't think that adding such URLs to the content format is good. It > blurs the boundaries between protocol (HTTP) and the payload (iCal). But it's the only way of opening the calendar in an application other than the browser *and* giving that application the original URL (at least in the operating systems I'm aware of). > Greets, > Helge > > PS: I never understood why Apple needed the 'webcal' URI scheme. I > guess it was just a quick hack. It was probably easier to activate an > OSX application by URL than by the content-type of the URL entity. It addresses exactly this problem. If the iCalendar object doesn't contain the URL it came from, the calendar application lacks that essential piece of information. BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 05:22:31 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57363A682D for ; Fri, 22 Aug 2008 05:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.37 X-Spam-Level: X-Spam-Status: No, score=-8.37 tagged_above=-999 required=5 tests=[AWL=-1.771, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOqOlYL7aBHn for ; Fri, 22 Aug 2008 05:22:30 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id A893C3A6905 for ; Fri, 22 Aug 2008 05:22:30 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 2247580DAC; Fri, 22 Aug 2008 05:22:16 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 59E0580D8E for ; Fri, 22 Aug 2008 05:22:14 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5461E14222C for ; Fri, 22 Aug 2008 05:22:13 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 EBCEWoAeJ8rM for ; Fri, 22 Aug 2008 05:22:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 434A214222A for ; Fri, 22 Aug 2008 05:22:05 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 12:22:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp052) with SMTP; 22 Aug 2008 14:22:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+TDyhy8DuTe4k3X+irCw4A6UusOmZKAV+QDryIA5 mUiUeLbVugKOzy Message-ID: <48AEAF62.9070806@gmx.de> Date: Fri, 22 Aug 2008 14:21:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) References: <20080822120638.27477gmx1@mx007.gmx.net> In-Reply-To: <20080822120638.27477gmx1@mx007.gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Tim Hare wrote: > If you want a subscription experience, you could embed the URL of the .ics > file in an Atom feed, couldn't you, and take advantage of the "self" > property for the feed? Not sure how that would help - I want to subscribe to the calendar, not a feed, after all. > ... BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 09:31:44 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44903A67E2 for ; Fri, 22 Aug 2008 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.72 X-Spam-Level: X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=1.879, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5mhpH3ododV for ; Fri, 22 Aug 2008 09:31:43 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 49B3B3A67CC for ; Fri, 22 Aug 2008 09:31:43 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 145A27F4F2; Fri, 22 Aug 2008 09:31:03 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 633AC7F4DD for ; Fri, 22 Aug 2008 09:31:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C77B1421FC for ; Fri, 22 Aug 2008 09:31:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 ibxJk+M2zsDr for ; Fri, 22 Aug 2008 09:30:50 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1772F14222B for ; Fri, 22 Aug 2008 09:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4D71010F2CA9 for ; Fri, 22 Aug 2008 18:30:46 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id B05C610F2CD2 for ; Fri, 22 Aug 2008 18:27:52 +0200 (CEST) Message-Id: <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AE7CF4.1070109@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 18:27:47 +0200 References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org On 22.08.2008, at 10:46, Julian Reschke wrote: > No, not a feed. Just the current state of the calendar. Exactly what > you get when you subscribe (for instance) to a Google Calendar in > Thunderbird, using "http" (not caldav). OK. >> > But it's the only way of opening the calendar in an application > other than the browser *and* giving that application the original > URL (at least in the operating systems I'm aware of). I still don't get it. Can't you configure the browser to open your calendaring application for the text/calendar content type? The browser can invoke the application with the URL? (I'm pretty sure that Mozilla allows that, and IE definitely does open by URL when you invoke a Word document for example, so it should also work there, somehow) > It addresses exactly this problem. If the iCalendar object doesn't > contain the URL it came from, the calendar application lacks that > essential piece of information. Yes, but in what case would you download a calendar via URL and then use the same URL again to re-download the same entity. That just doesn't make a lot sense? :-) Its really just a hack around an improper configuration of the URL/app activation system. Well, maybe the hack is worth it. But in this case I would prefer a webcal:// scheme over an iCal embedded URL, to preserve the layering between content and transport. Thanks, Helge -- Helge Hess http://helgehess.eu/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 09:52:46 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B9D3A694F for ; Fri, 22 Aug 2008 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.755 X-Spam-Level: X-Spam-Status: No, score=-7.755 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5lHbeaabZBa for ; Fri, 22 Aug 2008 09:52:45 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 9BD1E3A67A5 for ; Fri, 22 Aug 2008 09:52:45 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 90B8880C3A; Fri, 22 Aug 2008 09:51:56 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A987B80B48 for ; Fri, 22 Aug 2008 09:51:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A41F1142234 for ; Fri, 22 Aug 2008 09:51:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 TBo7+m0TZ2Xu for ; Fri, 22 Aug 2008 09:51:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 43D31142233 for ; Fri, 22 Aug 2008 09:51:47 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 16:51:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 22 Aug 2008 18:51:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Lt9YnadgLB3ZdSRSHQMqYKWxE1hnFW6stLwCLpP z3bhG8qrRpotD0 Message-ID: <48AEEE97.205@gmx.de> Date: Fri, 22 Aug 2008 18:51:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> In-Reply-To: <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Helge Hess wrote: > On 22.08.2008, at 10:46, Julian Reschke wrote: >> No, not a feed. Just the current state of the calendar. Exactly what >> you get when you subscribe (for instance) to a Google Calendar in >> Thunderbird, using "http" (not caldav). > > OK. > >>> >> But it's the only way of opening the calendar in an application other >> than the browser *and* giving that application the original URL (at >> least in the operating systems I'm aware of). > > I still don't get it. Can't you configure the browser to open your > calendaring application for the text/calendar content type? The browser > can invoke the application with the URL? > (I'm pretty sure that Mozilla allows that, and IE definitely does open > by URL when you invoke a Word document for example, so it should also > work there, somehow) The default is that the browser stores the content into a local temporary file, and then invokes the application with the file name. I do recall that MS IE has a way to actually pass the URL instead of the document, but when I researched this a long time ago, I couldn't figure out how that works. So let me know if you can convince one of these UAs to pass the URL, that would be an interesting outcome of this discussion as well. >> It addresses exactly this problem. If the iCalendar object doesn't >> contain the URL it came from, the calendar application lacks that >> essential piece of information. > > Yes, but in what case would you download a calendar via URL and then use > the same URL again to re-download the same entity. That just doesn't > make a lot sense? :-) Well, it would only happen once: you GET the calendar resource with your browser, which passes it to the calendar application. That application can then discover the "self" link, and offer to subscribe to the calendar. From there on, you would always use the calendar application to access the calendar. > Its really just a hack around an improper configuration of the URL/app > activation system. It's a workaround for a missing feature in current UAs. > Well, maybe the hack is worth it. But in this case I would prefer a > webcal:// scheme over an iCal embedded URL, to preserve the layering > between content and transport. : "Good practice: Reuse URI schemes A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources." BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 10:03:50 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391413A6944 for ; Fri, 22 Aug 2008 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aIXyVYcaK1B for ; Fri, 22 Aug 2008 10:03:49 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 575203A6931 for ; Fri, 22 Aug 2008 10:03:49 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A7D380D4B; Fri, 22 Aug 2008 10:03:19 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F3E280C3A for ; Fri, 22 Aug 2008 10:03:18 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 29AC7142233 for ; Fri, 22 Aug 2008 10:03:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 Z3aJ7bjn2Tbd for ; Fri, 22 Aug 2008 10:03:09 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9294214222B for ; Fri, 22 Aug 2008 10:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CF297BC4B97; Fri, 22 Aug 2008 13:03:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6wXLya635oC; Fri, 22 Aug 2008 13:03:09 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 6F43CBC4B90; Fri, 22 Aug 2008 13:03:08 -0400 (EDT) Date: Fri, 22 Aug 2008 13:03:05 -0400 From: Cyrus Daboo To: Julian Reschke , Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Message-ID: In-Reply-To: <48AEEE97.205@gmx.de> References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Julian, --On August 22, 2008 6:51:35 PM +0200 Julian Reschke wrote: >> Yes, but in what case would you download a calendar via URL and then use >> the same URL again to re-download the same entity. That just doesn't >> make a lot sense? :-) > > Well, it would only happen once: you GET the calendar resource with your > browser, which passes it to the calendar application. That application > can then discover the "self" link, and offer to subscribe to the > calendar. From there on, you would always use the calendar application to > access the calendar. By this argument then, any data handed off from a browser to another application should include the original URL embedded in it because the other app may want to re-fetch. So I think this is more an issue for the OS/Application URL hand-off process. The URL where the data originally came from ought to be attached to the file, or data stream, as meta-data. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 10:08:50 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2E43A69AE for ; Fri, 22 Aug 2008 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=1.503, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8OK8GIDrkd8 for ; Fri, 22 Aug 2008 10:08:49 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 274163A695E for ; Fri, 22 Aug 2008 10:08:49 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 7FB4E80D47; Fri, 22 Aug 2008 10:08:19 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A757D80D42 for ; Fri, 22 Aug 2008 10:08:17 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A16C614223C for ; Fri, 22 Aug 2008 10:08:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 0w58chY8XRSl for ; Fri, 22 Aug 2008 10:08:05 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E539142234 for ; Fri, 22 Aug 2008 10:08:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5E24F10F1595 for ; Fri, 22 Aug 2008 19:07:59 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id 2793310F1EE1 for ; Fri, 22 Aug 2008 19:07:44 +0200 (CEST) Message-Id: <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AEEE97.205@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 19:07:38 +0200 References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org On 22.08.2008, at 18:51, Julian Reschke wrote: > The default is that the browser stores the content into a local > temporary file, and then invokes the application with the file name. > > I do recall that MS IE has a way to actually pass the URL instead of > the document, but when I researched this a long time ago, I couldn't > figure out how that works. I couldn't find it in a quick search either, but I'm pretty sure its supposed to work. But then maybe not :-): http://bitworking.org/news/Atom_Auto_Sub_How_To OK. Another way would be to deliver a different content-type which contains the iCal URL. Something like this: --snip-- Content-type: application/x-url-to-open http://site/file.ics --snap-- Could be a generic 'URL reference' MIME type, or something text/ calendar specific. >> Well, maybe the hack is worth it. But in this case I would prefer a webcal:// >> scheme over an iCal embedded URL, to preserve the layering between >> content and transport. > > : > > "Good practice: Reuse URI schemes > > A specification SHOULD reuse an existing URI scheme (rather than > create a new one) when it provides the desired properties of > identifiers and their relation to resources." Its also good practice not to mix transport with content :-) OK, what about my special-reference entity suggestion then? Thanks, Helge PS: hey! you are supposed to do CalDAV anyways! and download of full vcals via HTTP ;-) -- Helge Hess http://helgehess.eu/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 10:11:13 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1523A68E6 for ; Fri, 22 Aug 2008 10:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYU0cOuUpjJQ for ; Fri, 22 Aug 2008 10:11:12 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 851113A682D for ; Fri, 22 Aug 2008 10:11:12 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id D016980D47; Fri, 22 Aug 2008 10:10:22 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9F5E980D42; Fri, 22 Aug 2008 10:10:21 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 99C3014223D; Fri, 22 Aug 2008 10:10:20 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 2Rskeo0lqTos; Fri, 22 Aug 2008 10:10:13 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3098D142234; Fri, 22 Aug 2008 10:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AEA3EBC4CC8; Fri, 22 Aug 2008 13:10:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQHt9WMlGKcz; Fri, 22 Aug 2008 13:10:13 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id BDC66BC4CC1; Fri, 22 Aug 2008 13:10:12 -0400 (EDT) Date: Fri, 22 Aug 2008 13:10:10 -0400 From: Cyrus Daboo To: Lisa Dusseault , ietf-calsify list Subject: Re: [Ietf-calsify] ADD is really optional --? Message-ID: <4E67FDD7B6161A9C919B2932@caldav.corp.apple.com> In-Reply-To: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> References: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Lisa, --On August 21, 2008 4:29:16 PM -0700 Lisa Dusseault wrote: > I'm doing AD Review of iTIP and the way I read specs like this by default > is that if there are a bunch of methods that can be sent around between > agents, all of them must be supported. > > However, for the ADD method, iTIP specifies a way for a receiving client > not to really support it -- return a REQUEST-STATUS of 3.14 followed by a > REFRESH request. Well that procedure can also be used for CANCEL and partial REQUESTs (ones that send only overridden instances). So this is not specific to ADD. > Is ADD routinely supported by iTIP implementations or is this exception > used in practice? I believe there are some clients out there that let users add instances to a recurring set, and I would expect them to use ADD. But I have no firm evidence of -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 10:15:27 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701D23A698F for ; Fri, 22 Aug 2008 10:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.639 X-Spam-Level: X-Spam-Status: No, score=-7.639 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sjy4TY9tOMR for ; Fri, 22 Aug 2008 10:15:26 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id A05A33A6981 for ; Fri, 22 Aug 2008 10:15:26 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 4DCF380D4B; Fri, 22 Aug 2008 10:14:31 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2EE5980D47 for ; Fri, 22 Aug 2008 10:14:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 292F514223C for ; Fri, 22 Aug 2008 10:14:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 kbOkbbmIXOha for ; Fri, 22 Aug 2008 10:14:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 2804E142234 for ; Fri, 22 Aug 2008 10:14:20 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 17:14:20 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp048) with SMTP; 22 Aug 2008 19:14:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18TyHZVu+0ToGdhRkThx/5xW7xWLBkD9XC4pqbi4A zyauIRoojqYokX Message-ID: <48AEF3E0.9040807@gmx.de> Date: Fri, 22 Aug 2008 19:14:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@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-FuHaFi: 0.66 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Cyrus Daboo wrote: >> Well, it would only happen once: you GET the calendar resource with your >> browser, which passes it to the calendar application. That application >> can then discover the "self" link, and offer to subscribe to the >> calendar. From there on, you would always use the calendar application to >> access the calendar. > > By this argument then, any data handed off from a browser to another > application should include the original URL embedded in it because the > other app may want to re-fetch. So I think this is more an issue for the > OS/Application URL hand-off process. The URL where the data originally > came from ought to be attached to the file, or data stream, as meta-data. I agree that it would be totally cool if it worked that way. But as far as I can tell, it doesn't. I'd love to learn how to configure IE/FF/Safari to do this. Maybe this is something for the (gasp) HTML5 WG to consider? BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Aug 22 10:21:41 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004063A67E2 for ; Fri, 22 Aug 2008 10:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.544 X-Spam-Level: X-Spam-Status: No, score=-7.544 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNjCFjIj81U9 for ; Fri, 22 Aug 2008 10:21:40 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 221423A67CF for ; Fri, 22 Aug 2008 10:21:40 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id A69B880D4B; Fri, 22 Aug 2008 10:20:54 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 01E7C80D47 for ; Fri, 22 Aug 2008 10:20:53 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F025414223C for ; Fri, 22 Aug 2008 10:20:51 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 8YEjPa+PoOEt for ; Fri, 22 Aug 2008 10:20:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id D4D62142234 for ; Fri, 22 Aug 2008 10:20:38 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 17:20:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 22 Aug 2008 19:20:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8KXdC/ZC8WSNhQaPglGb7xDDGAWZJUjDxjFcvua xujMoLzmp/hVbW Message-ID: <48AEF55B.2090400@gmx.de> Date: Fri, 22 Aug 2008 19:20:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> In-Reply-To: <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Helge Hess wrote: > On 22.08.2008, at 18:51, Julian Reschke wrote: >> The default is that the browser stores the content into a local >> temporary file, and then invokes the application with the file name. >> >> I do recall that MS IE has a way to actually pass the URL instead of >> the document, but when I researched this a long time ago, I couldn't >> figure out how that works. > > I couldn't find it in a quick search either, but I'm pretty sure its > supposed to work. But then maybe not :-): > > http://bitworking.org/news/Atom_Auto_Sub_How_To Yes. That one inspired me to do RFC 4709. > OK. Another way would be to deliver a different content-type which > contains the iCal URL. Something like this: > --snip-- > Content-type: application/x-url-to-open > > http://site/file.ics > --snap-- > Could be a generic 'URL reference' MIME type, or something text/calendar > specific. It would need to be specific, otherwise you can't dispatch to the right application. See RFC 4709 :-). >>> Well, maybe the hack is worth it. But in this case I would prefer a >>> webcal:// scheme over an iCal embedded URL, to preserve the layering >>> between content and transport. >> >> : >> >> "Good practice: Reuse URI schemes >> >> A specification SHOULD reuse an existing URI scheme (rather than >> create a new one) when it provides the desired properties of >> identifiers and their relation to resources." > > Its also good practice not to mix transport with content :-) > > OK, what about my special-reference entity suggestion then? That would work as well, and this is what I've been using for launching WebDAV clients (successfully). The "embed-the-source" approach works as well if content is being transferred anyway, and this is what Atom (RFC4287) uses. > PS: hey! you are supposed to do CalDAV anyways! and download of full > vcals via HTTP ;-) But, as far as I can tell, this has the same problem. How do you send a URL to a CalDAV calendar in an email? How does a Web server implement the "subscribe this with Caldav" functionality? As a matter of fact, my original proposal would work in that case as well. A CalDAV-aware client could do OPTIONS on the URI first, and check for CalDAV support, and then do "the right thing". BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Aug 26 07:03:09 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236363A6C66 for ; Tue, 26 Aug 2008 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hswiNQjh1dVA for ; Tue, 26 Aug 2008 07:03:08 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 3770C3A6B73 for ; Tue, 26 Aug 2008 07:03:05 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 879BD80D77; Tue, 26 Aug 2008 07:02:38 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7681E80D75 for ; Tue, 26 Aug 2008 07:02:37 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5DD9E14225C for ; Tue, 26 Aug 2008 07:02:36 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 eDTQlMYsPw4A; Tue, 26 Aug 2008 07:02:25 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5139E14225E; Tue, 26 Aug 2008 07:02:23 -0700 (PDT) Message-Id: From: Lisa Dusseault To: ietf-calsify list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 07:02:23 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] Proposed new text for 3.4.6 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org I was looking at the first few paragraphs of 3.4.6 and I couldn't quite figure out how the sending of a REFRESH, by the Organizer or an Attendee, combined with specifying a RECURRENCE-ID or not, and what the appropriate replies were for all cases. Here's proposed new text. ------------ The "REFRESH" method in a "VTODO" calendar component is used either by "Attendees" or by the "Organizer" of an existing "VTODO" calendar component. When an "Attendee" sends a "REFRESH" method, it's to request an updated description of the "VTODO" from the "Organizer". When an "Organizer" sends a "REFRESH" method, it's to request updated status from one or more "Attendees". The "REFRESH" method MUST specify the "UID" property corresponding to the "VTODO" calendar component needing update. It MAY specify the "RECURRENCE-ID" property also, to identify a specific instance. Appropriate success responses to a "REFRESH" method: - If an attendee sends the "REFRESH" method with a UID but not a RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and the entire "VTODO" to bring the attendee up to date. - If an attendee sends the "REFRESH" method and it identifies a RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and the "VTODO" instance. - If an "Organizer" sends the "REFRESH" method with a UID but not a RECURRENCE-ID, each recipient attempts to identify themselves in the "Attendee" list (possibly in several "Attendee" lists if there are exception instances), and checks their "PARTSTAT" to see if any update on their participation status is required. If it is, they respond with a REPLY that includes each new status. - If an "Organizer" sends the "REFRESH" method and it identifies a RECURRENCE-ID, then the recipient attempts to identify itself in the "Attendee" list for that instance, and if their PARTSTAT needs refreshing, responds with a REPLY including only the instance in question. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Aug 26 09:16:13 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256CF3A6935 for ; Tue, 26 Aug 2008 09:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.108 X-Spam-Level: X-Spam-Status: No, score=-105.108 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2pL0ujz87t6 for ; Tue, 26 Aug 2008 09:16:10 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 970FE3A67AB for ; Tue, 26 Aug 2008 09:16:10 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C06280CAF; Tue, 26 Aug 2008 09:15:55 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C3B6D80CAE for ; Tue, 26 Aug 2008 09:15:53 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9DD7142255 for ; Tue, 26 Aug 2008 09:15:52 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 Plz1Xy8UTMMe for ; Tue, 26 Aug 2008 09:15:45 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BCFA142241 for ; Tue, 26 Aug 2008 09:15:45 -0700 (PDT) Message-Id: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> From: Lisa Dusseault To: ietf-calsify list Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 09:15:46 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] AD Review of RFC2446bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0683634916==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============0683634916== Content-Type: multipart/alternative; boundary=Apple-Mail-1-941977697 --Apple-Mail-1-941977697 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Here's my review of version -07. I have no high-level problems except a suggestion for formatting the constraints tables throughout the document if Cyrus is willing. ---- Section 1.4 Says that ADD can be used to add one or more new instances to an existing VEVENT, VTODO or VJOURNAL. However, I'm not entirely clear how an iTIP recipient would get the VTODO or VJOURNAL in the first place. PUBLISH includes any type of calendar entry -- what does "calendar entry" define and include (It's mentioned only once that I can find in 2445bis)? Any iCalendar component? Section 3 First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL and VFREEBUSY, but that REQUEST can be used for all except VJOURNAL. This doesn't appear consistent with the text in Section 1.4 which implies that REQUEST can schedule any calendar entry. Maybe we're back to the missing definition of "calendar entry". Section 3.2 Main table says that the PUBLISH method constraints include 0 VTODO or VJOURNAL components. In section 3.2.2, REQUEST also has 0 , and in section 3.2.4, ADD has 0 VTODOs or VJOURNALs. Isn't this in contradiction to section 1.4's description of ADD? Doesn't this mean you can't send a VTODO or VJOURNAL out in iTIP at all? ... It turns out I need to interpret the tables of constraints in a narrower context. I suggest that the context be part of the title or first row of the table. Section 3.2.2.6 The event flow seems incomplete. It describes how a request can be forwarded to a new CU that wasn't invited, and then the organizer decides whether or not to add the uninvited CU to the attendee list. We're missing the step in between where the organizer learns that the new CU was invited. Is this by receiving a response from the uninvited CU, being cc'ed on the forwarded REQUEST, or receiving a separate copy of the REQUEST or a COUNTER, or any of the above? Same section: phrases like "a new ATTENDEE property is added" are in passive voice, aren't very clear about who is responsible. In this case it should be something like If the "Organizer" decides to add an uninvited CU, the CU of the "Organizer" adds a new "ATTENDEE" property with the uninvited CU with its property parameters set as the "Organizer" deems appropriate. Section 3.2.3: The "REPLY" method may also be used to respond to an unsuccessful "REQUEST" method. Is there something missing here? I read "unsuccessful" as a request that was not received. Hard to know how to reply to a request that was not received. Section 3.3 "FREEBUSY" properties should be sorted such that their values are in ascending order, based on the start time, and then the end time, with the earliest periods first. Is there a reason why the SHOULD isn't capitalized? Is there a reason why it's not a MUST? The busy time information within the iCalendar object MAY be grouped into more than one "VFREEBUSY" calendar component. This requirement does not seem consistent with the tables in 3.3.2 or 3.3.3, where the "Presence" column says that only one VFREEBUSY component is allowed. If it's only true for PUBLISH, then this statement quoted above should be moved into the section on PUBLISH (3.3.1) or even called out. Section 3.4.2: The originator of a "REQUEST" is the "Organizer" of the to-do. The recipient of a "REQUEST" is the "Calendar User" assigned the to-do. The REQUEST method is also used by the delegator as explained in 3.4.2.3. Maybe we should just add a prefix: "In the most typical case, the originator of a REQUEST is..." Next question in this same text: How do user agents check that they are in fact the Calendar User assigned the to-do, and not just being cc'ed? Section 3.4.4 If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". Shouldn't this be 3.14 error instead of 5.3? Section 3.2.4 for ADD uses a REQUEST-STATUS of 3.14 for the same case. Section 3.4.6 I'm going to suggest a rewrite of these paragraphs -- sent separate mail. Section 3.6, table, row for code 5.0 says: "Request MAY supported" Something must be missing here? Section 3.7.3: Clients are not required to save X-Tokens or use them in replies. It seems curious to have this anti-requirement, where there is no requirement of this sort for ordinary properties. I couldn't find any requirement that standard properties in iCalendar methods must be saved or used in replies. Section 4.2.4: The example in this section claims that the COUNTER requests a change to time and place of the meeting. However, it looks like the LOCATION field has "Green Conference Room" in both the original REQUEST and in the COUNTER. Section 4.2.5 says: It is not required that the "Delegate" include the "Delegator" in their "REPLY" method. However, it is strongly advised since this will inform the "Delegator" whether the "Delegate" plans to attend the meeting. However, Section 4.2.7 says: In this example the "Delegate" declines the meeting request and sets the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" parameter of the "Delegate" set to "DECLINED". This lets the "Delegator" know that the "Delegate" has declined and provides an opportunity to the "Delegator" to either accept the request or delegate it to another CU. These are inconsistent because section 4.2.5 indicates that the Delegate is responsible for letting the "Delegator" know if they've accepted. Section 4.2.7, however, does not say that the Delegate does so (it is silent) but it does say that the "Organizer" sends an update that lets the "Delegator" know if the delegate accepted. Is it the Delegate, the Organizer or both that are responsible for letting the Delegator know the accept status? Section 4.5.5: A reply indicating that "D" completed "D's" part of the assignment. Section 4.5.6 continues the example, however: ATTENDEE;PARTSTAT=IN- PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"? Section 5.1.1: +---------------- +--------------------------------------------------+ | Method | Fallback | +---------------- +--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with Not Supported | | DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | | | otherwise reply with Not Supported | +---------------- +--------------------------------------------------+ In this table, the "Fallback" context is inconsistent. Saying that the fallback if you don't support REQUEST is to send a PUBLISH is an instruction to the sender. However, saying that the fallback if you don't support COUNTER is to reply with Not Supported, is an instruction to the receiver. Isn't there a difference between "Required to be able to send" and "Required to be able to handle on receiving"? Thus, all iTIP clients MUST be able to receive PUBLISH requests but obviously aren't required to send them. COUNTER is not required to be sent or received. REPLY is required to be both sent and handled on receiving. Section 7. IANA Considerations I do not see any existing IANA registry for the iCalendar "METHOD" property values. If there is a registry, please provide the URL to help IANA. They will also need to be instructed to update the reference for these methods from 2446 to 2446bis. if, on the other hand there is no such registry and we are trying to create one, then IANA needs more clear instructions on creating the new registry and what fields it has and how entries are added (IETF consensus, expert assignment, First-come-first-served) --Apple-Mail-1-941977697 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Here's my review of = version -07.  I have no high-level problems except a suggestion for = formatting the constraints tables throughout the document if Cyrus is = willing.

----

Section = 1.4
Says that ADD can be used to add one or more new instances = to an existing VEVENT, VTODO or VJOURNAL.  However, I'm not = entirely clear how an iTIP recipient would get the VTODO or VJOURNAL in = the first place.  PUBLISH includes any type of calendar entry -- = what does "calendar entry" define and include (It's mentioned only once = that I can find in 2445bis)?  Any iCalendar = component?

Section 3
First table says that PUBLISH can = be used for VEVENT, VTODO, VJOURNAL and VFREEBUSY, but that REQUEST can = be used for all except VJOURNAL.  This doesn't appear consistent = with the text in Section 1.4 which implies that REQUEST can schedule any = calendar entry.  Maybe we're back to the missing definition of = "calendar entry".

Section 3.2
Main table says that the = PUBLISH method constraints include 0 VTODO or VJOURNAL components. =  In section 3.2.2,  REQUEST also has 0 , and in section 3.2.4, = ADD has 0 VTODOs or VJOURNALs.  Isn't this in contradiction to = section 1.4's description of ADD?  Doesn't this mean you can't send = a VTODO or VJOURNAL out in iTIP at all?  ... It turns out I need to = interpret the tables of constraints in a narrower context.  I = suggest that the context be part of the title or first row of the table. =  

Section 3.2.2.6 
The event flow = seems incomplete.  It describes how a request can be forwarded to a = new CU that wasn't invited, and then the organizer decides whether or = not to add the uninvited CU to the attendee list.  We're missing = the step in between where the organizer learns that the new CU was = invited. Is this by receiving a response from the uninvited CU, being = cc'ed on the forwarded REQUEST, or receiving a separate copy of the = REQUEST or a COUNTER, or any of the above?

Same section: phrases = like "a new ATTENDEE property is added" are in passive voice, aren't = very clear about who is responsible.  In this case it should be = something like
If the "Organizer" decides to add an uninvited CU, the = CU
= of the "Organizer" adds a new "ATTENDEE" property with
the = uninvited CU with its property parameters set as the
= "Organizer" deems appropriate.
Section = 3.2.3:
   The "REPLY" method may also = be used to respond to an unsuccessful
   "REQUEST" = method.  

Is there something missing here? =  I read "unsuccessful" as a request that was not received. =  Hard to know how to reply to a request that was not received. =  

Section 3.3
   ascending order, based on the = start time, and then the end time, with
   the earliest = periods first.  

Is there a reason why the SHOULD = isn't capitalized?  Is there a reason why it's not a = MUST? 

   The busy time = information within the iCalendar object MAY be grouped

This requirement does not seem = consistent with the tables in 3.3.2 or 3.3.3, where the "Presence" = column says that only one VFREEBUSY component is allowed.  If it's = only true for PUBLISH, then this statement quoted above should be moved = into the section on PUBLISH (3.3.1) or even called out.
Section 3.4.2:
   The = originator of a "REQUEST" is the "Organizer" of the to-do.  = The
   recipient of a "REQUEST" is the = "Calendar User" assigned the to-do.

The REQUEST = method is also used by the delegator as explained in 3.4.2.3. =  Maybe we should just add a prefix:  "In the most typical = case, the originator of a REQUEST = is..." 

Next question in this same text: =  How do user agents check that they are in fact the Calendar User = assigned the to-do, and not just being cc'ed? =  

Section = 3.4.4

If an "Attendee" implementation = does not support the "ADD"
   method it should = respond with a "REQUEST-STATUS" value of 5.3 and ask

Shouldn't this be 3.14 = error instead of 5.3?  Section 3.2.4 for ADD uses a REQUEST-STATUS = of 3.14 for the same case.

Section = 3.4.6 

I'm going to suggest a rewrite of = these paragraphs -- sent separate mail.

"Request MAY = supported"

Something must be missing = here?

Section 3.7.3:
= Clients are not required to save X-Tokens or use them

It seems curious to have = this anti-requirement, where there is no requirement of this sort for = ordinary properties.  I couldn't find any requirement that standard = properties in iCalendar methods must be saved or used in replies. =  

Section 4.2.4: The example in = this section claims that the COUNTER requests a change to time = and place of the meeting.  However, it looks like = the LOCATION field has "Green Conference Room" in both the original = REQUEST and in the COUNTER.



  It is not required = that the "Delegate" include the "Delegator" in
   will inform the "Delegator" = whether the "Delegate" plans to attend
   the meeting. =  

However, Section 4.2.7 = says:

   In this example = the "Delegate" declines the meeting request and sets
   "Organizer" SHOULD resend the = "REQUEST" to "C" with the "PARTSTAT"
   parameter of the = "Delegate" set to "DECLINED".  This lets the
   opportunity to the "Delegator" to = either accept the request or
   delegate it to = another CU.


These are = inconsistent because section 4.2.5 indicates that the Delegate is = responsible for letting the "Delegator" know if they've accepted. =  Section 4.2.7, however, does not say that the Delegate does so (it = is silent) but it does say that the "Organizer" sends an update =  that lets the "Delegator" know if the delegate accepted.   Is = it the Delegate, the Organizer or both that are responsible for letting = the Delegator know the accept = status?


Section = 4.5.5:

   A reply = indicating that "D" completed "D's" part of the assignment.
Section 4.5.6 continues the example, = however:

   =   ATTENDEE;PARTSTAT=3DIN-PROCESS;CUTYPE=3DINDIVIDUAL:mailto:d@example.com
Shouldn't "D"'s PARTSTAT be COMPLETED rather = than "IN-PROCESS"?


Section 5.1.1:
   | Method       =   | Fallback               =                     =       |
   = +----------------+--------------------------------------------------+
   | DECLINECOUNTER | Required if = EVENT-COUNTER is implemented;        |
   = +----------------+--------------------------------------------------+

In this table, the "Fallback" context is = inconsistent.  Saying that the fallback if you don't support = REQUEST is to send a PUBLISH is an instruction to the sender. =  However, saying that the fallback if you don't support COUNTER is = to reply with Not Supported, is an instruction to the = receiver.

Isn't there a difference between = "Required to be able to send" and "Required to be able to handle on = receiving"?   Thus, all iTIP clients MUST be able to receive = PUBLISH requests but obviously aren't required to send them.   = COUNTER is not required to be sent or received.  REPLY is required = to be both sent and handled on = receiving. 


Section 7. =  IANA Considerations

I do not see any = existing IANA registry for the iCalendar "METHOD" property values. =  If there is a registry, please provide the URL to help IANA. =  They will also need to be instructed to update the reference for = these methods from 2446 to 2446bis.

if, on the = other hand there is no such registry and we are trying to create one, = then IANA needs more clear instructions on creating the new registry and = what fields it has and how entries are added (IETF consensus, expert = assignment, = First-come-first-served)


= --Apple-Mail-1-941977697-- --===============0683634916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============0683634916==-- From ietf-calsify-bounces@osafoundation.org Wed Aug 27 05:33:57 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33753A6884 for ; Wed, 27 Aug 2008 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhhczjCnunv2 for ; Wed, 27 Aug 2008 05:33:56 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id 0CC993A6843 for ; Wed, 27 Aug 2008 05:33:56 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 27C2880D9B; Wed, 27 Aug 2008 05:33:57 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 28EFC80D91; Wed, 27 Aug 2008 05:33:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0BF47142241; Wed, 27 Aug 2008 05:33:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 Lh8MnN1wtDmq; Wed, 27 Aug 2008 05:33:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D58A714223F; Wed, 27 Aug 2008 05:33:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,278,1217808000"; d="scan'208";a="18363087" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2008 12:33:26 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7RCXB1P013301; Wed, 27 Aug 2008 14:33:11 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp438.cisco.com [10.61.65.182]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7RCXBFs002322; Wed, 27 Aug 2008 12:33:11 GMT Message-ID: <48B54986.1020900@cisco.com> Date: Wed, 27 Aug 2008 14:33:10 +0200 From: Eliot Lear User-Agent: Thunderbird/3.0b1pre (Macintosh; 20080826030720) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-calsify] AD Review of RFC2446bis References: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> In-Reply-To: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9305; t=1219840391; x=1220704391; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20AD=20Review=20of=20RFC 2446bis |Sender:=20; bh=HcNB/xqm1R+eTXYeUbCvEjGAzCaeHti9o7sGBRXKsqM=; b=DK4oegVlRnM2iRVD/PRrj0cfE9mSb7HPajc082DVMINHZo7O0elqUr6hvL vLpru2OzM80b3NAGg8z/rd+UQbUUzV9BBSHxdEQl6JQTisRHgcMFsOXDyThI AJ0K+QbrV4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ietf-calsify list X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Lisa, Thanks very much for your review. Would the WG like to comment? Eliot Lisa Dusseault wrote: > Here's my review of version -07. I have no high-level problems except > a suggestion for formatting the constraints tables throughout the > document if Cyrus is willing. > > ---- > > Section 1.4 > Says that ADD can be used to add one or more new instances to an > existing VEVENT, VTODO or VJOURNAL. However, I'm not entirely clear > how an iTIP recipient would get the VTODO or VJOURNAL in the first > place. PUBLISH includes any type of calendar entry -- what does > "calendar entry" define and include (It's mentioned only once that I > can find in 2445bis)? Any iCalendar component? > > Section 3 > First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL > and VFREEBUSY, but that REQUEST can be used for all except VJOURNAL. > This doesn't appear consistent with the text in Section 1.4 which > implies that REQUEST can schedule any calendar entry. Maybe we're > back to the missing definition of "calendar entry". > > Section 3.2 > Main table says that the PUBLISH method constraints include 0 VTODO or > VJOURNAL components. In section 3.2.2, REQUEST also has 0 , and in > section 3.2.4, ADD has 0 VTODOs or VJOURNALs. Isn't this in > contradiction to section 1.4's description of ADD? Doesn't this mean > you can't send a VTODO or VJOURNAL out in iTIP at all? ... It turns > out I need to interpret the tables of constraints in a narrower > context. I suggest that the context be part of the title or first row > of the table. > > Section 3.2.2.6 > The event flow seems incomplete. It describes how a request can be > forwarded to a new CU that wasn't invited, and then the organizer > decides whether or not to add the uninvited CU to the attendee list. > We're missing the step in between where the organizer learns that the > new CU was invited. Is this by receiving a response from the uninvited > CU, being cc'ed on the forwarded REQUEST, or receiving a separate copy > of the REQUEST or a COUNTER, or any of the above? > > Same section: phrases like "a new ATTENDEE property is added" are in > passive voice, aren't very clear about who is responsible. In this > case it should be something like > If the "Organizer" decides to add an uninvited CU, the CU > of the "Organizer" adds a new "ATTENDEE" property with > the uninvited CU with its property parameters set as the > "Organizer" deems appropriate. > Section 3.2.3: > The "REPLY" method may also be used to respond to an unsuccessful > "REQUEST" method. > > Is there something missing here? I read "unsuccessful" as a request > that was not received. Hard to know how to reply to a request that > was not received. > > Section 3.3 > "FREEBUSY" properties should be sorted such that their values are in > ascending order, based on the start time, and then the end time, with > the earliest periods first. > > Is there a reason why the SHOULD isn't capitalized? Is there a reason > why it's not a MUST? > > The busy time information within the iCalendar object MAY be grouped > into more than one "VFREEBUSY" calendar component. > > This requirement does not seem consistent with the tables in 3.3.2 or > 3.3.3, where the "Presence" column says that only one VFREEBUSY > component is allowed. If it's only true for PUBLISH, then this > statement quoted above should be moved into the section on PUBLISH > (3.3.1) or even called out. > > Section 3.4.2: > The originator of a "REQUEST" is the "Organizer" of the to-do. The > recipient of a "REQUEST" is the "Calendar User" assigned the to-do. > > The REQUEST method is also used by the delegator as explained in > 3.4.2.3. Maybe we should just add a prefix: "In the most typical > case, the originator of a REQUEST is..." > > Next question in this same text: How do user agents check that they > are in fact the Calendar User assigned the to-do, and not just being > cc'ed? > > Section 3.4.4 > > If an "Attendee" implementation does not support the "ADD" > method it should respond with a "REQUEST-STATUS" value of 5.3 and ask > for a "REFRESH". > > Shouldn't this be 3.14 error instead of 5.3? Section 3.2.4 for ADD > uses a REQUEST-STATUS of 3.14 for the same case. > > Section 3.4.6 > > I'm going to suggest a rewrite of these paragraphs -- sent separate mail. > > Section 3.6, table, row for code 5.0 says: > > "Request MAY supported" > > Something must be missing here? > > Section 3.7.3: > Clients are not required to save X-Tokens or use them > in replies. > > It seems curious to have this anti-requirement, where there is no > requirement of this sort for ordinary properties. I couldn't find any > requirement that standard properties in iCalendar methods must be > saved or used in replies. > > Section 4.2.4: The example in this section claims that the COUNTER > requests a change to time and *place* of the meeting. However, it > looks like the LOCATION field has "Green Conference Room" in both the > original REQUEST and in the COUNTER. > > > Section 4.2.5 says: > > It is not required that the "Delegate" include the "Delegator" in > their "REPLY" method. However, it is strongly advised since this > will inform the "Delegator" whether the "Delegate" plans to attend > the meeting. > > However, Section 4.2.7 says: > > In this example the "Delegate" declines the meeting request and sets > the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The > "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" > parameter of the "Delegate" set to "DECLINED". This lets the > "Delegator" know that the "Delegate" has declined and provides an > opportunity to the "Delegator" to either accept the request or > delegate it to another CU. > > > These are inconsistent because section 4.2.5 indicates that the > Delegate is responsible for letting the "Delegator" know if they've > accepted. Section 4.2.7, however, does not say that the Delegate does > so (it is silent) but it does say that the "Organizer" sends an update > that lets the "Delegator" know if the delegate accepted. Is it the > Delegate, the Organizer or both that are responsible for letting the > Delegator know the accept status? > > > Section 4.5.5: > > A reply indicating that "D" completed "D's" part of the assignment. > > Section 4.5.6 continues the example, however: > > ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com > > Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"? > > > Section 5.1.1: > > +----------------+--------------------------------------------------+ > | Method | Fallback | > +----------------+--------------------------------------------------+ > | PUBLISH | Required | > | REQUEST | PUBLISH | > | REPLY | Required | > | ADD | Required | > | CANCEL | Required | > | REFRESH | Required | > | COUNTER | Reply with Not Supported | > | DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | > | | otherwise reply with Not Supported | > +----------------+--------------------------------------------------+ > > In this table, the "Fallback" context is inconsistent. Saying that > the fallback if you don't support REQUEST is to send a PUBLISH is an > instruction to the sender. However, saying that the fallback if you > don't support COUNTER is to reply with Not Supported, is an > instruction to the receiver. > > Isn't there a difference between "Required to be able to send" and > "Required to be able to handle on receiving"? Thus, all iTIP clients > MUST be able to receive PUBLISH requests but obviously aren't required > to send them. COUNTER is not required to be sent or received. REPLY > is required to be both sent and handled on receiving. > > > Section 7. IANA Considerations > > I do not see any existing IANA registry for the iCalendar "METHOD" > property values. If there is a registry, please provide the URL to > help IANA. They will also need to be instructed to update the > reference for these methods from 2446 to 2446bis. > > if, on the other hand there is no such registry and we are trying to > create one, then IANA needs more clear instructions on creating the > new registry and what fields it has and how entries are added (IETF > consensus, expert assignment, First-come-first-served) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 28EFC80D91; Wed, 27 Aug 2008 05:33:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0BF47142241; Wed, 27 Aug 2008 05:33:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-50 required=4 tests=[AWL=2.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001] 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 Lh8MnN1wtDmq; Wed, 27 Aug 2008 05:33:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D58A714223F; Wed, 27 Aug 2008 05:33:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,278,1217808000"; d="scan'208";a="18363087" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2008 12:33:26 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7RCXB1P013301; Wed, 27 Aug 2008 14:33:11 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp438.cisco.com [10.61.65.182]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7RCXBFs002322; Wed, 27 Aug 2008 12:33:11 GMT Message-ID: <48B54986.1020900@cisco.com> Date: Wed, 27 Aug 2008 14:33:10 +0200 From: Eliot Lear User-Agent: Thunderbird/3.0b1pre (Macintosh; 20080826030720) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-calsify] AD Review of RFC2446bis References: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> In-Reply-To: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9305; t=1219840391; x=1220704391; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20AD=20Review=20of=20RFC 2446bis |Sender:=20; bh=HcNB/xqm1R+eTXYeUbCvEjGAzCaeHti9o7sGBRXKsqM=; b=DK4oegVlRnM2iRVD/PRrj0cfE9mSb7HPajc082DVMINHZo7O0elqUr6hvL vLpru2OzM80b3NAGg8z/rd+UQbUUzV9BBSHxdEQl6JQTisRHgcMFsOXDyThI AJ0K+QbrV4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ietf-calsify list X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 12:33:55 -0000 Lisa, Thanks very much for your review. Would the WG like to comment? Eliot Lisa Dusseault wrote: > Here's my review of version -07. I have no high-level problems except > a suggestion for formatting the constraints tables throughout the > document if Cyrus is willing. > > ---- > > Section 1.4 > Says that ADD can be used to add one or more new instances to an > existing VEVENT, VTODO or VJOURNAL. However, I'm not entirely clear > how an iTIP recipient would get the VTODO or VJOURNAL in the first > place. PUBLISH includes any type of calendar entry -- what does > "calendar entry" define and include (It's mentioned only once that I > can find in 2445bis)? Any iCalendar component? > > Section 3 > First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL > and VFREEBUSY, but that REQUEST can be used for all except VJOURNAL. > This doesn't appear consistent with the text in Section 1.4 which > implies that REQUEST can schedule any calendar entry. Maybe we're > back to the missing definition of "calendar entry". > > Section 3.2 > Main table says that the PUBLISH method constraints include 0 VTODO or > VJOURNAL components. In section 3.2.2, REQUEST also has 0 , and in > section 3.2.4, ADD has 0 VTODOs or VJOURNALs. Isn't this in > contradiction to section 1.4's description of ADD? Doesn't this mean > you can't send a VTODO or VJOURNAL out in iTIP at all? ... It turns > out I need to interpret the tables of constraints in a narrower > context. I suggest that the context be part of the title or first row > of the table. > > Section 3.2.2.6 > The event flow seems incomplete. It describes how a request can be > forwarded to a new CU that wasn't invited, and then the organizer > decides whether or not to add the uninvited CU to the attendee list. > We're missing the step in between where the organizer learns that the > new CU was invited. Is this by receiving a response from the uninvited > CU, being cc'ed on the forwarded REQUEST, or receiving a separate copy > of the REQUEST or a COUNTER, or any of the above? > > Same section: phrases like "a new ATTENDEE property is added" are in > passive voice, aren't very clear about who is responsible. In this > case it should be something like > If the "Organizer" decides to add an uninvited CU, the CU > of the "Organizer" adds a new "ATTENDEE" property with > the uninvited CU with its property parameters set as the > "Organizer" deems appropriate. > Section 3.2.3: > The "REPLY" method may also be used to respond to an unsuccessful > "REQUEST" method. > > Is there something missing here? I read "unsuccessful" as a request > that was not received. Hard to know how to reply to a request that > was not received. > > Section 3.3 > "FREEBUSY" properties should be sorted such that their values are in > ascending order, based on the start time, and then the end time, with > the earliest periods first. > > Is there a reason why the SHOULD isn't capitalized? Is there a reason > why it's not a MUST? > > The busy time information within the iCalendar object MAY be grouped > into more than one "VFREEBUSY" calendar component. > > This requirement does not seem consistent with the tables in 3.3.2 or > 3.3.3, where the "Presence" column says that only one VFREEBUSY > component is allowed. If it's only true for PUBLISH, then this > statement quoted above should be moved into the section on PUBLISH > (3.3.1) or even called out. > > Section 3.4.2: > The originator of a "REQUEST" is the "Organizer" of the to-do. The > recipient of a "REQUEST" is the "Calendar User" assigned the to-do. > > The REQUEST method is also used by the delegator as explained in > 3.4.2.3. Maybe we should just add a prefix: "In the most typical > case, the originator of a REQUEST is..." > > Next question in this same text: How do user agents check that they > are in fact the Calendar User assigned the to-do, and not just being > cc'ed? > > Section 3.4.4 > > If an "Attendee" implementation does not support the "ADD" > method it should respond with a "REQUEST-STATUS" value of 5.3 and ask > for a "REFRESH". > > Shouldn't this be 3.14 error instead of 5.3? Section 3.2.4 for ADD > uses a REQUEST-STATUS of 3.14 for the same case. > > Section 3.4.6 > > I'm going to suggest a rewrite of these paragraphs -- sent separate mail. > > Section 3.6, table, row for code 5.0 says: > > "Request MAY supported" > > Something must be missing here? > > Section 3.7.3: > Clients are not required to save X-Tokens or use them > in replies. > > It seems curious to have this anti-requirement, where there is no > requirement of this sort for ordinary properties. I couldn't find any > requirement that standard properties in iCalendar methods must be > saved or used in replies. > > Section 4.2.4: The example in this section claims that the COUNTER > requests a change to time and *place* of the meeting. However, it > looks like the LOCATION field has "Green Conference Room" in both the > original REQUEST and in the COUNTER. > > > Section 4.2.5 says: > > It is not required that the "Delegate" include the "Delegator" in > their "REPLY" method. However, it is strongly advised since this > will inform the "Delegator" whether the "Delegate" plans to attend > the meeting. > > However, Section 4.2.7 says: > > In this example the "Delegate" declines the meeting request and sets > the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The > "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" > parameter of the "Delegate" set to "DECLINED". This lets the > "Delegator" know that the "Delegate" has declined and provides an > opportunity to the "Delegator" to either accept the request or > delegate it to another CU. > > > These are inconsistent because section 4.2.5 indicates that the > Delegate is responsible for letting the "Delegator" know if they've > accepted. Section 4.2.7, however, does not say that the Delegate does > so (it is silent) but it does say that the "Organizer" sends an update > that lets the "Delegator" know if the delegate accepted. Is it the > Delegate, the Organizer or both that are responsible for letting the > Delegator know the accept status? > > > Section 4.5.5: > > A reply indicating that "D" completed "D's" part of the assignment. > > Section 4.5.6 continues the example, however: > > ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com > > Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"? > > > Section 5.1.1: > > +----------------+--------------------------------------------------+ > | Method | Fallback | > +----------------+--------------------------------------------------+ > | PUBLISH | Required | > | REQUEST | PUBLISH | > | REPLY | Required | > | ADD | Required | > | CANCEL | Required | > | REFRESH | Required | > | COUNTER | Reply with Not Supported | > | DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | > | | otherwise reply with Not Supported | > +----------------+--------------------------------------------------+ > > In this table, the "Fallback" context is inconsistent. Saying that > the fallback if you don't support REQUEST is to send a PUBLISH is an > instruction to the sender. However, saying that the fallback if you > don't support COUNTER is to reply with Not Supported, is an > instruction to the receiver. > > Isn't there a difference between "Required to be able to send" and > "Required to be able to handle on receiving"? Thus, all iTIP clients > MUST be able to receive PUBLISH requests but obviously aren't required > to send them. COUNTER is not required to be sent or received. REPLY > is required to be both sent and handled on receiving. > > > Section 7. IANA Considerations > > I do not see any existing IANA registry for the iCalendar "METHOD" > property values. If there is a registry, please provide the URL to > help IANA. They will also need to be instructed to update the > reference for these methods from 2446 to 2446bis. > > if, on the other hand there is no such registry and we are trying to > create one, then IANA needs more clear instructions on creating the > new registry and what fields it has and how entries are added (IETF > consensus, expert assignment, First-come-first-served) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C3B6D80CAE for ; Tue, 26 Aug 2008 09:15:53 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9DD7142255 for ; Tue, 26 Aug 2008 09:15:52 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-50 required=4 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SPF_FAIL=0.693] 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 Plz1Xy8UTMMe for ; Tue, 26 Aug 2008 09:15:45 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BCFA142241 for ; Tue, 26 Aug 2008 09:15:45 -0700 (PDT) Message-Id: <1918C4F5-A47D-4C95-942C-6036D11C9B95@osafoundation.org> From: Lisa Dusseault To: ietf-calsify list Content-Type: multipart/alternative; boundary=Apple-Mail-1-941977697 Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 09:15:46 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] AD Review of RFC2446bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2008 16:15:53 -0000 --Apple-Mail-1-941977697 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Here's my review of version -07. I have no high-level problems except a suggestion for formatting the constraints tables throughout the document if Cyrus is willing. ---- Section 1.4 Says that ADD can be used to add one or more new instances to an existing VEVENT, VTODO or VJOURNAL. However, I'm not entirely clear how an iTIP recipient would get the VTODO or VJOURNAL in the first place. PUBLISH includes any type of calendar entry -- what does "calendar entry" define and include (It's mentioned only once that I can find in 2445bis)? Any iCalendar component? Section 3 First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL and VFREEBUSY, but that REQUEST can be used for all except VJOURNAL. This doesn't appear consistent with the text in Section 1.4 which implies that REQUEST can schedule any calendar entry. Maybe we're back to the missing definition of "calendar entry". Section 3.2 Main table says that the PUBLISH method constraints include 0 VTODO or VJOURNAL components. In section 3.2.2, REQUEST also has 0 , and in section 3.2.4, ADD has 0 VTODOs or VJOURNALs. Isn't this in contradiction to section 1.4's description of ADD? Doesn't this mean you can't send a VTODO or VJOURNAL out in iTIP at all? ... It turns out I need to interpret the tables of constraints in a narrower context. I suggest that the context be part of the title or first row of the table. Section 3.2.2.6 The event flow seems incomplete. It describes how a request can be forwarded to a new CU that wasn't invited, and then the organizer decides whether or not to add the uninvited CU to the attendee list. We're missing the step in between where the organizer learns that the new CU was invited. Is this by receiving a response from the uninvited CU, being cc'ed on the forwarded REQUEST, or receiving a separate copy of the REQUEST or a COUNTER, or any of the above? Same section: phrases like "a new ATTENDEE property is added" are in passive voice, aren't very clear about who is responsible. In this case it should be something like If the "Organizer" decides to add an uninvited CU, the CU of the "Organizer" adds a new "ATTENDEE" property with the uninvited CU with its property parameters set as the "Organizer" deems appropriate. Section 3.2.3: The "REPLY" method may also be used to respond to an unsuccessful "REQUEST" method. Is there something missing here? I read "unsuccessful" as a request that was not received. Hard to know how to reply to a request that was not received. Section 3.3 "FREEBUSY" properties should be sorted such that their values are in ascending order, based on the start time, and then the end time, with the earliest periods first. Is there a reason why the SHOULD isn't capitalized? Is there a reason why it's not a MUST? The busy time information within the iCalendar object MAY be grouped into more than one "VFREEBUSY" calendar component. This requirement does not seem consistent with the tables in 3.3.2 or 3.3.3, where the "Presence" column says that only one VFREEBUSY component is allowed. If it's only true for PUBLISH, then this statement quoted above should be moved into the section on PUBLISH (3.3.1) or even called out. Section 3.4.2: The originator of a "REQUEST" is the "Organizer" of the to-do. The recipient of a "REQUEST" is the "Calendar User" assigned the to-do. The REQUEST method is also used by the delegator as explained in 3.4.2.3. Maybe we should just add a prefix: "In the most typical case, the originator of a REQUEST is..." Next question in this same text: How do user agents check that they are in fact the Calendar User assigned the to-do, and not just being cc'ed? Section 3.4.4 If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". Shouldn't this be 3.14 error instead of 5.3? Section 3.2.4 for ADD uses a REQUEST-STATUS of 3.14 for the same case. Section 3.4.6 I'm going to suggest a rewrite of these paragraphs -- sent separate mail. Section 3.6, table, row for code 5.0 says: "Request MAY supported" Something must be missing here? Section 3.7.3: Clients are not required to save X-Tokens or use them in replies. It seems curious to have this anti-requirement, where there is no requirement of this sort for ordinary properties. I couldn't find any requirement that standard properties in iCalendar methods must be saved or used in replies. Section 4.2.4: The example in this section claims that the COUNTER requests a change to time and place of the meeting. However, it looks like the LOCATION field has "Green Conference Room" in both the original REQUEST and in the COUNTER. Section 4.2.5 says: It is not required that the "Delegate" include the "Delegator" in their "REPLY" method. However, it is strongly advised since this will inform the "Delegator" whether the "Delegate" plans to attend the meeting. However, Section 4.2.7 says: In this example the "Delegate" declines the meeting request and sets the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" parameter of the "Delegate" set to "DECLINED". This lets the "Delegator" know that the "Delegate" has declined and provides an opportunity to the "Delegator" to either accept the request or delegate it to another CU. These are inconsistent because section 4.2.5 indicates that the Delegate is responsible for letting the "Delegator" know if they've accepted. Section 4.2.7, however, does not say that the Delegate does so (it is silent) but it does say that the "Organizer" sends an update that lets the "Delegator" know if the delegate accepted. Is it the Delegate, the Organizer or both that are responsible for letting the Delegator know the accept status? Section 4.5.5: A reply indicating that "D" completed "D's" part of the assignment. Section 4.5.6 continues the example, however: ATTENDEE;PARTSTAT=IN- PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"? Section 5.1.1: +---------------- +--------------------------------------------------+ | Method | Fallback | +---------------- +--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with Not Supported | | DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | | | otherwise reply with Not Supported | +---------------- +--------------------------------------------------+ In this table, the "Fallback" context is inconsistent. Saying that the fallback if you don't support REQUEST is to send a PUBLISH is an instruction to the sender. However, saying that the fallback if you don't support COUNTER is to reply with Not Supported, is an instruction to the receiver. Isn't there a difference between "Required to be able to send" and "Required to be able to handle on receiving"? Thus, all iTIP clients MUST be able to receive PUBLISH requests but obviously aren't required to send them. COUNTER is not required to be sent or received. REPLY is required to be both sent and handled on receiving. Section 7. IANA Considerations I do not see any existing IANA registry for the iCalendar "METHOD" property values. If there is a registry, please provide the URL to help IANA. They will also need to be instructed to update the reference for these methods from 2446 to 2446bis. if, on the other hand there is no such registry and we are trying to create one, then IANA needs more clear instructions on creating the new registry and what fields it has and how entries are added (IETF consensus, expert assignment, First-come-first-served) --Apple-Mail-1-941977697 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Here's my review of = version -07.  I have no high-level problems except a suggestion for = formatting the constraints tables throughout the document if Cyrus is = willing.

----

Section = 1.4
Says that ADD can be used to add one or more new instances = to an existing VEVENT, VTODO or VJOURNAL.  However, I'm not = entirely clear how an iTIP recipient would get the VTODO or VJOURNAL in = the first place.  PUBLISH includes any type of calendar entry -- = what does "calendar entry" define and include (It's mentioned only once = that I can find in 2445bis)?  Any iCalendar = component?

Section 3
First table says that PUBLISH can = be used for VEVENT, VTODO, VJOURNAL and VFREEBUSY, but that REQUEST can = be used for all except VJOURNAL.  This doesn't appear consistent = with the text in Section 1.4 which implies that REQUEST can schedule any = calendar entry.  Maybe we're back to the missing definition of = "calendar entry".

Section 3.2
Main table says that the = PUBLISH method constraints include 0 VTODO or VJOURNAL components. =  In section 3.2.2,  REQUEST also has 0 , and in section 3.2.4, = ADD has 0 VTODOs or VJOURNALs.  Isn't this in contradiction to = section 1.4's description of ADD?  Doesn't this mean you can't send = a VTODO or VJOURNAL out in iTIP at all?  ... It turns out I need to = interpret the tables of constraints in a narrower context.  I = suggest that the context be part of the title or first row of the table. =  

Section 3.2.2.6 
The event flow = seems incomplete.  It describes how a request can be forwarded to a = new CU that wasn't invited, and then the organizer decides whether or = not to add the uninvited CU to the attendee list.  We're missing = the step in between where the organizer learns that the new CU was = invited. Is this by receiving a response from the uninvited CU, being = cc'ed on the forwarded REQUEST, or receiving a separate copy of the = REQUEST or a COUNTER, or any of the above?

Same section: phrases = like "a new ATTENDEE property is added" are in passive voice, aren't = very clear about who is responsible.  In this case it should be = something like
If the "Organizer" decides to add an uninvited CU, the = CU
= of the "Organizer" adds a new "ATTENDEE" property with
the = uninvited CU with its property parameters set as the
= "Organizer" deems appropriate.
Section = 3.2.3:
   The "REPLY" method may also = be used to respond to an unsuccessful
   "REQUEST" = method.  

Is there something missing here? =  I read "unsuccessful" as a request that was not received. =  Hard to know how to reply to a request that was not received. =  

Section 3.3
   ascending order, based on the = start time, and then the end time, with
   the earliest = periods first.  

Is there a reason why the SHOULD = isn't capitalized?  Is there a reason why it's not a = MUST? 

   The busy time = information within the iCalendar object MAY be grouped

This requirement does not seem = consistent with the tables in 3.3.2 or 3.3.3, where the "Presence" = column says that only one VFREEBUSY component is allowed.  If it's = only true for PUBLISH, then this statement quoted above should be moved = into the section on PUBLISH (3.3.1) or even called out.
Section 3.4.2:
   The = originator of a "REQUEST" is the "Organizer" of the to-do.  = The
   recipient of a "REQUEST" is the = "Calendar User" assigned the to-do.

The REQUEST = method is also used by the delegator as explained in 3.4.2.3. =  Maybe we should just add a prefix:  "In the most typical = case, the originator of a REQUEST = is..." 

Next question in this same text: =  How do user agents check that they are in fact the Calendar User = assigned the to-do, and not just being cc'ed? =  

Section = 3.4.4

If an "Attendee" implementation = does not support the "ADD"
   method it should = respond with a "REQUEST-STATUS" value of 5.3 and ask

Shouldn't this be 3.14 = error instead of 5.3?  Section 3.2.4 for ADD uses a REQUEST-STATUS = of 3.14 for the same case.

Section = 3.4.6 

I'm going to suggest a rewrite of = these paragraphs -- sent separate mail.

"Request MAY = supported"

Something must be missing = here?

Section 3.7.3:
= Clients are not required to save X-Tokens or use them

It seems curious to have = this anti-requirement, where there is no requirement of this sort for = ordinary properties.  I couldn't find any requirement that standard = properties in iCalendar methods must be saved or used in replies. =  

Section 4.2.4: The example in = this section claims that the COUNTER requests a change to time = and place of the meeting.  However, it looks like = the LOCATION field has "Green Conference Room" in both the original = REQUEST and in the COUNTER.



  It is not required = that the "Delegate" include the "Delegator" in
   will inform the "Delegator" = whether the "Delegate" plans to attend
   the meeting. =  

However, Section 4.2.7 = says:

   In this example = the "Delegate" declines the meeting request and sets
   "Organizer" SHOULD resend the = "REQUEST" to "C" with the "PARTSTAT"
   parameter of the = "Delegate" set to "DECLINED".  This lets the
   opportunity to the "Delegator" to = either accept the request or
   delegate it to = another CU.


These are = inconsistent because section 4.2.5 indicates that the Delegate is = responsible for letting the "Delegator" know if they've accepted. =  Section 4.2.7, however, does not say that the Delegate does so (it = is silent) but it does say that the "Organizer" sends an update =  that lets the "Delegator" know if the delegate accepted.   Is = it the Delegate, the Organizer or both that are responsible for letting = the Delegator know the accept = status?


Section = 4.5.5:

   A reply = indicating that "D" completed "D's" part of the assignment.
Section 4.5.6 continues the example, = however:

   =   ATTENDEE;PARTSTAT=3DIN-PROCESS;CUTYPE=3DINDIVIDUAL:mailto:d@example.com
Shouldn't "D"'s PARTSTAT be COMPLETED rather = than "IN-PROCESS"?


Section 5.1.1:
   | Method       =   | Fallback               =                     =       |
   = +----------------+--------------------------------------------------+
   | DECLINECOUNTER | Required if = EVENT-COUNTER is implemented;        |
   = +----------------+--------------------------------------------------+

In this table, the "Fallback" context is = inconsistent.  Saying that the fallback if you don't support = REQUEST is to send a PUBLISH is an instruction to the sender. =  However, saying that the fallback if you don't support COUNTER is = to reply with Not Supported, is an instruction to the = receiver.

Isn't there a difference between = "Required to be able to send" and "Required to be able to handle on = receiving"?   Thus, all iTIP clients MUST be able to receive = PUBLISH requests but obviously aren't required to send them.   = COUNTER is not required to be sent or received.  REPLY is required = to be both sent and handled on = receiving. 


Section 7. =  IANA Considerations

I do not see any = existing IANA registry for the iCalendar "METHOD" property values. =  If there is a registry, please provide the URL to help IANA. =  They will also need to be instructed to update the reference for = these methods from 2446 to 2446bis.

if, on the = other hand there is no such registry and we are trying to create one, = then IANA needs more clear instructions on creating the new registry and = what fields it has and how entries are added (IETF consensus, expert = assignment, = First-come-first-served)


= --Apple-Mail-1-941977697-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7681E80D75 for ; Tue, 26 Aug 2008 07:02:37 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5DD9E14225C for ; Tue, 26 Aug 2008 07:02:36 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-50 required=4 tests=[AWL=0.130, BAYES_00=-2.599, RDNS_NONE=0.1, SPF_FAIL=0.693] 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 eDTQlMYsPw4A; Tue, 26 Aug 2008 07:02:25 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5139E14225E; Tue, 26 Aug 2008 07:02:23 -0700 (PDT) Message-Id: From: Lisa Dusseault To: ietf-calsify list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 07:02:23 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] Proposed new text for 3.4.6 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2008 14:02:37 -0000 I was looking at the first few paragraphs of 3.4.6 and I couldn't quite figure out how the sending of a REFRESH, by the Organizer or an Attendee, combined with specifying a RECURRENCE-ID or not, and what the appropriate replies were for all cases. Here's proposed new text. ------------ The "REFRESH" method in a "VTODO" calendar component is used either by "Attendees" or by the "Organizer" of an existing "VTODO" calendar component. When an "Attendee" sends a "REFRESH" method, it's to request an updated description of the "VTODO" from the "Organizer". When an "Organizer" sends a "REFRESH" method, it's to request updated status from one or more "Attendees". The "REFRESH" method MUST specify the "UID" property corresponding to the "VTODO" calendar component needing update. It MAY specify the "RECURRENCE-ID" property also, to identify a specific instance. Appropriate success responses to a "REFRESH" method: - If an attendee sends the "REFRESH" method with a UID but not a RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and the entire "VTODO" to bring the attendee up to date. - If an attendee sends the "REFRESH" method and it identifies a RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and the "VTODO" instance. - If an "Organizer" sends the "REFRESH" method with a UID but not a RECURRENCE-ID, each recipient attempts to identify themselves in the "Attendee" list (possibly in several "Attendee" lists if there are exception instances), and checks their "PARTSTAT" to see if any update on their participation status is required. If it is, they respond with a REPLY that includes each new status. - If an "Organizer" sends the "REFRESH" method and it identifies a RECURRENCE-ID, then the recipient attempts to identify itself in the "Attendee" list for that instance, and if their PARTSTAT needs refreshing, responds with a REPLY including only the instance in question. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 01E7C80D47 for ; Fri, 22 Aug 2008 10:20:53 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F025414223C for ; Fri, 22 Aug 2008 10:20:51 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.4 X-Spam-Level: X-Spam-Status: No, score=-4.4 tagged_above=-50 required=4 tests=[AWL=-1.800, BAYES_00=-2.599, SPF_PASS=-0.001] 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 8YEjPa+PoOEt for ; Fri, 22 Aug 2008 10:20:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id D4D62142234 for ; Fri, 22 Aug 2008 10:20:38 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 17:20:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 22 Aug 2008 19:20:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8KXdC/ZC8WSNhQaPglGb7xDDGAWZJUjDxjFcvua xujMoLzmp/hVbW Message-ID: <48AEF55B.2090400@gmx.de> Date: Fri, 22 Aug 2008 19:20:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> In-Reply-To: <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:20:53 -0000 Helge Hess wrote: > On 22.08.2008, at 18:51, Julian Reschke wrote: >> The default is that the browser stores the content into a local >> temporary file, and then invokes the application with the file name. >> >> I do recall that MS IE has a way to actually pass the URL instead of >> the document, but when I researched this a long time ago, I couldn't >> figure out how that works. > > I couldn't find it in a quick search either, but I'm pretty sure its > supposed to work. But then maybe not :-): > > http://bitworking.org/news/Atom_Auto_Sub_How_To Yes. That one inspired me to do RFC 4709. > OK. Another way would be to deliver a different content-type which > contains the iCal URL. Something like this: > --snip-- > Content-type: application/x-url-to-open > > http://site/file.ics > --snap-- > Could be a generic 'URL reference' MIME type, or something text/calendar > specific. It would need to be specific, otherwise you can't dispatch to the right application. See RFC 4709 :-). >>> Well, maybe the hack is worth it. But in this case I would prefer a >>> webcal:// scheme over an iCal embedded URL, to preserve the layering >>> between content and transport. >> >> : >> >> "Good practice: Reuse URI schemes >> >> A specification SHOULD reuse an existing URI scheme (rather than >> create a new one) when it provides the desired properties of >> identifiers and their relation to resources." > > Its also good practice not to mix transport with content :-) > > OK, what about my special-reference entity suggestion then? That would work as well, and this is what I've been using for launching WebDAV clients (successfully). The "embed-the-source" approach works as well if content is being transferred anyway, and this is what Atom (RFC4287) uses. > PS: hey! you are supposed to do CalDAV anyways! and download of full > vcals via HTTP ;-) But, as far as I can tell, this has the same problem. How do you send a URL to a CalDAV calendar in an email? How does a Web server implement the "subscribe this with Caldav" functionality? As a matter of fact, my original proposal would work in that case as well. A CalDAV-aware client could do OPTIONS on the URI first, and check for CalDAV support, and then do "the right thing". BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2EE5980D47 for ; Fri, 22 Aug 2008 10:14:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 292F514223C for ; Fri, 22 Aug 2008 10:14:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-50 required=4 tests=[AWL=-1.813, BAYES_00=-2.599, SPF_PASS=-0.001] 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 kbOkbbmIXOha for ; Fri, 22 Aug 2008 10:14:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 2804E142234 for ; Fri, 22 Aug 2008 10:14:20 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 17:14:20 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp048) with SMTP; 22 Aug 2008 19:14:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18TyHZVu+0ToGdhRkThx/5xW7xWLBkD9XC4pqbi4A zyauIRoojqYokX Message-ID: <48AEF3E0.9040807@gmx.de> Date: Fri, 22 Aug 2008 19:14:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@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-FuHaFi: 0.66 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:14:30 -0000 Cyrus Daboo wrote: >> Well, it would only happen once: you GET the calendar resource with your >> browser, which passes it to the calendar application. That application >> can then discover the "self" link, and offer to subscribe to the >> calendar. From there on, you would always use the calendar application to >> access the calendar. > > By this argument then, any data handed off from a browser to another > application should include the original URL embedded in it because the > other app may want to re-fetch. So I think this is more an issue for the > OS/Application URL hand-off process. The URL where the data originally > came from ought to be attached to the file, or data stream, as meta-data. I agree that it would be totally cool if it worked that way. But as far as I can tell, it doesn't. I'd love to learn how to configure IE/FF/Safari to do this. Maybe this is something for the (gasp) HTML5 WG to consider? BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9F5E980D42; Fri, 22 Aug 2008 10:10:21 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 99C3014223D; Fri, 22 Aug 2008 10:10:20 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-50 required=4 tests=[AWL=-0.007, BAYES_00=-2.599] 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 2Rskeo0lqTos; Fri, 22 Aug 2008 10:10:13 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3098D142234; Fri, 22 Aug 2008 10:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AEA3EBC4CC8; Fri, 22 Aug 2008 13:10:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQHt9WMlGKcz; Fri, 22 Aug 2008 13:10:13 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id BDC66BC4CC1; Fri, 22 Aug 2008 13:10:12 -0400 (EDT) Date: Fri, 22 Aug 2008 13:10:10 -0400 From: Cyrus Daboo To: Lisa Dusseault , ietf-calsify list Subject: Re: [Ietf-calsify] ADD is really optional --? Message-ID: <4E67FDD7B6161A9C919B2932@caldav.corp.apple.com> In-Reply-To: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> References: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:10:21 -0000 Hi Lisa, --On August 21, 2008 4:29:16 PM -0700 Lisa Dusseault wrote: > I'm doing AD Review of iTIP and the way I read specs like this by default > is that if there are a bunch of methods that can be sent around between > agents, all of them must be supported. > > However, for the ADD method, iTIP specifies a way for a receiving client > not to really support it -- return a REQUEST-STATUS of 3.14 followed by a > REFRESH request. Well that procedure can also be used for CANCEL and partial REQUESTs (ones that send only overridden instances). So this is not specific to ADD. > Is ADD routinely supported by iTIP implementations or is this exception > used in practice? I believe there are some clients out there that let users add instances to a recurring set, and I would expect them to use ADD. But I have no firm evidence of -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A757D80D42 for ; Fri, 22 Aug 2008 10:08:17 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A16C614223C for ; Fri, 22 Aug 2008 10:08:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 0w58chY8XRSl for ; Fri, 22 Aug 2008 10:08:05 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E539142234 for ; Fri, 22 Aug 2008 10:08:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5E24F10F1595 for ; Fri, 22 Aug 2008 19:07:59 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id 2793310F1EE1 for ; Fri, 22 Aug 2008 19:07:44 +0200 (CEST) Message-Id: <71132ABE-0C09-4C41-8D19-1DE82006F9AF@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AEEE97.205@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 19:07:38 +0200 References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:08:17 -0000 On 22.08.2008, at 18:51, Julian Reschke wrote: > The default is that the browser stores the content into a local > temporary file, and then invokes the application with the file name. > > I do recall that MS IE has a way to actually pass the URL instead of > the document, but when I researched this a long time ago, I couldn't > figure out how that works. I couldn't find it in a quick search either, but I'm pretty sure its supposed to work. But then maybe not :-): http://bitworking.org/news/Atom_Auto_Sub_How_To OK. Another way would be to deliver a different content-type which contains the iCal URL. Something like this: --snip-- Content-type: application/x-url-to-open http://site/file.ics --snap-- Could be a generic 'URL reference' MIME type, or something text/ calendar specific. >> Well, maybe the hack is worth it. But in this case I would prefer a webcal:// >> scheme over an iCal embedded URL, to preserve the layering between >> content and transport. > > : > > "Good practice: Reuse URI schemes > > A specification SHOULD reuse an existing URI scheme (rather than > create a new one) when it provides the desired properties of > identifiers and their relation to resources." Its also good practice not to mix transport with content :-) OK, what about my special-reference entity suggestion then? Thanks, Helge PS: hey! you are supposed to do CalDAV anyways! and download of full vcals via HTTP ;-) -- Helge Hess http://helgehess.eu/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F3E280C3A for ; Fri, 22 Aug 2008 10:03:18 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 29AC7142233 for ; Fri, 22 Aug 2008 10:03:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-50 required=4 tests=[AWL=-0.007, BAYES_00=-2.599] 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 Z3aJ7bjn2Tbd for ; Fri, 22 Aug 2008 10:03:09 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9294214222B for ; Fri, 22 Aug 2008 10:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CF297BC4B97; Fri, 22 Aug 2008 13:03:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6wXLya635oC; Fri, 22 Aug 2008 13:03:09 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 6F43CBC4B90; Fri, 22 Aug 2008 13:03:08 -0400 (EDT) Date: Fri, 22 Aug 2008 13:03:05 -0400 From: Cyrus Daboo To: Julian Reschke , Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Message-ID: In-Reply-To: <48AEEE97.205@gmx.de> References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> <48AEEE97.205@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:03:18 -0000 Hi Julian, --On August 22, 2008 6:51:35 PM +0200 Julian Reschke wrote: >> Yes, but in what case would you download a calendar via URL and then use >> the same URL again to re-download the same entity. That just doesn't >> make a lot sense? :-) > > Well, it would only happen once: you GET the calendar resource with your > browser, which passes it to the calendar application. That application > can then discover the "self" link, and offer to subscribe to the > calendar. From there on, you would always use the calendar application to > access the calendar. By this argument then, any data handed off from a browser to another application should include the original URL embedded in it because the other app may want to re-fetch. So I think this is more an issue for the OS/Application URL hand-off process. The URL where the data originally came from ought to be attached to the file, or data stream, as meta-data. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A987B80B48 for ; Fri, 22 Aug 2008 09:51:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A41F1142234 for ; Fri, 22 Aug 2008 09:51:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-50 required=4 tests=[AWL=-1.827, BAYES_00=-2.599, SPF_PASS=-0.001] 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 TBo7+m0TZ2Xu for ; Fri, 22 Aug 2008 09:51:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 43D31142233 for ; Fri, 22 Aug 2008 09:51:47 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 16:51:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 22 Aug 2008 18:51:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Lt9YnadgLB3ZdSRSHQMqYKWxE1hnFW6stLwCLpP z3bhG8qrRpotD0 Message-ID: <48AEEE97.205@gmx.de> Date: Fri, 22 Aug 2008 18:51:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> In-Reply-To: <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 16:51:55 -0000 Helge Hess wrote: > On 22.08.2008, at 10:46, Julian Reschke wrote: >> No, not a feed. Just the current state of the calendar. Exactly what >> you get when you subscribe (for instance) to a Google Calendar in >> Thunderbird, using "http" (not caldav). > > OK. > >>> >> But it's the only way of opening the calendar in an application other >> than the browser *and* giving that application the original URL (at >> least in the operating systems I'm aware of). > > I still don't get it. Can't you configure the browser to open your > calendaring application for the text/calendar content type? The browser > can invoke the application with the URL? > (I'm pretty sure that Mozilla allows that, and IE definitely does open > by URL when you invoke a Word document for example, so it should also > work there, somehow) The default is that the browser stores the content into a local temporary file, and then invokes the application with the file name. I do recall that MS IE has a way to actually pass the URL instead of the document, but when I researched this a long time ago, I couldn't figure out how that works. So let me know if you can convince one of these UAs to pass the URL, that would be an interesting outcome of this discussion as well. >> It addresses exactly this problem. If the iCalendar object doesn't >> contain the URL it came from, the calendar application lacks that >> essential piece of information. > > Yes, but in what case would you download a calendar via URL and then use > the same URL again to re-download the same entity. That just doesn't > make a lot sense? :-) Well, it would only happen once: you GET the calendar resource with your browser, which passes it to the calendar application. That application can then discover the "self" link, and offer to subscribe to the calendar. From there on, you would always use the calendar application to access the calendar. > Its really just a hack around an improper configuration of the URL/app > activation system. It's a workaround for a missing feature in current UAs. > Well, maybe the hack is worth it. But in this case I would prefer a > webcal:// scheme over an iCal embedded URL, to preserve the layering > between content and transport. : "Good practice: Reuse URI schemes A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources." BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 633AC7F4DD for ; Fri, 22 Aug 2008 09:31:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C77B1421FC for ; Fri, 22 Aug 2008 09:31:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 ibxJk+M2zsDr for ; Fri, 22 Aug 2008 09:30:50 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1772F14222B for ; Fri, 22 Aug 2008 09:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4D71010F2CA9 for ; Fri, 22 Aug 2008 18:30:46 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id B05C610F2CD2 for ; Fri, 22 Aug 2008 18:27:52 +0200 (CEST) Message-Id: <7978065A-608C-4F68-A53D-231B6EE4708D@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AE7CF4.1070109@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 18:27:47 +0200 References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> <48AE7CF4.1070109@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 16:31:01 -0000 On 22.08.2008, at 10:46, Julian Reschke wrote: > No, not a feed. Just the current state of the calendar. Exactly what > you get when you subscribe (for instance) to a Google Calendar in > Thunderbird, using "http" (not caldav). OK. >> > But it's the only way of opening the calendar in an application > other than the browser *and* giving that application the original > URL (at least in the operating systems I'm aware of). I still don't get it. Can't you configure the browser to open your calendaring application for the text/calendar content type? The browser can invoke the application with the URL? (I'm pretty sure that Mozilla allows that, and IE definitely does open by URL when you invoke a Word document for example, so it should also work there, somehow) > It addresses exactly this problem. If the iCalendar object doesn't > contain the URL it came from, the calendar application lacks that > essential piece of information. Yes, but in what case would you download a calendar via URL and then use the same URL again to re-download the same entity. That just doesn't make a lot sense? :-) Its really just a hack around an improper configuration of the URL/app activation system. Well, maybe the hack is worth it. But in this case I would prefer a webcal:// scheme over an iCal embedded URL, to preserve the layering between content and transport. Thanks, Helge -- Helge Hess http://helgehess.eu/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 59E0580D8E for ; Fri, 22 Aug 2008 05:22:14 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5461E14222C for ; Fri, 22 Aug 2008 05:22:13 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.441 X-Spam-Level: X-Spam-Status: No, score=-4.441 tagged_above=-50 required=4 tests=[AWL=-1.841, BAYES_00=-2.599, SPF_PASS=-0.001] 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 EBCEWoAeJ8rM for ; Fri, 22 Aug 2008 05:22:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 434A214222A for ; Fri, 22 Aug 2008 05:22:05 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 12:22:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp052) with SMTP; 22 Aug 2008 14:22:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+TDyhy8DuTe4k3X+irCw4A6UusOmZKAV+QDryIA5 mUiUeLbVugKOzy Message-ID: <48AEAF62.9070806@gmx.de> Date: Fri, 22 Aug 2008 14:21:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) References: <20080822120638.27477gmx1@mx007.gmx.net> In-Reply-To: <20080822120638.27477gmx1@mx007.gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 12:22:14 -0000 Tim Hare wrote: > If you want a subscription experience, you could embed the URL of the .ics > file in an Atom feed, couldn't you, and take advantage of the "self" > property for the feed? Not sure how that would help - I want to subscribe to the calendar, not a feed, after all. > ... BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0556880D3F for ; Fri, 22 Aug 2008 05:06:49 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F3FFC142233 for ; Fri, 22 Aug 2008 05:06:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-50 required=4 tests=[AWL=0.787, BAYES_00=-2.599, SPF_PASS=-0.001] 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 Rpa0z8r5hwF3 for ; Fri, 22 Aug 2008 05:06:36 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by laweleka.osafoundation.org (Postfix) with ESMTP id 26E5A14222A for ; Fri, 22 Aug 2008 05:06:35 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 5PA61a00916AWCUA9Q6cXV; Fri, 22 Aug 2008 12:06:36 +0000 Received: from THare ([71.203.105.66]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 5Q6V1a00F1RyUCv8SQ6bBW; Fri, 22 Aug 2008 12:06:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=4lsWnCqjEnIA:10 a=7FhwB9M-7j8A:10 a=PFsjAnyDAAAA:8 a=VkrFwHKdAb8ac-Q_ckYA:9 a=SJqFrJ2rlxo3mFn7wC4A:7 a=xuLO5RUyktVzUXU5vGjL8u3HzaUA:4 a=nMy-LcBKloIA:10 a=YewFc9KQ5U8A:10 a=f3vTY2RCmVgA:10 From: "Tim Hare" To: "'Julian Reschke'" , "'Helge Hess'" Subject: RE: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) Date: Fri, 22 Aug 2008 08:06:31 -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: <48AE7CF4.1070109@gmx.de> Thread-Index: AckEM6vccdqhrG2fR4GKWLRABci2BQAGywAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Message-Id: <20080822120636.26E5A14222A@laweleka.osafoundation.org> Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 12:06:49 -0000 If you want a subscription experience, you could embed the URL of the .ics file in an Atom feed, couldn't you, and take advantage of the "self" property for the feed? As an aside, there's a TC-XML at Calconnect.org which is discussing XML representation of iCalendar; this sort of thing might be of interest to them. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Julian Reschke Sent: Friday, August 22, 2008 4:47 AM To: Helge Hess Cc: IETF-iCalendar Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal related to 2445bis) Helge Hess wrote: > Julian, > > I'm not sure what you mean by 'subscribe' in the context. Do you want > some kind of feed which is based on the iCal format? That is, > subsequent GETs on that feed URL only return changed items? No, not a feed. Just the current state of the calendar. Exactly what you get when you subscribe (for instance) to a Google Calendar in Thunderbird, using "http" (not caldav). > Subscribe in the iCal-over-HTTP context is just using that URL, cache > it and do proper if-none-match: etag requests to keep it up to date. > Thats no different to the subscription of regular RSS feeds. > > I don't think that adding such URLs to the content format is good. It > blurs the boundaries between protocol (HTTP) and the payload (iCal). But it's the only way of opening the calendar in an application other than the browser *and* giving that application the original URL (at least in the operating systems I'm aware of). > Greets, > Helge > > PS: I never understood why Apple needed the 'webcal' URI scheme. I > guess it was just a quick hack. It was probably easier to activate an > OSX application by URL than by the content-type of the URL entity. It addresses exactly this problem. If the iCalendar object doesn't contain the URL it came from, the calendar application lacks that essential piece of information. BR, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2BCF880D79 for ; Fri, 22 Aug 2008 01:47:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2801414222B for ; Fri, 22 Aug 2008 01:47:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.542 X-Spam-Level: X-Spam-Status: No, score=-4.542 tagged_above=-50 required=4 tests=[AWL=-1.942, BAYES_00=-2.599, SPF_PASS=-0.001] 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 1eupIICSZvcm for ; Fri, 22 Aug 2008 01:46:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id E28971421FB for ; Fri, 22 Aug 2008 01:46:55 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 08:46:55 -0000 Received: from p508FFFBC.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.255.188] by mail.gmx.net (mp045) with SMTP; 22 Aug 2008 10:46:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+w8rcJKsywtrQZZWt4BMDYOF6x+Ws1l9nJDz3TWl MC1E14ZZBAaOg8 Message-ID: <48AE7CF4.1070109@gmx.de> Date: Fri, 22 Aug 2008 10:46:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) References: <48AE74C0.3090809@gmx.de> <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> In-Reply-To: <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 08:47:05 -0000 Helge Hess wrote: > Julian, > > I'm not sure what you mean by 'subscribe' in the context. Do you want > some kind of feed which is based on the iCal format? That is, subsequent > GETs on that feed URL only return changed items? No, not a feed. Just the current state of the calendar. Exactly what you get when you subscribe (for instance) to a Google Calendar in Thunderbird, using "http" (not caldav). > Subscribe in the iCal-over-HTTP context is just using that URL, cache it > and do proper if-none-match: etag requests to keep it up to date. Thats > no different to the subscription of regular RSS feeds. > > I don't think that adding such URLs to the content format is good. It > blurs the boundaries between protocol (HTTP) and the payload (iCal). But it's the only way of opening the calendar in an application other than the browser *and* giving that application the original URL (at least in the operating systems I'm aware of). > Greets, > Helge > > PS: I never understood why Apple needed the 'webcal' URI scheme. I guess > it was just a quick hack. It was probably easier to activate an OSX > application by URL than by the content-type of the URL entity. It addresses exactly this problem. If the iCalendar object doesn't contain the URL it came from, the calendar application lacks that essential piece of information. BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 68B7580D95 for ; Fri, 22 Aug 2008 01:25:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 649FD14222B for ; Fri, 22 Aug 2008 01:25:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 S3M3QSYFRvp3 for ; Fri, 22 Aug 2008 01:25:17 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 63A091421FB for ; Fri, 22 Aug 2008 01:25:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BE7D010F0985 for ; Fri, 22 Aug 2008 10:25:18 +0200 (CEST) Received: from [192.168.0.111] (p4FD5F9E6.dip.t-dialin.net [79.213.249.230]) by mail.mdlink.net (Postfix) with ESMTP id 0150910F0622 for ; Fri, 22 Aug 2008 10:24:47 +0200 (CEST) Message-Id: <3AEE371F-FA20-463A-9342-B2DF97797626@opengroupware.org> From: Helge Hess To: IETF-iCalendar In-Reply-To: <48AE74C0.3090809@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) Date: Fri, 22 Aug 2008 10:24:43 +0200 References: <48AE74C0.3090809@gmx.de> X-Mailer: Apple Mail (2.928.1) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 08:25:30 -0000 Julian, I'm not sure what you mean by 'subscribe' in the context. Do you want some kind of feed which is based on the iCal format? That is, subsequent GETs on that feed URL only return changed items? Subscribe in the iCal-over-HTTP context is just using that URL, cache it and do proper if-none-match: etag requests to keep it up to date. Thats no different to the subscription of regular RSS feeds. I don't think that adding such URLs to the content format is good. It blurs the boundaries between protocol (HTTP) and the payload (iCal). Greets, Helge PS: I never understood why Apple needed the 'webcal' URI scheme. I guess it was just a quick hack. It was probably easier to activate an OSX application by URL than by the content-type of the URL entity. On 22.08.2008, at 10:11, Julian Reschke wrote: > I've got a quick question about the iCalendar format, or actually an > idea. > > If I serve an iCalendar resource through HTTP, what I really want is > to allow the client not only to read it (display it in a calendar > application), but also to *subscribe* to it, for which I obviously > need the URI. > > Apple, years ago, "solved" this (and potentially some other use > cases) with their custom "webcal" URI scheme. (I note that this URI > scheme hasn't been registered with IANA.) > > The Atom WG was smarter, by allowing the format to carry a "self" > URI, for subscription (see >). > > Bernard already pointed me to the URL property ( >), but what I'm looking for is a Calendar property, not a Component > property (I think). > > Is something like that possible in iCalendar? If not, could/should > it be added? (Separate document?) -- Helge Hess http://helgehess.eu/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E7D380D2E for ; Fri, 22 Aug 2008 01:12:08 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2768514222B for ; Fri, 22 Aug 2008 01:12:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-50 required=4 tests=[AWL=-1.941, BAYES_00=-2.599, SPF_PASS=-0.001] 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 TB6RaI7bpcQO for ; Fri, 22 Aug 2008 01:11:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id DFC961421FB for ; Fri, 22 Aug 2008 01:11:54 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2008 08:11:53 -0000 Received: from p508FFFBC.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.255.188] by mail.gmx.net (mp065) with SMTP; 22 Aug 2008 10:11:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Fcjtl/FVFrtr+YUccP4VPX0ivStdcFbkBiNdThT F6QfDIQ4DVIW6X Message-ID: <48AE74C0.3090809@gmx.de> Date: Fri, 22 Aug 2008 10:11:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 08:12:08 -0000 Hi, I've got a quick question about the iCalendar format, or actually an idea. If I serve an iCalendar resource through HTTP, what I really want is to allow the client not only to read it (display it in a calendar application), but also to *subscribe* to it, for which I obviously need the URI. Apple, years ago, "solved" this (and potentially some other use cases) with their custom "webcal" URI scheme. (I note that this URI scheme hasn't been registered with IANA.) The Atom WG was smarter, by allowing the format to carry a "self" URI, for subscription (see ). Bernard already pointed me to the URL property (), but what I'm looking for is a Calendar property, not a Component property (I think). Is something like that possible in iCalendar? If not, could/should it be added? (Separate document?) BR, Julian Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 39C0780DBA for ; Thu, 21 Aug 2008 16:29:23 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 35826142247 for ; Thu, 21 Aug 2008 16:29:22 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-50 required=4 tests=[AWL=0.038, BAYES_00=-2.599, RDNS_NONE=0.1, SPF_FAIL=0.693] 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 0iPx-OB1JDhS for ; Thu, 21 Aug 2008 16:29:16 -0700 (PDT) Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 06862142224 for ; Thu, 21 Aug 2008 16:29:16 -0700 (PDT) Message-Id: <277C9E7A-0536-457D-83DB-6BA43D470CB6@osafoundation.org> From: Lisa Dusseault To: ietf-calsify list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 21 Aug 2008 16:29:16 -0700 X-Mailer: Apple Mail (2.928.1) Subject: [Ietf-calsify] ADD is really optional --? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2008 23:29:23 -0000 I'm doing AD Review of iTIP and the way I read specs like this by default is that if there are a bunch of methods that can be sent around between agents, all of them must be supported. However, for the ADD method, iTIP specifies a way for a receiving client not to really support it -- return a REQUEST-STATUS of 3.14 followed by a REFRESH request. Is ADD routinely supported by iTIP implementations or is this exception used in practice? Lisa Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 18FCB7F522 for ; Mon, 4 Aug 2008 23:21:32 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 606AF142206 for ; Mon, 4 Aug 2008 23:21:31 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-50 required=4 tests=[AWL=0.908, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DayMhteUzKZq for ; Mon, 4 Aug 2008 23:21:20 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 61E211421FF for ; Mon, 4 Aug 2008 23:21:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m756Kv1E021749 for ; Tue, 5 Aug 2008 09:21:17 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 09:20:59 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 09:20:56 +0300 Received: from [172.21.41.245] (esdhcp041245.research.nokia.com [172.21.41.245]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m756KsH5028437 for ; Tue, 5 Aug 2008 09:20:54 +0300 From: Aki Niemi To: "ietf-calsify@osafoundation.org" Content-Type: text/plain Organization: Nokia Devices R&D Date: Tue, 05 Aug 2008 09:20:52 +0300 Message-Id: <1217917252.7851.2.camel@little.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2008 06:20:56.0158 (UTC) FILETIME=[6B6F6FE0:01C8F6C3] X-Nokia-AV: Clean Subject: [Ietf-calsify] FYI: Nomcom 2008-9 Call for Volunteers X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 06:21:32 -0000 If you are qualified (have attended 3 out of past 5 meetings), please consider volunteering for the Nomcom: https://datatracker.ietf.org/ann/nomcom/1617/ Cheers, Aki -- Aki Niemi Maemo Software, Nokia Devices R&D