From ietf-calsify-bounces@osafoundation.org Wed Jan 13 05:57:24 2010 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 93E183A69E8 for ; Wed, 13 Jan 2010 05:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 QEFG+vDBMa3u for ; Wed, 13 Jan 2010 05:57:22 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 9F1723A69E7 for ; Wed, 13 Jan 2010 05:57:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 699F077D70B; Wed, 13 Jan 2010 05:57:06 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzvD4V2YYv9a; Wed, 13 Jan 2010 05:57:06 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 1532B77D714; Wed, 13 Jan 2010 05:55:07 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id BC70F77D714 for ; Wed, 13 Jan 2010 05:52:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdfjVcPrD-nS for ; Wed, 13 Jan 2010 05:52:10 -0800 (PST) Received: from mail.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4E64277D70B for ; Wed, 13 Jan 2010 05:51:47 -0800 (PST) Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by mail.fam.tuwien.ac.at (8.14.3/8.14.3/Debian-5) with ESMTP id o0DDpUV7008444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Jan 2010 14:51:35 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: "ietf-calsify@osafoundation.org" Date: Wed, 13 Jan 2010 14:52:12 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.4; i686; ; ) MIME-Version: 1.0 Message-Id: <201001131452.12602.reinhold@kainhofer.com> Subject: [ietf-calsify] Indicating a completed to-do??? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi all, Recently the issue came up in kde how a completed to-do is supposed to be indicated. There are three different completion settings defined in rfc 5545: -) STATUS:COMPLETED (as opposed to NEEDS-ACTION) -) COMPLETED:20070707T100000Z -) PERCENT-COMPLETE:100 However, the RFC is quiet which of those is supposed to indicate that a to-do is actually completed... There is, however, an example in section 3.6.2 of a completed to-do: The following is an example of a "VTODO" calendar component that was due before 1:00 P.M. UTC on July 9th, 2007 and was completed on July 7th, 2007 at 10:00 A.M. UTC. BEGIN:VTODO UID:20070514T103211Z-123404@example.com DTSTAMP:20070514T103211Z DTSTART:20070514T110000Z DUE:20070709T130000Z COMPLETED:20070707T100000Z SUMMARY:Submit Revised Internet-Draft PRIORITY:1 STATUS:NEEDS-ACTION END:VTODO Is the STATUS:NEEDS-ACTION really intended or is it an oversight and should rather be STATUS:COMPLETED??? The problem we have is interoperability: Horde creates a VTODO with STATUS:COMPLETED COMPLETED:20100112T125449Z while Korganizer and kontact instead use only the completion percentage: COMPLETED:20100112T124208Z PERCENT-COMPLETE:100 Unfortunately, this totally breaks the exchange of to-dos between horde and kontact, as completed to-dos in one application won't be detected as completed in the other. In the RFC I couldn't find anything that says that one of the is "correct" and the other is not... Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Jan 13 10:07:55 2010 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 7B6C33A6860 for ; Wed, 13 Jan 2010 10:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601] 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 d13z6KLlj5NS for ; Wed, 13 Jan 2010 10:07:54 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 6708D3A67AB for ; Wed, 13 Jan 2010 10:07:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 16BE877D718; Wed, 13 Jan 2010 10:07:41 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7DQ99RUxuoB; Wed, 13 Jan 2010 10:07:40 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2199877D714; Wed, 13 Jan 2010 10:05:43 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E5EBC77D71C for ; Wed, 13 Jan 2010 10:02:25 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzqrwNRsxegS for ; Wed, 13 Jan 2010 10:02:14 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by leka.osafoundation.org (Postfix) with ESMTP id 87CC877D71A for ; Wed, 13 Jan 2010 10:01:52 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 8so61419qwh.15 for ; Wed, 13 Jan 2010 10:01:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.32.10 with SMTP id a10mr593424qcd.105.1263405701023; Wed, 13 Jan 2010 10:01:41 -0800 (PST) Date: Wed, 13 Jan 2010 10:01:40 -0800 Message-ID: <6b35e9b91001131001y7a5aafdeu352d5856bb7436ba@mail.gmail.com> From: Calvin So To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Group Event X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1254292451==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============1254292451== Content-Type: multipart/alternative; boundary=0016364eeec00446af047d0f9063 --0016364eeec00446af047d0f9063 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I am not sure if my case is feasible but I am trying to write a backend program that send out message to "A", "B", "C" and "D" and make "A" as the organizer/chair of a group event and the others as the attendees. I have read the "4.2. Group Event Examples" in http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... but it doesn't mention much about what message content should be constructed for message sending to "A" Can somebody shed some light on this? In particular, which parameter (s) should I pay special attention to? Or there is no feasible solution for my case? Thanks! --0016364eeec00446af047d0f9063 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,=A0

I am not sure if my case is feasible but I am trying to write a=A0
backend program that send out me= ssage to "A", "B", "C" and "D" and<= span class=3D"Apple-converted-space">=A0
make "A" as the organizer/chair of a group event and the others a= s the=A0
attendees.=A0

I have read the "4.2. Group Event Examples" in=A0
http://ri-cal.rubyforg= e.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t...=A0
but it doesn't mention much about what message content should be=A0
constructed for message sendin= g to "A"=A0

Can somebody shed some light on this? In particular, which parameter=A0
(s) should I pay special at= tention to? Or there is no feasible= =A0
solution for my case?=A0

Thanks!=A0

 --0016364eeec00446af047d0f9063-- --===============1254292451== 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 --===============1254292451==-- From ietf-calsify-bounces@osafoundation.org Wed Jan 13 10:38:49 2010 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 696383A6A39 for ; Wed, 13 Jan 2010 10:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sKX43AnQcKdE for ; Wed, 13 Jan 2010 10:38:48 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 525CA3A6A1D for ; Wed, 13 Jan 2010 10:38:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 58A7F7841F4; Wed, 13 Jan 2010 10:38:33 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqBFTfLk4efZ; Wed, 13 Jan 2010 10:38:32 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D84137841F0; Wed, 13 Jan 2010 10:36:34 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 3A76A7841F3 for ; Wed, 13 Jan 2010 10:35:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avjBuy9oTeqZ for ; Wed, 13 Jan 2010 10:35:08 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id A6CFB7841EF for ; Wed, 13 Jan 2010 10:34:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A6D3D92A374B; Wed, 13 Jan 2010 13:34:36 -0500 (EST) 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 9IacMZieb1CP; Wed, 13 Jan 2010 13:34:36 -0500 (EST) Received: from [17.244.121.139] (unknown [17.244.121.139]) by daboo.name (Postfix) with ESMTPSA id 8E6C692A3743; Wed, 13 Jan 2010 13:34:35 -0500 (EST) Date: Wed, 13 Jan 2010 10:34:33 -0800 From: Cyrus Daboo To: Calvin So , ietf-calsify@osafoundation.org Message-ID: In-Reply-To: <6b35e9b91001131001y7a5aafdeu352d5856bb7436ba@mail.gmail.com> References: <6b35e9b91001131001y7a5aafdeu352d5856bb7436ba@mail.gmail.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=1158 Subject: Re: [ietf-calsify] Group Event X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org SGkgQ2FsdmluLAoKLS1PbiBKYW51YXJ5IDEzLCAyMDEwIDEwOjAxOjQwIEFNIC0wODAwIENhbHZp biBTbyA8c29jaGlob25nQGdtYWlsLmNvbT4gCndyb3RlOgoKPiBJIGFtIG5vdCBzdXJlIGlmIG15 IGNhc2UgaXMgZmVhc2libGUgYnV0IEkgYW0gdHJ5aW5nIHRvIHdyaXRlIGHCoAo+IGJhY2tlbmQg cHJvZ3JhbSB0aGF0IHNlbmQgb3V0IG1lc3NhZ2UgdG8gIkEiLCAiQiIsICJDIiBhbmQgIkQiIGFu ZMKgCj4gbWFrZSAiQSIgYXMgdGhlIG9yZ2FuaXplci9jaGFpciBvZiBhIGdyb3VwIGV2ZW50IGFu ZCB0aGUgb3RoZXJzIGFzIHRoZcKgCj4gYXR0ZW5kZWVzLsKgCj4KPiBJIGhhdmUgcmVhZCB0aGUg IjQuMi4gR3JvdXAgRXZlbnQgRXhhbXBsZXMiIGluwqAKPiBodHRwOi8vcmktY2FsLnJ1Ynlmb3Jn ZS5vcmcvcmRvYy9kb2NzL2RyYWZ0LWlldGYtY2Fsc2lmeS0yNDQ2YmlzLTA4X3QuLi7CoAo+IGJ1 dCBpdCBkb2Vzbid0IG1lbnRpb24gbXVjaCBhYm91dCB3aGF0IG1lc3NhZ2UgY29udGVudCBzaG91 bGQgYmXCoAo+IGNvbnN0cnVjdGVkIGZvciBtZXNzYWdlIHNlbmRpbmcgdG8gIkEiwqAKPgo+IENh biBzb21lYm9keSBzaGVkIHNvbWUgbGlnaHQgb24gdGhpcz8gSW4gcGFydGljdWxhciwgd2hpY2gg cGFyYW1ldGVywqAKPiAocykgc2hvdWxkIEkgcGF5IHNwZWNpYWwgYXR0ZW50aW9uIHRvPyBPciB0 aGVyZSBpcyBubyBmZWFzaWJsZcKgCj4gc29sdXRpb24gZm9yIG15IGNhc2U/wqAKClN0cmljdGx5 IHNwZWFraW5nIGluIHRoZSBpVElQIG1vZGVsIG1lc3NhZ2VzIGFyZSBhc3N1bWVkIHRvIGJlIG9y aWdpbmF0ZWQgCmJ5IHRoZSBPcmdhbml6ZXIuIEluIHlvdXIgY2FzZSBpdCBsb29rcyBsaWtlIHlv dSB3YW50IHNvbWUgdGhpcmQgcGFydHkgdG8gCm9yaWdpbmF0ZSB0aGUgbWVzc2FnZSBhbmQgbWFr ZSBzdXJlIGl0IGFsc28gZ2V0cyBwdXQgb24gdGhlIE9yZ2FuaXplcidzIApjYWxlbmRhci4gRG9l cyB0aGUgdGhpcmQgcGFydHkgaGF2ZSBhbnkgZGlyZWN0IGFjY2VzcyB0byB0aGUgT3JnYW5pemVy J3MgCmNhbGVuZGFyPyBBcmUgeW91IGV4cGVjdGluZyB0aGUgQXR0ZW5kZWUncyB0byByZXBseSB0 byB0aGUgb3JnYW5pemVyIHdpdGggCnRoZWlyIHBhcnRpY2lwYXRpb24gc3RhdHVzIHVwZGF0ZXM/ CgotLSAKQ3lydXMgRGFib28KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmlldGYtY2Fsc2lmeSBtYWlsaW5nIGxpc3QKaWV0Zi1jYWxzaWZ5QG9zYWZvdW5k YXRpb24ub3JnCmh0dHA6Ly9saXN0cy5vc2Fmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lldGYtY2Fsc2lmeQo= From ietf-calsify-bounces@osafoundation.org Wed Jan 13 13:13:18 2010 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 3E93F3A6857 for ; Wed, 13 Jan 2010 13:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 E4TES3N+wyuf for ; Wed, 13 Jan 2010 13:13:16 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id C09E03A67E5 for ; Wed, 13 Jan 2010 13:13:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0B96A77D714; Wed, 13 Jan 2010 13:13:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciCrsEeyCVZ1; Wed, 13 Jan 2010 13:13:02 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E379477D718; Wed, 13 Jan 2010 13:11:03 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 93ACE77D718 for ; Wed, 13 Jan 2010 13:10:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E6V8GgafdFN for ; Wed, 13 Jan 2010 13:09:33 -0800 (PST) Received: from mail.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id E903577D714 for ; Wed, 13 Jan 2010 13:09:12 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by mail.fam.tuwien.ac.at (8.14.3/8.14.3/Debian-5) with ESMTP id o0DL8wpM032364; Wed, 13 Jan 2010 22:08:58 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org, Calvin So Date: Wed, 13 Jan 2010 22:08:55 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.4; i686; ; ) References: <6b35e9b91001131001y7a5aafdeu352d5856bb7436ba@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <201001132208.55349.reinhold@kainhofer.com> Subject: Re: [ietf-calsify] Group Event X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Am Mittwoch, 13. Januar 2010 19:34:33 schrieb Cyrus Daboo: > Hi Calvin, > > --On January 13, 2010 10:01:40 AM -0800 Calvin So > > wrote: > > I am not sure if my case is feasible but I am trying to write a > > backend program that send out message to "A", "B", "C" and "D" and > > make "A" as the organizer/chair of a group event and the others as the > > attendees. Okay, so basically your programm (who is operating it???) is the organizer. There should be some human contact organizing (i.e. fixing the date, organizing the room, informing the participants about changes, etc.) the event with A,B,C and D. That human contact (email address) should be the ORGANIZER of the event. The fact that A is the CHAIR of the meeting can be indicated by the ROLE parameter of the ATTENDEE: ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com See section 3.2.16 of RFC 5545 All other attendees will either have no ROLE parameter (implicitly, REQ- PARTICIPANT is assumed in that case) or an explicit ROLE parameter: ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot:mailto:hcabot@example.com > > I have read the "4.2. Group Event Examples" in > > http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... > > but it doesn't mention much about what message content should be > > constructed for message sending to "A" You should definitely also read RFC 5545 (the successor to RFC 2445) about ATTENDEE, ORGANIZER and all its parameters. RFC 2446bis builds on RFC5545. > > Can somebody shed some light on this? In particular, which parameter > > (s) should I pay special attention to? Or there is no feasible > > solution for my case? > > Strictly speaking in the iTIP model messages are assumed to be originated > by the Organizer. In your case it looks like you want some third party to > originate the message and make sure it also gets put on the Organizer's > calendar. You are using "organizer" for two different tasks: 1) really organizing the event and 2) chairing the event. > Does the third party have any direct access to the Organizer's > calendar? Are you expecting the Attendee's to reply to the organizer with > their participation status updates? Exactly, this is the issue. if your application simply acts on behalf of the chair/organizer (i.e. can fix dates for him/her, has access to the calendar, etc. like a secretary), the chair or the secretary should also be the ORGANIZER and will receive all replies by the attendees. Otherwise, the chair is simply a "normal" attendee with a special role at the meeting. In that case the ORGANIZER is someone else and the chair is an ATTENDEE with ROLE=CHAIR. Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Jan 14 07:36:36 2010 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 40A993A6782 for ; Thu, 14 Jan 2010 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6] 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 CMW2uDSrZ9i4 for ; Thu, 14 Jan 2010 07:36:34 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 4C7403A63EB for ; Thu, 14 Jan 2010 07:36:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E423F77D714; Thu, 14 Jan 2010 07:36:20 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7oL7Kglo415; Thu, 14 Jan 2010 07:36:20 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9305477D71D; Thu, 14 Jan 2010 07:34:22 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B486877D71D for ; Thu, 14 Jan 2010 07:33:19 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rnQ7G-g5N-7 for ; Thu, 14 Jan 2010 07:33:02 -0800 (PST) Received: from mail.daywesthealthcare.com (mail.ddaysoftware.com [71.36.93.161]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 5D88F77D714 for ; Thu, 14 Jan 2010 07:32:38 -0800 (PST) Received: from [192.168.1.161] ([71.36.93.161]) by mail.daywesthealthcare.com (IceWarp 9.4.2) with ASMTP (SSL) id WQR71804 for ; Thu, 14 Jan 2010 08:29:04 -0700 Message-ID: <4B4F383F.5090008@ddaysoftware.com> Date: Thu, 14 Jan 2010 08:29:03 -0700 From: Doug Day User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Subject: Re: [ietf-calsify] Indicating a completed to-do??? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612761877==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1612761877== Content-Type: multipart/alternative; boundary="------------040408020000050904050004" This is a multi-part message in MIME format. --------------040408020000050904050004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reinhold, Those are some good points, and I'd like to hear other's view on this. My personal interpretation is that the STATUS is the driving field here; both the COMPLETED and PERCENT-COMPLETE are there for informational purposes when determining if the VTODO is complete. However, there is a kink with this philosophy: 1. VTODO items can recur. 2. The only solution I can see for tracking completed status is a combination of the STATUS property and the COMPLETED property. If the STATUS field is set to COMPLETED, but the VTODO recurs, then the COMPLETED date should be used to determine when the event is again due? This is a tricky situation -- one I'd like to see resolved. For example. Say you have a VTODO that looks like this: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN BEGIN:VTODO UID:fed50a1c-1e72-11db-a465-aae271be3660 SUMMARY:Test Todo STATUS:COMPLETED COMPLETED;TZID=US-Eastern:20060825T100000 CLASS:PRIVATE DTSTART;TZID=US-Eastern:20060728T090000 RRULE:FREQ=WEEKLY;INTERVAL=3;UNTIL=20061207T160000Z DTSTAMP:20060728T195437Z END:VTODO BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T000000Z TZURL:http://zones.stds_r_us.net/tz/US-Eastern BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE END:VCALENDAR Notice the VTODO has been marked both in COMPLETED status and with a COMPLETED date/time. However, the VTODO is also scheduled to recur every 3 weeks. Should the status be reset to NEEDS-ACTION after this time? Should that be implicit? How should a CUA handle this situation? Also, how should the recurrence rule be handled? It seems it should be scheduled 3 weeks from the COMPLETED date/time. Is that accurate? Any thoughts? -Doug Day http://www.ddaysoftware.com Reinhold Kainhofer wrote: > Hi all, > Recently the issue came up in kde how a completed to-do is supposed to be > indicated. There are three different completion settings defined in rfc 5545: > -) STATUS:COMPLETED (as opposed to NEEDS-ACTION) > -) COMPLETED:20070707T100000Z > -) PERCENT-COMPLETE:100 > > However, the RFC is quiet which of those is supposed to indicate that a to-do > is actually completed... There is, however, an example in section 3.6.2 of a > completed to-do: > > The following is an example of a "VTODO" calendar component that > was due before 1:00 P.M. UTC on July 9th, 2007 and was completed > on July 7th, 2007 at 10:00 A.M. UTC. > > BEGIN:VTODO > UID:20070514T103211Z-123404@example.com > DTSTAMP:20070514T103211Z > DTSTART:20070514T110000Z > DUE:20070709T130000Z > COMPLETED:20070707T100000Z > SUMMARY:Submit Revised Internet-Draft > PRIORITY:1 > STATUS:NEEDS-ACTION > END:VTODO > > Is the STATUS:NEEDS-ACTION really intended or is it an oversight and should > rather be STATUS:COMPLETED??? > > The problem we have is interoperability: Horde creates a VTODO with > STATUS:COMPLETED > COMPLETED:20100112T125449Z > while Korganizer and kontact instead use only the completion percentage: > COMPLETED:20100112T124208Z > PERCENT-COMPLETE:100 > > Unfortunately, this totally breaks the exchange of to-dos between horde and > kontact, as completed to-dos in one application won't be detected as completed > in the other. > > > In the RFC I couldn't find anything that says that one of the is "correct" and > the other is not... > > Cheers, > Reinhold > Reinhold CONFIDENTIALITY NOTICE: This electronic transmission may contain confidential information. This information is intended for the use of the individual(s) or entity to whom it is intended, even if addressed incorrectly. This information should not be read, given or made accessible to anyone else. Please delete it from your files if you are not the intended recipient. If you have received this electronic transmission in error, please notify the sender immediately via the address shown. Thank you for your compliance. --------------040408020000050904050004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reinhold,

Those are some good points, and I'd like to hear other's view on this.

My personal interpretation is that the STATUS is the driving field here;  both the COMPLETED and PERCENT-COMPLETE are there for informational purposes when determining if the VTODO is complete.

However, there is a kink with this philosophy:

1.  VTODO items can recur.
2.  The only solution I can see for tracking completed status is a combination of the STATUS property and the COMPLETED property.  If the STATUS field is set to COMPLETED, but the VTODO recurs, then the COMPLETED date should be used to determine when the event is again due?  This is a tricky situation -- one I'd like to see resolved.

For example.  Say you have a VTODO that looks like this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VTODO
UID:fed50a1c-1e72-11db-a465-aae271be3660
SUMMARY:Test Todo
STATUS:COMPLETED
COMPLETED;TZID=US-Eastern:20060825T100000
CLASS:PRIVATE
DTSTART;TZID=US-Eastern:20060728T090000
RRULE:FREQ=WEEKLY;INTERVAL=3;UNTIL=20061207T160000Z
DTSTAMP:20060728T195437Z
END:VTODO
BEGIN:VTIMEZONE
TZID:US-Eastern
LAST-MODIFIED:19870101T000000Z
TZURL:http://zones.stds_r_us.net/tz/US-Eastern
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
END:VCALENDAR

Notice the VTODO has been marked both in COMPLETED status and with a COMPLETED date/time.  However, the VTODO is also scheduled to recur every 3 weeks.  Should the status be reset to NEEDS-ACTION after this time?  Should that be implicit?  How should a CUA handle this situation?

Also, how should the recurrence rule be handled?  It seems it should be scheduled 3 weeks from the COMPLETED date/time.  Is that accurate?

Any thoughts?
-Doug Day
http://www.ddaysoftware.com

 

Reinhold Kainhofer wrote:
Hi all,
Recently the issue came up in kde how a completed to-do is supposed to be 
indicated. There are three different completion settings defined in rfc 5545:
-) STATUS:COMPLETED (as opposed to NEEDS-ACTION)
-) COMPLETED:20070707T100000Z
-) PERCENT-COMPLETE:100

However, the RFC is quiet which of those is supposed to indicate that a to-do 
is actually completed... There is, however, an example in section 3.6.2 of a 
completed to-do:

      The following is an example of a "VTODO" calendar component that
      was due before 1:00 P.M. UTC on July 9th, 2007 and was completed
      on July 7th, 2007 at 10:00 A.M. UTC.

       BEGIN:VTODO
       UID:20070514T103211Z-123404@example.com
       DTSTAMP:20070514T103211Z
       DTSTART:20070514T110000Z
       DUE:20070709T130000Z
       COMPLETED:20070707T100000Z
       SUMMARY:Submit Revised Internet-Draft
       PRIORITY:1
       STATUS:NEEDS-ACTION
       END:VTODO

Is the STATUS:NEEDS-ACTION really intended or is it an oversight and should 
rather be STATUS:COMPLETED???

The problem we have is interoperability: Horde creates a VTODO with
    STATUS:COMPLETED
    COMPLETED:20100112T125449Z
while Korganizer and kontact instead use only the completion percentage:
    COMPLETED:20100112T124208Z
    PERCENT-COMPLETE:100

Unfortunately, this totally breaks the exchange of to-dos between horde and 
kontact, as completed to-dos in one application won't be detected as completed 
in the other.


In the RFC I couldn't find anything that says that one of the is "correct" and 
the other is not... 

Cheers,
Reinhold




Reinhold

CONFIDENTIALITY NOTICE:  This electronic transmission may contain confidential information.
This information is intended for the use of the individual(s) or entity to whom it is 
intended, even if addressed incorrectly.  This information should not be read, 
given or made accessible to anyone else.  Please delete it from your files if you are 
not the intended recipient.  If you have received this electronic transmission in error, 
please notify the sender immediately via the address shown.  Thank you for your compliance.
--------------040408020000050904050004-- --===============1612761877== 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 --===============1612761877==-- From ietf-calsify-bounces@osafoundation.org Thu Jan 14 08:41:07 2010 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 85BC93A697E for ; Thu, 14 Jan 2010 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Ckj9p3nBjRFJ for ; Thu, 14 Jan 2010 08:41:06 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 598D63A696F for ; Thu, 14 Jan 2010 08:41:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id ED44077D714; Thu, 14 Jan 2010 08:40:52 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2MWP4AuqWFi; Thu, 14 Jan 2010 08:40:52 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 533957841ED; Thu, 14 Jan 2010 08:38:54 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id AC7E577D71C for ; Thu, 14 Jan 2010 08:37:51 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQuhWhTMRqHG for ; Thu, 14 Jan 2010 08:37:37 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id 9DB3377D714 for ; Thu, 14 Jan 2010 08:37:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7F75994D9892 for ; Thu, 14 Jan 2010 11:37:04 -0500 (EST) 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 2hHGtH7IZoHe for ; Thu, 14 Jan 2010 11:37:04 -0500 (EST) Received: from [17.244.121.139] (unknown [75.16.26.133]) by daboo.name (Postfix) with ESMTPSA id 9213B94D9889 for ; Thu, 14 Jan 2010 11:37:03 -0500 (EST) Date: Thu, 14 Jan 2010 08:37:00 -0800 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: <72B29711D784C848D153D971@socrates.local> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=309 Subject: [ietf-calsify] RFC5546 is out X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi folks, iTIPbis is now RFC 5546 (). It was actually published at the end of last year but for some reason the actual announcement message got lost (RFC editor said they would try and re-post it). Thanks to everyone who helped out with this revision. -- Cyrus Daboo _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Jan 14 08:56:47 2010 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 3196D3A6905 for ; Thu, 14 Jan 2010 08:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 sKDDu1UEH6IG for ; Thu, 14 Jan 2010 08:56:46 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 381793A685D for ; Thu, 14 Jan 2010 08:56:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 665C277D71C; Thu, 14 Jan 2010 08:56:33 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlVYA1x3ETRZ; Thu, 14 Jan 2010 08:56:33 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DF2E777D714; Thu, 14 Jan 2010 08:54:36 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 6CE1377D71C for ; Thu, 14 Jan 2010 08:53:34 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDSli+OjTLAA for ; Thu, 14 Jan 2010 08:53:14 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 764A777D714 for ; Thu, 14 Jan 2010 08:52:53 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAAjaTkuQ/uCWe2dsb2JhbACDYJgWAQEWJAaoD4cXjViBK4IvVgQ X-IronPort-AV: E=Sophos;i="4.49,275,1262563200"; d="scan'208";a="2438065" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 Jan 2010 16:23:39 +0000 Received: from dhcp-10-61-111-195.cisco.com (dhcp-10-61-111-195.cisco.com [10.61.111.195]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0EGqenp000281; Thu, 14 Jan 2010 16:52:40 GMT Message-ID: <4B4F4BD8.5040907@cisco.com> Date: Thu, 14 Jan 2010 17:52:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Cyrus Daboo References: <72B29711D784C848D153D971@socrates.local> In-Reply-To: <72B29711D784C848D153D971@socrates.local> X-Enigmail-Version: 1.0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] RFC5546 is out X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Congratulations, Cyrus, on a great job! Eliot On 1/14/10 5:37 PM, Cyrus Daboo wrote: > Hi folks, > iTIPbis is now RFC 5546 (). It was > actually published at the end of last year but for some reason the actual > announcement message got lost (RFC editor said they would try and re-post > it). > > Thanks to everyone who helped out with this revision. > > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From alexey.melnikov@isode.com Fri Jan 29 15:38:58 2010 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E183A6931 for ; Fri, 29 Jan 2010 15:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Or9OJgge6YGs for ; Fri, 29 Jan 2010 15:38:57 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 93B7F3A6807 for ; Fri, 29 Jan 2010 15:38:56 -0800 (PST) Received: from [92.40.156.85] (92.40.156.85.sub.mbb.three.co.uk [92.40.156.85]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 29 Jan 2010 23:39:17 +0000 Message-ID: <4B637190.2010009@isode.com> Date: Fri, 29 Jan 2010 23:38:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo References: <4B15183F.3030209@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010806030203030504080704" Cc: calsify@ietf.org Subject: Re: [calsify] WGLC for draft-ietf-calsify-rfc2447bis-07.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 23:38:58 -0000 --------------010806030203030504080704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cyrus Daboo wrote: > Hi, Hi Cyrus, Thank you for the review. My belated response: > --On December 1, 2009 2:21:03 PM +0100 Eliot Lear wrote: > >> We are entering working group last call for >> draft-ietf-calsify-rfc2447bis-07.txt, iMIP. At this time I would ask=20 >> you >> to please identify any outstanding issues you have with the draft, if=20 >> you >> have not already done so. I am in the process of checking all examples. >> You can find a copy of the draft at >> http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07. > > My review: > > - Abstract: change '(iCAL)' to '(iCalendar)'. > > - Introduction: change 'over MIME as defined in' to 'over Internet=20 > email (using MIME) as defined in'. Both changed, thanks. > - =C2=A72: The terminology for "originator" and "respondent" are a little= =20 > messy. As per iTIP. "originator" is the person sending the message.=20 > That could be the ORGANIZER or ATTENDEE. iTIP does not have the=20 > concept of a "respondent", but rather uses "recipient" to refer to the=20 > use receiving the scheduling message (and that too could be either the=20 > ORGANIZER or an ATTENDEE). Since "respondent" is really only used in=20 > one place I suggest we remove it and replace it with "recipient" in=20 > =C2=A72.2.1. Then the following should be done: > > -- =C2=A72, =C2=B62 & =C2=B63 change to: > > The sections below refer to the "originator" and the "recipient" of an > iMIP message. In the case of a "request" method, the originator is the > "Organizer" and the recipient is an "Attendee" of the event. In the > case of a "response" method, the originator is an "Attendee" and the > recipient is the "Organizer" of the event. > > The [RFC-5322] "Reply-To" header typically contains the email address > of the originator of the scheduling message. However, this cannot be > guaranteed as Mail User Agents (MUA) are not required to enforce iMIP > semantics. Ok, I used your text. > - =C2=A72, =C2=B63 - why is Reply-to even mentioned here? If it is mention= ed,=20 > why is there no discussion on what goes in the From or To fields? I=20 > think this is something lacking in the spec. What is more there needs=20 > to be a clear statement that when a recipient replies to a scheduling=20 > message with another scheduling message (as opposed to a "regular"=20 > email message), they MUST use the addressing information in the=20 > iCalendar data and not that in the email headers (i.e. discard From:,=20 > Reply-To: etc). I am still thinking about the best way of dealing with this. > - =C2=A72.2.1, =C2=B63: why is the reference to "[RFC-1847]" at the start? Hmm. To qualify "message flow"? > - =C2=A72.3, =C2=B61: change 'the "ATTENDEE" property' to 'the "ORGANIZER"= and=20 > "ATTENDEE" properties' > > - =C2=A72.4 title: change 'Content Type' to 'Content-Type'. Changed. > - =C2=A72.4: this has terms like '"method" parameter' when referring to a= =20 > MIME header parameter. But the main terminology section stated that=20 > iCalendar parameters would appear in lower case with the work=20 > "parameter" after them. So there is the potential for confusion here=20 > (we have the same issue with CalDAV and iCalendar and "property"). I=20 > suggest we change the document to use upper case for the iCalendar=20 > parameters, which matches how those are displayed in iCalendar and=20 > iTIP. Also, when talking about MIME parameters, we should explicitly=20 > state "MIME parameter" rather than just "parameter". I've tried to do that, but I am not sure if I've done it consistently in=20 the document. Please check the following version. > - =C2=A72.4, =C2=B610: missing reference '<>'. This required some digging. I've added a reference to Content-Language=20 header field. > - =C2=A72.5 Example: change 'ACME' to 'example.com' - do that for all=20 > examples. I've changed to use: PRODID:-//Example/ExampleCalendarClient//EN as in RFC 5546. > - =C2=A73, =C2=B61: comment left at the end of the paragraph needs to be a= ddressed. Can you recommend some specific text? > - =C2=A73, =C2=B64: change 'Section 3 of [iTIP]' to 'Section 1.4 of [iTIP]= '. > > - =C2=A74.3 title: 'Inline Attachment' is confusing as iCalendar refers to= =20 > "inline attachments" as ones where the attachment data is directly in=20 > the iCalendar property. I suggest just removing 'and Inline=20 > Attachment' from the end of the title.=20 Changed. --------------010806030203030504080704 Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable Cyrus Daboo wrote:
Hi,
Hi Cyrus,
Thank you for the review. My belated response:
--On December 1, 2009 2:21:03 PM +0100 Eliot Lear <lear@cisco.com> wrote:
We are entering working group last call for
draft-ietf-calsify-rfc2447bis-07.txt, iMIP.=C2=A0 At this time I would ask you
to please identify any outstanding issues you have with the draft, if you
have not already done so.=C2=A0 I am in the process of checking all examples.
You can find a copy of the draft at
http:/= /tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07.
My review:

- Abstract: change '(iCAL)' to '(iCalendar)'.

- Introduction: change 'over MIME as defined in' to 'over Internet email (using MIME) as defined in'.
Both changed, thanks.
- =C2=A72: The terminology for "originator" and "respondent" are a little messy. As per iTIP. "originator" is the person sending the message. That could be the ORGANIZER or ATTENDEE. iTIP does not have the concept of a "respondent", but rather uses "recipient" to refer to the use receiving the scheduling message (and that too could be either the ORGANIZER or an ATTENDEE). Since "respondent" is really only used in one place I suggest we remove it and replace it with "recipient" in =C2=A72.2.1. Then the following should be done:

-- =C2=A72, =C2=B62 & =C2=B63 change to:

=C2=A0=C2=A0 The sections below refer to the "originator" and the "recipient" of an
=C2=A0=C2=A0 iMIP message. In the case of a "request" method, the originator= is the
=C2=A0=C2=A0 "Organizer" and the recipient is an "Attendee" of the event. In= the
=C2=A0=C2=A0 case of a "response" method, the originator is an "Attendee" an= d the
=C2=A0=C2=A0 recipient is the "Organizer" of the event.

=C2=A0=C2=A0 The [RFC-5322] "Reply-To" header typically contains the email address
=C2=A0=C2=A0 of the originator of the scheduling message. However, this cann= ot be
=C2=A0=C2=A0 guaranteed as Mail User Agents (MUA) are not required to enforc= e iMIP
=C2=A0=C2=A0 semantics.
Ok, I used your text.
- =C2=A72, =C2=B63 - why is Reply-to even mentioned here? If = it is mentioned, why is there no discussion on what goes in the From or To fields? I think this is something lacking in the spec. What is more there needs to be a clear statement that when a recipient replies to a scheduling message with another scheduling message (as opposed to a "regular" email message), they MUST use the addressing information in the iCalendar data and not that in the email headers (i.e. discard From:, Reply-To: etc).
I am still thinking about the best way of dealing with this.
- =C2=A72.2.1, =C2=B63: why is the reference to "[RFC-1847]" = at the start?
Hmm. To qualify "message flow"?
- =C2=A72.3, =C2=B61: change 'the "ATTENDEE" property' to 't= he "ORGANIZER" and "ATTENDEE" properties'

- =C2=A72.4 title: change 'Content Type' to 'Content-Type'.
Changed.
- =C2=A72.4: this has terms like '"method" parameter' when referring to a MIME header parameter. But the main terminology section stated that iCalendar parameters would appear in lower case with the work "parameter" after them. So there is the potential for confusion here (we have the same issue with CalDAV and iCalendar and "property"). I suggest we change the document to use upper case for the iCalendar parameters, which matches how those are displayed in iCalendar and iTIP. Also, when talking about MIME parameters, we should explicitly state "MIME parameter" rather than just "parameter".
I've tried to do that, but I am not sure if I've done it consistently in the document. Please check the following version.
- =C2=A72.4, =C2=B610: missing reference '<<add ref>= >'.
This required some digging. I've added a reference to Content-Language header field.
- =C2=A72.5 Example: change 'ACME' to 'example.com' - do that for all examples.
I've changed to use:
PRODID:-//Example/ExampleCalendarClient//EN

as in RFC 5546.
- =C2=A73, =C2=B61: comment left at the end of the paragraph needs to be addressed.
Can you recommend some specific text?
- =C2=A73, =C2=B64: change 'Section 3 of [iTIP]' to 'Section = 1.4 of [iTIP]'.

- =C2=A74.3 title: 'Inline Attachment' is confusing as iCalendar refers to "inline attachments" as ones where the attachment data is directly in the iCalendar property. I suggest just removing 'and Inline Attachment' from the end of the title.
Changed.




--------------010806030203030504080704--

From calsify-bounces@ietf.org  Fri Jan 29 15:38:59 2010
Return-Path: 
X-Original-To: calsify-archive-feit0ahl@lists.ietf.org
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE72C3A6931; Fri, 29 Jan 2010 15:38:59 -0800 (PST)
X-Original-To: calsify@core3.amsl.com
Delivered-To: calsify@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E183A6931 for ; Fri, 29 Jan 2010 15:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.826
X-Spam-Level: 
X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 Or9OJgge6YGs for ; Fri, 29 Jan 2010 15:38:57 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 93B7F3A6807 for ; Fri, 29 Jan 2010 15:38:56 -0800 (PST)
Received: from [92.40.156.85] (92.40.156.85.sub.mbb.three.co.uk [92.40.156.85])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Fri, 29 Jan 2010 23:39:17 +0000
Message-ID: <4B637190.2010009@isode.com>
Date: Fri, 29 Jan 2010 23:38:56 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cyrus Daboo 
References: <4B15183F.3030209@cisco.com> 
In-Reply-To: 
MIME-Version: 1.0
Cc: calsify@ietf.org
Subject: Re: [calsify] WGLC for draft-ietf-calsify-rfc2447bis-07.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1508180632=="
Sender: calsify-bounces@ietf.org
Errors-To: calsify-bounces@ietf.org

--===============1508180632==
Content-Type: multipart/alternative;
 boundary="------------010806030203030504080704"


--------------010806030203030504080704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable

Cyrus Daboo wrote:

> Hi,

Hi Cyrus,
Thank you for the review. My belated response:

> --On December 1, 2009 2:21:03 PM +0100 Eliot Lear  wrote:
>
>> We are entering working group last call for
>> draft-ietf-calsify-rfc2447bis-07.txt, iMIP.  At this time I would ask=20
>> you
>> to please identify any outstanding issues you have with the draft, if=20
>> you
>> have not already done so.  I am in the process of checking all examples.
>> You can find a copy of the draft at
>> http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07.
>
> My review:
>
> - Abstract: change '(iCAL)' to '(iCalendar)'.
>
> - Introduction: change 'over MIME as defined in' to 'over Internet=20
> email (using MIME) as defined in'.

Both changed, thanks.

> - =C2=A72: The terminology for "originator" and "respondent" are a little=
=20
> messy. As per iTIP. "originator" is the person sending the message.=20
> That could be the ORGANIZER or ATTENDEE. iTIP does not have the=20
> concept of a "respondent", but rather uses "recipient" to refer to the=20
> use receiving the scheduling message (and that too could be either the=20
> ORGANIZER or an ATTENDEE). Since "respondent" is really only used in=20
> one place I suggest we remove it and replace it with "recipient" in=20
> =C2=A72.2.1. Then the following should be done:
>
> -- =C2=A72, =C2=B62 & =C2=B63 change to:
>
>    The sections below refer to the "originator" and the "recipient" of an
>    iMIP message. In the case of a "request" method, the originator is the
>    "Organizer" and the recipient is an "Attendee" of the event. In the
>    case of a "response" method, the originator is an "Attendee" and the
>    recipient is the "Organizer" of the event.
>
>    The [RFC-5322] "Reply-To" header typically contains the email address
>    of the originator of the scheduling message. However, this cannot be
>    guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
>    semantics.

Ok, I used your text.

> - =C2=A72, =C2=B63 - why is Reply-to even mentioned here? If it is mention=
ed,=20
> why is there no discussion on what goes in the From or To fields? I=20
> think this is something lacking in the spec. What is more there needs=20
> to be a clear statement that when a recipient replies to a scheduling=20
> message with another scheduling message (as opposed to a "regular"=20
> email message), they MUST use the addressing information in the=20
> iCalendar data and not that in the email headers (i.e. discard From:,=20
> Reply-To: etc).

I am still thinking about the best way of dealing with this.

> - =C2=A72.2.1, =C2=B63: why is the reference to "[RFC-1847]" at the start?

Hmm. To qualify "message flow"?

> - =C2=A72.3, =C2=B61: change 'the "ATTENDEE" property' to 'the "ORGANIZER"=
 and=20
> "ATTENDEE" properties'
>
> - =C2=A72.4 title: change 'Content Type' to 'Content-Type'.

Changed.

> - =C2=A72.4: this has terms like '"method" parameter' when referring to a=
=20
> MIME header parameter. But the main terminology section stated that=20
> iCalendar parameters would appear in lower case with the work=20
> "parameter" after them. So there is the potential for confusion here=20
> (we have the same issue with CalDAV and iCalendar and "property"). I=20
> suggest we change the document to use upper case for the iCalendar=20
> parameters, which matches how those are displayed in iCalendar and=20
> iTIP. Also, when talking about MIME parameters, we should explicitly=20
> state "MIME parameter" rather than just "parameter".

I've tried to do that, but I am not sure if I've done it consistently in=20
the document. Please check the following version.

> - =C2=A72.4, =C2=B610: missing reference '<>'.

This required some digging. I've added a reference to Content-Language=20
header field.

> - =C2=A72.5 Example: change 'ACME' to 'example.com' - do that for all=20
> examples.

I've changed to use:

PRODID:-//Example/ExampleCalendarClient//EN

as in RFC 5546.

> - =C2=A73, =C2=B61: comment left at the end of the paragraph needs to be a=
ddressed.

Can you recommend some specific text?

> - =C2=A73, =C2=B64: change 'Section 3 of [iTIP]' to 'Section 1.4 of [iTIP]=
'.
>
> - =C2=A74.3 title: 'Inline Attachment' is confusing as iCalendar refers to=
=20
> "inline attachments" as ones where the attachment data is directly in=20
> the iCalendar property. I suggest just removing 'and Inline=20
> Attachment' from the end of the title.=20

Changed.


--------------010806030203030504080704
Content-Type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable




  
  








Cyrus Daboo wrote:

Hi, 



Hi Cyrus,

Thank you for the review. My belated response:


--On December 1, 2009 2:21:03 PM +0100 Eliot Lear <lear@cisco.com>
wrote: 

  
We are entering working group last call for 

draft-ietf-calsify-rfc2447bis-07.txt, iMIP.=C2=A0 At this time I would ask
you 

to please identify any outstanding issues you have with the draft, if
you 

have not already done so.=C2=A0 I am in the process of checking all
examples. 

You can find a copy of the draft at 

    http:/=
/tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07.
    

  

My review: 

  

- Abstract: change '(iCAL)' to '(iCalendar)'. 

  

- Introduction: change 'over MIME as defined in' to 'over Internet
email (using MIME) as defined in'. 



Both changed, thanks.


- =C2=A72: The terminology for "originator" and "respondent"
are a little
messy. As per iTIP. "originator" is the person sending the message.
That could be the ORGANIZER or ATTENDEE. iTIP does not have the concept
of a "respondent", but rather uses "recipient" to refer to the use
receiving the scheduling message (and that too could be either the
ORGANIZER or an ATTENDEE). Since "respondent" is really only used in
one place I suggest we remove it and replace it with "recipient" in
=C2=A72.2.1. Then the following should be done: 

  

-- =C2=A72, =C2=B62 & =C2=B63 change to: 

  

=C2=A0=C2=A0 The sections below refer to the "originator" and the
"recipient" of
an 

=C2=A0=C2=A0 iMIP message. In the case of a "request" method, the originator=
 is
the 

=C2=A0=C2=A0 "Organizer" and the recipient is an "Attendee" of the event. In=
 the 

=C2=A0=C2=A0 case of a "response" method, the originator is an "Attendee" an=
d the
  

=C2=A0=C2=A0 recipient is the "Organizer" of the event. 

  

=C2=A0=C2=A0 The [RFC-5322] "Reply-To" header typically contains the email
address 

=C2=A0=C2=A0 of the originator of the scheduling message. However, this cann=
ot be
  

=C2=A0=C2=A0 guaranteed as Mail User Agents (MUA) are not required to enforc=
e
iMIP 

=C2=A0=C2=A0 semantics. 



Ok, I used your text.


- =C2=A72, =C2=B63 - why is Reply-to even mentioned here? If =
it
is mentioned, why
is there no discussion on what goes in the From or To fields? I think
this is something lacking in the spec. What is more there needs to be a
clear statement that when a recipient replies to a scheduling message
with another scheduling message (as opposed to a "regular" email
message), they MUST use the addressing information in the iCalendar
data and not that in the email headers (i.e. discard From:, Reply-To:
etc). 



I am still thinking about the best way of dealing with this.


- =C2=A72.2.1, =C2=B63: why is the reference to "[RFC-1847]" =
at the
start? 



Hmm. To qualify "message flow"?


 - =C2=A72.3, =C2=B61: change 'the "ATTENDEE" property' to 't=
he
"ORGANIZER"
and
"ATTENDEE" properties' 

  

- =C2=A72.4 title: change 'Content Type' to 'Content-Type'. 



Changed.


- =C2=A72.4: this has terms like '"method" parameter'
when referring to a
MIME header parameter. But the main terminology section stated that
iCalendar parameters would appear in lower case with the work
"parameter" after them. So there is the potential for confusion here
(we have the same issue with CalDAV and iCalendar and "property"). I
suggest we change the document to use upper case for the iCalendar
parameters, which matches how those are displayed in iCalendar and
iTIP. Also, when talking about MIME parameters, we should
explicitly
state "MIME parameter" rather than just "parameter". 



I've tried to do that, but I am not sure if I've done it consistently
in the document. Please check the following version.


- =C2=A72.4, =C2=B610: missing reference '<<add ref>=
>'. 



This required some digging. I've added a reference to Content-Language
header field.


- =C2=A72.5 Example: change 'ACME' to 'example.com' -
do that for all
examples. 



I've changed to use:


PRODID:-//Example/ExampleCalendarClient//EN

as in RFC 5546.



- =C2=A73, =C2=B61: comment left at the end of the paragraph
needs to be
addressed. 



Can you recommend some specific text?


- =C2=A73, =C2=B64: change 'Section 3 of [iTIP]' to 'Section =
1.4
of [iTIP]'. 

  

- =C2=A74.3 title: 'Inline Attachment' is confusing as iCalendar
refers to
"inline attachments" as ones where the attachment data is directly in
the iCalendar property. I suggest just removing 'and Inline Attachment'
from the end of the title. 

Changed.






--------------010806030203030504080704--

--===============1508180632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--===============1508180632==--