From nobody Mon Jan 5 06:49:14 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662BE1A88B4 for ; Mon, 5 Jan 2015 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_TQQt9X5-bY for ; Mon, 5 Jan 2015 06:49:10 -0800 (PST) Received: from oak.morsemedia.net (oak.morsemedia.net [69.50.241.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB051A88B2 for ; Mon, 5 Jan 2015 06:49:10 -0800 (PST) Received: from c75-111-84-234.erkacmtk01.ca.dh.suddenlink.net ([75.111.84.234]:33708 helo=[192.168.0.100]) by oak.morsemedia.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1Y88xt-0004VC-To; Mon, 05 Jan 2015 06:49:06 -0800 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B4D07283-8C3E-427D-B60C-57706BC7B71C" From: Dave Thewlis In-Reply-To: Date: Mon, 5 Jan 2015 06:49:04 -0800 Message-Id: <2CA3A3CD-5008-49E2-A44D-F7EF19105AAD@calconnect.org> References: To: "Anganes, Amanda L" X-Mailer: Apple Mail (2.1993) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1Y88xt-0004VC-To X-MorseMedia-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oak.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Get-Message-Sender-Via: oak.morsemedia.net: authenticated_id: dave@dcta.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/fcEnkJkEEfHKzkYwr6Lgk78rcE8 Cc: "calsify@ietf.org" Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:49:13 -0000 --Apple-Mail=_B4D07283-8C3E-427D-B60C-57706BC7B71C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am in favor of adopting this document. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | Dave.Thewlis@calconnect.org > On Dec 19, 2014, at 10:49 AM, Anganes, Amanda L = wrote: >=20 > Greetings, >=20 > This is a call for comments on the adoption of = draft-daboo-calendar-availability-05 as an official Calendering = Extensions Working Group draft. Due to the holiday season, this call for = adoption will run a bit longer =96 please comment by January 16th. >=20 > Thanks, >=20 > Amanda & Donald >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --Apple-Mail=_B4D07283-8C3E-427D-B60C-57706BC7B71C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I am in favor of adopting this = document.

Dave = Thewlis


--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling = Consortium
+1 707 840 9391 voice | +1 707 498 = 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | Dave.Thewlis@calconnect.org

On Dec 19, 2014, at 10:49 AM, Anganes, Amanda L <aanganes@mitre.org> = wrote:

Greetings,

This is a call for comments on the adoption of = draft-daboo-calendar-availability-05 as an official Calendering = Extensions Working Group draft. Due to the holiday season, this call for = adoption will run a bit longer =96 please comment by January 16th.

Thanks,

Amanda & Donald

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

= --Apple-Mail=_B4D07283-8C3E-427D-B60C-57706BC7B71C-- From nobody Mon Jan 5 06:49:52 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4240E1A88C3 for ; Mon, 5 Jan 2015 06:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo0CzOlK1s7m for ; Mon, 5 Jan 2015 06:49:48 -0800 (PST) Received: from oak.morsemedia.net (oak.morsemedia.net [69.50.241.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2C91A88C7 for ; Mon, 5 Jan 2015 06:49:47 -0800 (PST) Received: from c75-111-84-234.erkacmtk01.ca.dh.suddenlink.net ([75.111.84.234]:33708 helo=[192.168.0.100]) by oak.morsemedia.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1Y88yY-0004VC-5Y; Mon, 05 Jan 2015 06:49:46 -0800 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C3DDB2A2-4DB6-4AE5-9E64-E998DD6DA590" From: Dave Thewlis In-Reply-To: Date: Mon, 5 Jan 2015 06:49:45 -0800 Message-Id: <49A67E54-A935-4AF3-9351-A96E6B1CFFEF@calconnect.org> References: To: "Anganes, Amanda L" X-Mailer: Apple Mail (2.1993) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1Y88yY-0004VC-5Y X-MorseMedia-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oak.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Get-Message-Sender-Via: oak.morsemedia.net: authenticated_id: dave@dcta.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Iwrdm9fSl0eSty44F2K1MDLDZ1g Cc: "calsify@ietf.org" Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:49:50 -0000 --Apple-Mail=_C3DDB2A2-4DB6-4AE5-9E64-E998DD6DA590 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am in favor of adopting this document. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | Dave.Thewlis@calconnect.org > On Dec 19, 2014, at 10:50 AM, Anganes, Amanda L = wrote: >=20 > Greetings, >=20 > This is a call for comments on the adoption of = draft-daboo-icalendar-extensions-08 as an official Calendering = Extensions Working Group draft. Due to the holiday season, this call for = adoption will run a bit longer =96 please comment by January 16th. >=20 > Thanks, >=20 > Amanda & Donald >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --Apple-Mail=_C3DDB2A2-4DB6-4AE5-9E64-E998DD6DA590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am in favor of adopting this document.

Dave Thewlis


--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling = Consortium
+1 707 840 9391 voice | +1 707 498 = 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | Dave.Thewlis@calconnect.org

On Dec 19, 2014, at 10:50 AM, Anganes, Amanda L <aanganes@mitre.org> = wrote:

Greetings,

This is a call for comments on the adoption = of draft-daboo-icalendar-extensions-08 as an official = Calendering Extensions Working Group draft. Due to the holiday season, = this call for adoption will run a bit longer =96 please comment by = January 16th.

Thanks,

Amanda & Donald

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

= --Apple-Mail=_C3DDB2A2-4DB6-4AE5-9E64-E998DD6DA590-- From nobody Mon Jan 5 14:01:09 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02B61A8F3D; Mon, 5 Jan 2015 14:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n68Jyxk4Dog; Mon, 5 Jan 2015 14:01:03 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 415931A8BBD; Mon, 5 Jan 2015 14:01:03 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTPA id A4F581342B; Mon, 5 Jan 2015 17:01:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21675.2462.186194.702206@compute03.cs.columbia.edu> Date: Mon, 5 Jan 2015 17:01:02 -0500 From: Jonathan Lennox To: tzdist@ietf.org,calsify@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/-F6IsY_E9YCgq6I8u0Ju_vns2Ds Subject: [calsify] How should tzdist support rscale? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 22:01:05 -0000 (Cc'ing both tzdist and calsify because the issue is about the interaction of specs defined by the two groups...please trim to one or the other if the topic ends up being unique to that group.) A question recently occured to me about the interaction of rscale and tzdist. Should it be possible for a VTIMEZONE -- either inline in an iCalendar document, or distributed by tzdist -- to use an RSCALE? There are some natural use cases for this -- Iran uses the Persian calendar to set its DST observances, and Israel used the Hebrew calendar from 2005-2012. Right now the IANA tzdata just expands non-Gregorian rules to a list of dates, but in principle, RSCALE would be a much more natural (and compact) way of representing rules like these. However, tzdist has no way to negotiate the use of iCalendar extensions. Should one be defined? For that matter, the rscale draft doesn't talk about its use in VTIMEZONE at all (indeed, it asserts that VTIMEZONEs are always specified in Gregorian time). Should it? -- Jonathan Lennox lennox@cs.columbia.edu From nobody Tue Jan 6 07:24:37 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39851A1AA1; Tue, 6 Jan 2015 07:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbWHQDFzNd44; Tue, 6 Jan 2015 07:24:32 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214CB1A8850; Tue, 6 Jan 2015 07:24:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7251A809E32; Tue, 6 Jan 2015 10:24:19 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ycJmj_fGTJ; Tue, 6 Jan 2015 10:24:19 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 0DD82809E25; Tue, 6 Jan 2015 10:24:17 -0500 (EST) Date: Tue, 06 Jan 2015 10:24:13 -0500 From: Cyrus Daboo To: Jonathan Lennox , tzdist@ietf.org, calsify@ietf.org Message-ID: <258A901779432BE2E9A929AD@caldav.corp.apple.com> In-Reply-To: <21675.2462.186194.702206@compute03.cs.columbia.edu> References: <21675.2462.186194.702206@compute03.cs.columbia.edu> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2026 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/hWtjWkOn_tU2jVNOtWLhV91l12s Subject: Re: [calsify] [Tzdist] How should tzdist support rscale? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:24:35 -0000 Hi Jonathan, --On January 5, 2015 at 5:01:02 PM -0500 Jonathan Lennox wrote: > A question recently occured to me about the interaction of rscale and > tzdist. > > Should it be possible for a VTIMEZONE -- either inline in an iCalendar > document, or distributed by tzdist -- to use an RSCALE? If a time zone were indeed defined in terms of a non-Gregorian recurrence then it would seem reasonable to support that. > There are some natural use cases for this -- Iran uses the Persian > calendar to set its DST observances, and Israel used the Hebrew calendar > from 2005-2012. Right now the IANA tzdata just expands non-Gregorian > rules to a list of dates, but in principle, RSCALE would be a much more > natural (and compact) way of representing rules like these. > > However, tzdist has no way to negotiate the use of iCalendar extensions. > Should one be defined? If tz data publishers actually start wantint to produce data using non-Gregorian rules, then we can easily define an extension to the capabilities response to indicate that is an option. > For that matter, the rscale draft doesn't talk about its use in VTIMEZONE > at all (indeed, it asserts that VTIMEZONEs are always specified in > Gregorian time). Should it? Actually the rscale document only mentions time zones once in Section 1 - and there it states that time zone rules (i.e., what comes from a publisher) is specified in terms of the Gregorian calendar - that does not imply VTIMEZONE itself is limited to Gregorian rules - just that no time zone data uses non-Gregorian. If you think that text needs re-wording to clarify that, I can certainly change it. At this point, I think the use of non-Gregorian rules in VTIMEZONE should not be ruled out, but tzdist does not need to support it until we have publishers actually wanting to use it. Of course at that point things will get tricky for the publisher as they will want to keep the Gregorian rules around for backwards compatibility. -- Cyrus Daboo From nobody Wed Jan 7 07:21:35 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC13B1A9127; Wed, 7 Jan 2015 07:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cvntVs9h4NB; Wed, 7 Jan 2015 07:21:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B20DA1A914D; Wed, 7 Jan 2015 07:21:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 07:21:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/QmcTe21aHjJLU3c0rbPu7vkFEcE Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-rscale-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:21:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions Working Group of the IETF. Title : Non-Gregorian Recurrence Rules in iCalendar Authors : Cyrus Daboo Gregory Yakushev Filename : draft-ietf-calext-rscale-03.txt Pages : 19 Date : 2015-01-07 Abstract: This document defines extensions to iCalendar (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how CalDAV (RFC 4791) servers and clients can be extended to support these new recurrence rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-rscale/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-calext-rscale-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 7 07:26:02 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1560D1A87DE for ; Wed, 7 Jan 2015 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymJyA9c8nBg7 for ; Wed, 7 Jan 2015 07:25:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27811A8736 for ; Wed, 7 Jan 2015 07:25:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 17531820BAA for ; Wed, 7 Jan 2015 10:25:51 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGAaV3RLw7il for ; Wed, 7 Jan 2015 10:25:50 -0500 (EST) Received: from [17.45.162.254] (unknown [17.45.162.254]) by daboo.name (Postfix) with ESMTPSA id 44A2C820B9B for ; Wed, 7 Jan 2015 10:25:50 -0500 (EST) Date: Wed, 07 Jan 2015 10:25:46 -0500 From: Cyrus Daboo To: calsify@ietf.org Message-ID: In-Reply-To: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> References: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=265 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/1SlwlfYoDc67ZzQctWN3oQ1FrYg Subject: Re: [calsify] I-D Action: draft-ietf-calext-rscale-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:25:54 -0000 Hi folks, A new version of the draft has been posted to address Donald's recent comments. It also clarifies the interaction with VTIMEZONE (following up on recent comments by Jonathan Lennox). The changes are to the Abstract and Section 1 only. -- Cyrus Daboo From nobody Wed Jan 7 07:42:04 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717151A9121 for ; Wed, 7 Jan 2015 07:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EuIr7Nu_YMC for ; Wed, 7 Jan 2015 07:41:54 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FAE1A90EC for ; Wed, 7 Jan 2015 07:41:53 -0800 (PST) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t07Ffhwh004844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jan 2015 10:41:44 -0500 Message-ID: <54AD53B7.6000109@andrew.cmu.edu> Date: Wed, 07 Jan 2015 10:41:43 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.7.152422 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/nMj9vWoWUT8LLkN1IUab6mqU7Zc Subject: Re: [calsify] I-D Action: draft-ietf-calext-rscale-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:42:00 -0000 On 01/07/2015 10:25 AM, Cyrus Daboo wrote: > Hi folks, > A new version of the draft has been posted to address Donald's recent > comments. It also clarifies the interaction with VTIMEZONE (following > up on recent comments by Jonathan Lennox). The changes are to the > Abstract and Section 1 only. > Hi Cyrus, Was Updates: 4791, 5546 removed from the boilerplate intentionally, or was is an xml2rfc hiccup? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Jan 7 07:44:07 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77321A9131 for ; Wed, 7 Jan 2015 07:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4uqZartgwgr for ; Wed, 7 Jan 2015 07:44:03 -0800 (PST) Received: from smtp10.server.rpi.edu (smtp10.server.rpi.edu [128.113.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0391A9128 for ; Wed, 7 Jan 2015 07:44:03 -0800 (PST) Received: from smtp-auth1.server.rpi.edu (smtp-auth1.server.rpi.edu [128.113.2.231]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id t07Fi1DG032652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jan 2015 10:44:01 -0500 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id 74E305822F; Wed, 7 Jan 2015 10:44:01 -0500 (EST) Received: from EX14CAS1.win.rpi.edu (ex14cas1.win.rpi.edu [128.113.5.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPS id 63B0D5807D; Wed, 7 Jan 2015 10:44:01 -0500 (EST) Received: from EX14MB4.win.rpi.edu ([169.254.4.166]) by EX14CAS1.win.rpi.edu ([128.113.5.97]) with mapi id 14.03.0210.002; Wed, 7 Jan 2015 10:44:01 -0500 From: "Schwartz, Gary" To: "Anganes, Amanda L" , "calsify@ietf.org" Thread-Topic: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 Thread-Index: AQHQG7x2t0iihNy4Pk6dfdvI4KT6WZy06an+ Date: Wed, 7 Jan 2015 15:44:00 +0000 Message-ID: <920205ED05CEC745B445A7076A15BE1689895AA8@ex14mb4.win.rpi.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.113.124.116] Content-Type: multipart/alternative; boundary="_000_920205ED05CEC745B445A7076A15BE1689895AA8ex14mb4winrpied_" MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-CanIt-Incident-Id: 03NB3I16F X-CanIt-Geo: ip=128.113.5.97; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/87W7l5j9rc9O4R8WFFk6Zs44FU4 Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:44:05 -0000 --_000_920205ED05CEC745B445A7076A15BE1689895AA8ex14mb4winrpied_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support adopting this document. Gary Schwartz Director, Communications & Middleware Technologies Rensselaer Polytechnic Institute ________________________________ From: calsify [calsify-bounces@ietf.org] on behalf of Anganes, Amanda L [aa= nganes@mitre.org] Sent: Friday, December 19, 2014 1:49 PM To: calsify@ietf.org Subject: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-= 05 Greetings, This is a call for comments on the adoption of draft-daboo-calendar-availab= ility-05 as an official Calendering Extensions Working Group draft. Due to = the holiday season, this call for adoption will run a bit longer =96 please= comment by January 16th. Thanks, Amanda & Donald --_000_920205ED05CEC745B445A7076A15BE1689895AA8ex14mb4winrpied_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support adopting this document.

Gary Schwartz
Director, Communications & Middleware Technologies
Rensselaer Polytechnic Institute
From: calsify [calsify-bounces@ietf.org] = on behalf of Anganes, Amanda L [aanganes@mitre.org]
Sent: Friday, December 19, 2014 1:49 PM
To: calsify@ietf.org
Subject: [calsify] Call for WG Adoption: draft-daboo-calendar-availa= bility-05

Greetings,

This is a call for comments on the adoption of draft-daboo-calendar-av= ailability-05 as an official Calendering Extensions Working Group draft. Du= e to the holiday season, this call for adoption will run a bit longer =96 p= lease comment by January 16th.

Thanks,

Amanda & Donald

--_000_920205ED05CEC745B445A7076A15BE1689895AA8ex14mb4winrpied_-- From nobody Wed Jan 7 07:44:40 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D0D1A9138 for ; Wed, 7 Jan 2015 07:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDQ6JonSuEpA for ; Wed, 7 Jan 2015 07:44:33 -0800 (PST) Received: from smtp10.server.rpi.edu (smtp10.server.rpi.edu [128.113.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 446BD1A9136 for ; Wed, 7 Jan 2015 07:44:33 -0800 (PST) Received: from smtp-auth1.server.rpi.edu (route.canit.rpi.edu [128.113.2.231]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id t07FiVJJ000378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jan 2015 10:44:32 -0500 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id CCC6058234; Wed, 7 Jan 2015 10:44:31 -0500 (EST) Received: from EX14CAS1.win.rpi.edu (ex14cas1.win.rpi.edu [128.113.5.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPS id BEA6A58232; Wed, 7 Jan 2015 10:44:31 -0500 (EST) Received: from EX14MB4.win.rpi.edu ([169.254.4.166]) by EX14CAS1.win.rpi.edu ([128.113.5.97]) with mapi id 14.03.0210.002; Wed, 7 Jan 2015 10:44:31 -0500 From: "Schwartz, Gary" To: "Anganes, Amanda L" , "calsify@ietf.org" Thread-Topic: Call for WG Adoption: draft-daboo-icalendar-extensions-08 Thread-Index: AQHQG7yaQn7ZIG96S0CU2tssenhpB5y06hqo Date: Wed, 7 Jan 2015 15:44:31 +0000 Message-ID: <920205ED05CEC745B445A7076A15BE1689895AB8@ex14mb4.win.rpi.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.113.124.116] Content-Type: multipart/alternative; boundary="_000_920205ED05CEC745B445A7076A15BE1689895AB8ex14mb4winrpied_" MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-CanIt-Incident-Id: 03NB3Iw7l X-CanIt-Geo: ip=128.113.5.97; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/oh5SzJE_cy24TP1P5lvkyhjz_zU Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:44:36 -0000 --_000_920205ED05CEC745B445A7076A15BE1689895AB8ex14mb4winrpied_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support adopting this document. Gary Schwartz Director, Communications & Middleware Technologies Rensselaer Polytechnic Institute ________________________________ From: calsify [calsify-bounces@ietf.org] on behalf of Anganes, Amanda L [aa= nganes@mitre.org] Sent: Friday, December 19, 2014 1:50 PM To: calsify@ietf.org Subject: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-0= 8 Greetings, This is a call for comments on the adoption of draft-daboo-icalendar-extens= ions-08 as an official Calendering Extensions Working Group draft. Due to t= he holiday season, this call for adoption will run a bit longer =96 please = comment by January 16th. Thanks, Amanda & Donald --_000_920205ED05CEC745B445A7076A15BE1689895AB8ex14mb4winrpied_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support adopting this= document.

Gary Schwartz
Director, Communications & = Middleware Technologies
Rensselaer Polytechnic Institut= e
From: calsify [calsify-bounces@ietf.org] = on behalf of Anganes, Amanda L [aanganes@mitre.org]
Sent: Friday, December 19, 2014 1:50 PM
To: calsify@ietf.org
Subject: [calsify] Call for WG Adoption: draft-daboo-icalendar-exten= sions-08

Greetings,

This is a call for comments on the adoption of draft-daboo-icalen= dar-extensions-08 as an official Calendering Extensions Working Group = draft. Due to the holiday season, this call for adoption will run a bit lon= ger =96 please comment by January 16th.

Thanks,

Amanda & Donald

--_000_920205ED05CEC745B445A7076A15BE1689895AB8ex14mb4winrpied_-- From nobody Wed Jan 7 07:47:59 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1571A8845 for ; Wed, 7 Jan 2015 07:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNR98MSA7lgU for ; Wed, 7 Jan 2015 07:47:53 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428381A9127 for ; Wed, 7 Jan 2015 07:47:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 83E86821672; Wed, 7 Jan 2015 10:47:50 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8fQ7JFq0wGU; Wed, 7 Jan 2015 10:47:50 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 41813821667; Wed, 7 Jan 2015 10:47:48 -0500 (EST) Date: Wed, 07 Jan 2015 10:47:47 -0500 From: Cyrus Daboo To: Ken Murchison , calsify@ietf.org Message-ID: <557D68689BE39CC9434C97CB@caldav.corp.apple.com> In-Reply-To: <54AD53B7.6000109@andrew.cmu.edu> References: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> <54AD53B7.6000109@andrew.cmu.edu> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=696 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ObzxIywB3k0n1MnWh3uR60n-Ot0 Subject: Re: [calsify] I-D Action: draft-ietf-calext-rscale-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:47:54 -0000 Hi Ken, --On January 7, 2015 at 10:41:43 AM -0500 Ken Murchison wrote: > Was Updates: 4791, 5546 removed from the boilerplate intentionally, or > was is an xml2rfc hiccup? Yes - after consultation with our AD (Barry Leiba) I decided that rscale does not "update" those two, but rather "extends" or "clarifies" its use with those specs. In the case of CalDAV it uses existing "extension" mechanisms (namely the presence of a new property). So I just left iCal, xCal and jCal in the "Updates" list since rscale does redefine the syntax elements in those specs in a manner that is outside of any normal extension mechanism that those specs provide. -- Cyrus Daboo From nobody Wed Jan 7 07:50:19 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5385B1A9127 for ; Wed, 7 Jan 2015 07:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdzXnS7gEHac for ; Wed, 7 Jan 2015 07:50:10 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FB71A90AE for ; Wed, 7 Jan 2015 07:50:10 -0800 (PST) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t07Fo7m0005359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jan 2015 10:50:07 -0500 Message-ID: <54AD55AF.3060602@andrew.cmu.edu> Date: Wed, 07 Jan 2015 10:50:07 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <20150107152116.4199.45568.idtracker@ietfa.amsl.com> <54AD53B7.6000109@andrew.cmu.edu> <557D68689BE39CC9434C97CB@caldav.corp.apple.com> In-Reply-To: <557D68689BE39CC9434C97CB@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.7.153923 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/xploN0CByzUKClxbaJQTRmDt_-Q Subject: Re: [calsify] I-D Action: draft-ietf-calext-rscale-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:50:15 -0000 On 01/07/2015 10:47 AM, Cyrus Daboo wrote: > Hi Ken, > > --On January 7, 2015 at 10:41:43 AM -0500 Ken Murchison > wrote: > >> Was Updates: 4791, 5546 removed from the boilerplate intentionally, or >> was is an xml2rfc hiccup? > > Yes - after consultation with our AD (Barry Leiba) I decided that > rscale does not "update" those two, but rather "extends" or > "clarifies" its use with those specs. In the case of CalDAV it uses > existing "extension" mechanisms (namely the presence of a new > property). So I just left iCal, xCal and jCal in the "Updates" list > since rscale does redefine the syntax elements in those specs in a > manner that is outside of any normal extension mechanism that those > specs provide. Makes sense. Thanks for the clarification. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Jan 7 08:02:12 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA2C1A9138 for ; Wed, 7 Jan 2015 08:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfVc3qdFvIuy for ; Wed, 7 Jan 2015 08:02:01 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF48E1A0070 for ; Wed, 7 Jan 2015 08:02:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0BF76821B09; Wed, 7 Jan 2015 11:02:01 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0L4JOxAscZu; Wed, 7 Jan 2015 11:02:00 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 0E601821AFE; Wed, 7 Jan 2015 11:01:58 -0500 (EST) Date: Wed, 07 Jan 2015 11:01:57 -0500 From: Cyrus Daboo To: "Anganes, Amanda L" , calsify@ietf.org Message-ID: <9ADA89461E9BF6B5AD8F6AAB@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=465 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/iqK3MJdXKLqTZsgmgZ9llZSGdik Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:02:06 -0000 Hi Amanda, --On December 19, 2014 at 6:49:04 PM +0000 "Anganes, Amanda L"=20 wrote: > This is a call for comments on the adoption of > draft-daboo-calendar-availability-05 as an official Calendering > Extensions Working Group draft. Due to the holiday season, this call for > adoption will run a bit longer =E2=80=93 please comment by January 16th. > FYI I am a co-author of that document, and I do support its adoption by=20 Calext. --=20 Cyrus Daboo From nobody Wed Jan 7 08:02:35 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5E1A914D for ; Wed, 7 Jan 2015 08:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0N82zmLeJaD for ; Wed, 7 Jan 2015 08:02:28 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55411A0070 for ; Wed, 7 Jan 2015 08:02:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1B343821B4C; Wed, 7 Jan 2015 11:02:28 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgwURqSYF0no; Wed, 7 Jan 2015 11:02:27 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 0850A821B41; Wed, 7 Jan 2015 11:02:26 -0500 (EST) Date: Wed, 07 Jan 2015 11:02:25 -0500 From: Cyrus Daboo To: "Anganes, Amanda L" , calsify@ietf.org Message-ID: <68831C409C8343C6B6E54E19@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=465 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/8IFscTa1L1Mj-laIz6ob29yxLBo Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:02:32 -0000 Hi Amanda, --On December 19, 2014 at 6:50:05 PM +0000 "Anganes, Amanda L"=20 wrote: > This is a call for comments on the adoption of > draft-daboo-icalendar-extensions-08 as an official Calendering Extensions > Working Group draft. Due to the holiday season, this call for adoption > will run a bit longer =E2=80=93 please comment by January 16th. > FYI I am a co-author of that document, and I do support its adoption by=20 Calext. --=20 Cyrus Daboo From nobody Wed Jan 7 08:06:56 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0533F1A8895 for ; Wed, 7 Jan 2015 08:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu5wdG07Pp3E for ; Wed, 7 Jan 2015 08:06:52 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41B21A8866 for ; Wed, 7 Jan 2015 08:06:51 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id z60so1041772qgd.23 for ; Wed, 07 Jan 2015 08:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Rlw9J7Te3kRnN0gzGrrGfXlnfKyJca0IJV2vXqljJR4=; b=kGz319I4e2+Zr4Xp4XkbiuGZ4q/mlTqYLY37vsEqlEJk/NMw5GAPsh05D5VSkSPg+/ YY8TeaoKPrjs5fgGXpXKK8u/TZTD5SoePNpQ1CzkBFhJfQh4jbqHpr+AoqDD1RtCLclY IMIm18Uca3Xy3q/aSRBeA1AvBfrwxkSXI2746fufOgN+ESEtGREMi1FMEVlGp7BXSC9q dmFsInmHeTk4wZuh6yLi/wLnu67xnCsPitkizVI2Edx7CjftBtJjU9Xznn19EKj5Fi+u INI+sWv//uwvU58k2Iz6kLAEyxLHd86hJRQz6gNMCT7p40ah3TMfrPoCrq1DSW7Z22/E MsYw== X-Received: by 10.140.28.200 with SMTP id 66mr5653223qgz.16.1420646808045; Wed, 07 Jan 2015 08:06:48 -0800 (PST) Received: from ?IPv6:2620:0:2820:2:d555:cb72:7565:519a? ([2620:0:2820:2:d555:cb72:7565:519a]) by mx.google.com with ESMTPSA id r2sm1657621qah.1.2015.01.07.08.06.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2015 08:06:47 -0800 (PST) Message-ID: <54AD5995.2070405@gmail.com> Date: Wed, 07 Jan 2015 11:06:45 -0500 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020601020402060901060501" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/h9BODQWm1gwmsdD-COmERWeCbeg Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:06:54 -0000 This is a multi-part message in MIME format. --------------020601020402060901060501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this specification. On 12/19/2014 01:49 PM, Anganes, Amanda L wrote: > Greetings, > > This is a call for comments on the adoption of > draft-daboo-calendar-availability-05 as an official Calendering > Extensions Working Group draft. Due to the holiday season, this call > for adoption will run a bit longer – please comment by January 16th. > > Thanks, > > Amanda & Donald > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------020601020402060901060501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I support adoption of this specification.

On 12/19/2014 01:49 PM, Anganes, Amanda L wrote:
Greetings,

This is a call for comments on the adoption of draft-daboo-calendar-availability-05 as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer – please comment by January 16th.

Thanks,

Amanda & Donald



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

--------------020601020402060901060501-- From nobody Wed Jan 7 08:07:42 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591131A8860 for ; Wed, 7 Jan 2015 08:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOJ-yu-O2jKp for ; Wed, 7 Jan 2015 08:07:28 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EAA1A9166 for ; Wed, 7 Jan 2015 08:07:27 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id n4so3247633qaq.6 for ; Wed, 07 Jan 2015 08:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=MNvOeuv94fT//t1U9kRudyHN8dHpsQu1nRS8dijAoPg=; b=EQd1uZXApNGHfCqdN8m1w1/+uhlVBhF5ErTuBOvPFlvVRgyLlv8N1pOQD+BKSa1wuF qAosGdRIBgZ2tv3txEBXd0aMiGSaijeGK6ZU7xqrc93fdsGFprtmsC/dPork4s47ZqpT 30UZoU8jpHLkENxXTg4zF2uFstTyyAGL4Lv7t7as+wNtQGOyV4RgZXPVDZvw9Tqps5MB KyD8snBYuSKKFsSTqrdwdH/M2dwLdH3xfbvF2mR+anv37kjMUykXD5zVy9vQVm+jsaoC PNdtwqdl1LyTeg8hQdC8zuPGxYM1D6s6z12G6nP1yIFO2zTRajPyaTLGaZZU43wcaLfi /SIg== X-Received: by 10.224.43.3 with SMTP id u3mr5999127qae.50.1420646847134; Wed, 07 Jan 2015 08:07:27 -0800 (PST) Received: from ?IPv6:2620:0:2820:2:d555:cb72:7565:519a? ([2620:0:2820:2:d555:cb72:7565:519a]) by mx.google.com with ESMTPSA id p7sm1655650qat.4.2015.01.07.08.07.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2015 08:07:26 -0800 (PST) Message-ID: <54AD59BD.4040108@gmail.com> Date: Wed, 07 Jan 2015 11:07:25 -0500 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050206060801080407090108" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/D_nnFcO5xDtEXghlTfSn20rBqBw Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:07:30 -0000 This is a multi-part message in MIME format. --------------050206060801080407090108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this specification. On 12/19/2014 01:50 PM, Anganes, Amanda L wrote: > Greetings, > > This is a call for comments on the adoption > of draft-daboo-icalendar-extensions-08 as an official Calendering > Extensions Working Group draft. Due to the holiday season, this call > for adoption will run a bit longer – please comment by January 16th. > > Thanks, > > Amanda & Donald > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------050206060801080407090108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I support adoption of this specification.

On 12/19/2014 01:50 PM, Anganes, Amanda L wrote:
Greetings,

This is a call for comments on the adoption of draft-daboo-icalendar-extensions-08 as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer – please comment by January 16th.

Thanks,

Amanda & Donald



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

--------------050206060801080407090108-- From nobody Wed Jan 7 08:10:10 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF71A9127 for ; Wed, 7 Jan 2015 08:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUxig95wympZ for ; Wed, 7 Jan 2015 08:10:06 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8149C1A8860 for ; Wed, 7 Jan 2015 08:09:42 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so1441102wes.13 for ; Wed, 07 Jan 2015 08:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujQxYl112mFboM9xQBVt44sOLwkO3kkAzANODMMLJ4Y=; b=RaO9F/ScJLKWKD4McRG10L1rzRw5dGV+3+pslxG8pnrk3fE1ExaBTAJq3zJXZhuhAM lZ86oQXzEBcc2m2UemTyO5eYCX42xSa/ouoCkiXZ8eXFGVbhQayBHa9KxuG6pgaHhFzw Oh4VS/SndLIMusWiYilzkiiMgMxFJ+8cmO/LiuZhnkNYcSGivHZzB+ZLWh84fzc4ddt/ 8OPAeAMsnMks+iYGQp/kW78nRE9v9ojaBoaYrfF/oDhNd+QqkX/YT+L+q90kHOqxEZrT 5iBzdLznojHaXiOqz2CyZbwP5n6BPk0oQVJSMDszIMVEQ1BK/FRAKKqOKhv4bU11VwgN MKew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ujQxYl112mFboM9xQBVt44sOLwkO3kkAzANODMMLJ4Y=; b=aIC3nWO/ra7vZJOKt8Qi2isjIb9EY+4IurZvoWO4PQZzr3yjv5WzbCi3Lm+l9ocJ7Z VnOxiDilZb/bwDUvD2D92/8+fx4d2dz1lLRCKdbe+H7pYMIVIJvwU96RylkrFZ0K8vBM lCc0ORClzAb8YC72d8wI+y0FY7KQ0XmkWHCMAbSmvv8LefU5YWqpHU3kFQ93fDuoblOg 8Sg8cTccfYpMl8Ns9RN+8AQhV4Br7ENcT9c1ih5vlM/SRh5tluUcvBv8K52psy/FonPm Xsi5fzG2vTkyQ47pwr9qvluMl1pbRaEDos7cuiowfEfDguWNDpmOnOx2ohDti4W/Y33x SWcg== X-Gm-Message-State: ALoCoQkGMMmZA0AjQr6kE8SA9twu7UpTfxtoVZmUqQuUCYU6uo1Hgv8ozV+s58LmUGEKGR+Qx5zI MIME-Version: 1.0 X-Received: by 10.194.94.1 with SMTP id cy1mr7490838wjb.127.1420646981203; Wed, 07 Jan 2015 08:09:41 -0800 (PST) Received: by 10.27.215.201 with HTTP; Wed, 7 Jan 2015 08:09:41 -0800 (PST) In-Reply-To: <54AD5995.2070405@gmail.com> References: <54AD5995.2070405@gmail.com> Date: Wed, 7 Jan 2015 17:09:41 +0100 Message-ID: From: Lucia Fedorova To: Mike Douglass Content-Type: multipart/alternative; boundary=047d7bf0c39aaaaeaf050c12265d Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/B1NIhl1yPmhb2DhsVJeAlfFyUp4 Cc: calsify@ietf.org Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:10:08 -0000 --047d7bf0c39aaaaeaf050c12265d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adoption of this specification. Lucia (Google) On Wed, Jan 7, 2015 at 5:06 PM, Mike Douglass wrote: > I support adoption of this specification. > > On 12/19/2014 01:49 PM, Anganes, Amanda L wrote: > > Greetings, > > This is a call for comments on the adoption of > draft-daboo-calendar-availability-05 as an official Calendering Extension= s > Working Group draft. Due to the holiday season, this call for adoption wi= ll > run a bit longer =E2=80=93 please comment by January 16th. > > Thanks, > > Amanda & Donald > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo= /calsify > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > --047d7bf0c39aaaaeaf050c12265d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adoption of this = specification.
Lucia
(Google)

On Wed, Jan 7, 2015 at 5:0= 6 PM, Mike Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20
I support adoption of this specification.

On 12/19/2014 01:49 PM, Anganes, Amanda L wrote:
=20
Greetings,

This is a call for comments on the adoption of draft-daboo-calendar-availability-05 as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer =E2=80=93 please comment by January 16th.

Thanks,

Amanda & Donald



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


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


--047d7bf0c39aaaaeaf050c12265d-- From nobody Wed Jan 7 08:10:27 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B821A9122 for ; Wed, 7 Jan 2015 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBgYo_1m-lCg for ; Wed, 7 Jan 2015 08:10:22 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED4C1A9170 for ; Wed, 7 Jan 2015 08:09:54 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so1947011wid.12 for ; Wed, 07 Jan 2015 08:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yjg6X8h39UHtsSFLDlEkzJqU1f75sABV70JbvpOTetU=; b=dD/VgMQ3zvuvD1OY1evOuWpvwtTDXq7KzjLMVfOmjOz2jUnnX9kEh/Ma0AMDrmhNL9 E68a0vQp99CujPnyQyEopJqMXHcIpr8cmecr037Jsz01Wm+kZhh4uVp/eIUHtUz4zY9n qy8CLT+hDsl/9hEE5ul8y44R9l5U4nmOODF1Tf/MtOS/vq71JkfGci9ijFR8rZUe0ZKi n9J2aiECjk3mN3Muvz9Ac9utTym3A1L7ypq6ncVtlE35UBxdf02nNxVZJHITH4aQQvqN nrwnB//bmTydn2qVtT4qyqzl8viUgtElHXjsWctW1zE0sDuW0wpIXpVTDZvPHbPRFKX5 a2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yjg6X8h39UHtsSFLDlEkzJqU1f75sABV70JbvpOTetU=; b=BqfIkv750RT4P9C238g0BQXp1QctaGJNDF6N1tfN4Xbv8lKyLjcHsWLMadX3LXAu7B nBvt0LpcfRZE/MhRNcpgj++PKbKqb0RvGc+UnyGRr8GdiFXB2aAywxfDjFfxa4+sMJY+ I89Zrc/GHJfohw29cvEwGH7P29nEVvwU0Tjd2eRK4cb6FNYVJ1jq4LyOcE8+1ohOkH6Z ED2etmwoA2nG35ZMA+VYPkJlu4+6fWLZoPZHz2RPS7k8Xs8ew6pTTwD/yB0ZwC3FfUAR vXUadZh3EGhsC/hzlpWZuw61YHAkoRWU65KP9k5THhKJlt0+Sv0R2D38+Eo/JHjL7kae TtBA== X-Gm-Message-State: ALoCoQlijrCHz7wZKZSlRlbaOxfLkyM6pxuc4UW21MSLxAXxBaIs5ni0q0Dr0Le1/auSuUuukTT0 MIME-Version: 1.0 X-Received: by 10.180.36.226 with SMTP id t2mr50099589wij.16.1420646992920; Wed, 07 Jan 2015 08:09:52 -0800 (PST) Received: by 10.27.215.201 with HTTP; Wed, 7 Jan 2015 08:09:52 -0800 (PST) In-Reply-To: <54AD59BD.4040108@gmail.com> References: <54AD59BD.4040108@gmail.com> Date: Wed, 7 Jan 2015 17:09:52 +0100 Message-ID: From: Lucia Fedorova To: Mike Douglass Content-Type: multipart/alternative; boundary=e89a8f642c9e5d7077050c122780 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/eYDyD2aQ4U_JfMa-FWFzxv3tLIU Cc: calsify@ietf.org Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:10:24 -0000 --e89a8f642c9e5d7077050c122780 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adoption of this specification. Lucia (Google) On Wed, Jan 7, 2015 at 5:07 PM, Mike Douglass wrote: > I support adoption of this specification. > > On 12/19/2014 01:50 PM, Anganes, Amanda L wrote: > > Greetings, > > This is a call for comments on the adoption > of draft-daboo-icalendar-extensions-08 as an official Calendering > Extensions Working Group draft. Due to the holiday season, this call for > adoption will run a bit longer =E2=80=93 please comment by January 16th. > > Thanks, > > Amanda & Donald > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo= /calsify > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > --e89a8f642c9e5d7077050c122780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adoption of this = specification.
Lucia
(Google)

On Wed, Jan 7, 2015 at 5:0= 7 PM, Mike Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20
I support adoption of this specification.

On 12/19/2014 01:50 PM, Anganes, Amanda L wrote:
=20
Greetings,

This is a call for comments on the adoption of=C2=A0draft-daboo-icalendar-extensions-08=C2=A0as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer =E2=80=93 pl= ease comment by January 16th.

Thanks,

Amanda & Donald



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


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


--e89a8f642c9e5d7077050c122780-- From nobody Wed Jan 7 09:37:22 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A1D1A8A80; Mon, 5 Jan 2015 13:13:32 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "From" X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_FROM=1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYfy5lne31_G; Mon, 5 Jan 2015 13:13:29 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id E082D1A8A6A; Mon, 5 Jan 2015 13:13:28 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTPA id 49C7D132E2; Mon, 5 Jan 2015 16:13:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21674.65143.707505.318547@compute03.cs.columbia.edu> Date: Mon, 5 Jan 2015 16:13:27 -0500 To: tzdist@ietf.org,calsify@ietf.org X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/9kmC4eNwb_ffpIDk0XR3rOc3G1U X-Mailman-Approved-At: Wed, 07 Jan 2015 09:37:21 -0800 Subject: [calsify] How should tzdist support rscale? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:13:32 -0000 (Cc'ing both tzdist and calsify because the issue is about the interaction of specs defined by the two groups...please trim to one or the other if the topic ends up being unique to that group.) A question recently occured to me about the interaction of rscale and tzdist. Should it be possible for a VTIMEZONE -- either inline in an iCalendar document, or distributed by tzdist -- to use an RSCALE? There are some natural use cases for this -- Iran uses the Persian calendar to set its DST observances, and Israel used the Hebrew calendar from 2005-2012. Right now the IANA tzdata just expands non-Gregorian rules to a list of dates, but in principle, RSCALE would be a much more natural (and compact) way of representing rules like these. However, tzdist has no way to negotiate the use of iCalendar extensions. Should one be defined? For that matter, the rscale draft doesn't talk about its use in VTIMEZONE at all (indeed, it asserts that VTIMEZONEs are always specified in Gregorian time). Should it? -- Jonathan Lennox lennox@cs.columbia.edu From nobody Wed Jan 7 10:22:03 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBFD1A00F6; Wed, 7 Jan 2015 10:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qma6BVOaveJ6; Wed, 7 Jan 2015 10:21:58 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id A91A11A008A; Wed, 7 Jan 2015 10:21:58 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTPA id 79D58131E1; Wed, 7 Jan 2015 13:21:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21677.31042.586794.7773@compute03.cs.columbia.edu> Date: Wed, 7 Jan 2015 13:21:54 -0500 From: Jonathan Lennox To: Cyrus Daboo In-Reply-To: <258A901779432BE2E9A929AD@caldav.corp.apple.com> References: <21675.2462.186194.702206@compute03.cs.columbia.edu> <258A901779432BE2E9A929AD@caldav.corp.apple.com> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ZHltPgm3DLS7eUr7oK3A1NurCjo Cc: tzdist@ietf.org, calsify@ietf.org Subject: Re: [calsify] [Tzdist] How should tzdist support rscale? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 18:22:01 -0000 On Tuesday, January 6 2015, "Cyrus Daboo" wrote to "Jonathan Lennox, tzdist@ietf.org, calsify@ietf.org" saying: > Hi Jonathan, > > --On January 5, 2015 at 5:01:02 PM -0500 Jonathan Lennox > wrote: > > > A question recently occured to me about the interaction of rscale and > > tzdist. > > > > Should it be possible for a VTIMEZONE -- either inline in an iCalendar > > document, or distributed by tzdist -- to use an RSCALE? > > If a time zone were indeed defined in terms of a non-Gregorian recurrence > then it would seem reasonable to support that. > > > There are some natural use cases for this -- Iran uses the Persian > > calendar to set its DST observances, and Israel used the Hebrew calendar > > from 2005-2012. Right now the IANA tzdata just expands non-Gregorian > > rules to a list of dates, but in principle, RSCALE would be a much more > > natural (and compact) way of representing rules like these. > > > > However, tzdist has no way to negotiate the use of iCalendar extensions. > > Should one be defined? > > If tz data publishers actually start wantint to produce data using > non-Gregorian rules, then we can easily define an extension to the > capabilities response to indicate that is an option. > > > For that matter, the rscale draft doesn't talk about its use in VTIMEZONE > > at all (indeed, it asserts that VTIMEZONEs are always specified in > > Gregorian time). Should it? > > Actually the rscale document only mentions time zones once in Section 1 - > and there it states that time zone rules (i.e., what comes from a > publisher) is specified in terms of the Gregorian calendar - that does not > imply VTIMEZONE itself is limited to Gregorian rules - just that no time > zone data uses non-Gregorian. If you think that text needs re-wording to > clarify that, I can certainly change it. Yes, I think that the rscale draft should be clarified to note that RSCALE can appear in an RRULE in any iCalendar context where RRULE is allowed, not just VEVENT, and in particular it can appear in VTIMEZONE. > At this point, I think the use of non-Gregorian rules in VTIMEZONE should > not be ruled out, but tzdist does not need to support it until we have > publishers actually wanting to use it. Of course at that point things will > get tricky for the publisher as they will want to keep the Gregorian rules > around for backwards compatibility. Yes -- for tzdist I'm mostly thinking about this as an exercise to make sure we have backward-compatible future extensibility defined correctly. If we understand how we would do this if it's ever needed, I think we're in pretty good shape. That said, I think tzdist in the meantime should have some statement saying that RSCALE MUST NOT be used unless support for it is negotated through some as-yet undefined mechanism. -- Jonathan Lennox lennox@cs.columbia.edu From nobody Wed Jan 7 11:21:23 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A031A1A22; Wed, 7 Jan 2015 11:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYth93LxDhuw; Wed, 7 Jan 2015 11:21:06 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id E542F1A1A09; Wed, 7 Jan 2015 11:21:05 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTPA id 51BE01351E; Wed, 7 Jan 2015 14:21:04 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21677.34592.655837.458072@compute03.cs.columbia.edu> Date: Wed, 7 Jan 2015 14:21:04 -0500 From: Jonathan Lennox To: Cyrus Daboo , tzdist@ietf.org, calsify@ietf.org In-Reply-To: <21677.31042.586794.7773@compute03.cs.columbia.edu> References: <21675.2462.186194.702206@compute03.cs.columbia.edu> <258A901779432BE2E9A929AD@caldav.corp.apple.com> <21677.31042.586794.7773@compute03.cs.columbia.edu> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/zMlEuymDZzBW7yz_HF2cKad0WAc Subject: Re: [calsify] [Tzdist] How should tzdist support rscale? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 19:21:14 -0000 On Wednesday, January 7 2015, "Jonathan Lennox" wrote to "Cyrus Daboo, tzdist@ietf.org, calsify@ietf.org" saying: > > Actually the rscale document only mentions time zones once in Section 1 - > > and there it states that time zone rules (i.e., what comes from a > > publisher) is specified in terms of the Gregorian calendar - that does not > > imply VTIMEZONE itself is limited to Gregorian rules - just that no time > > zone data uses non-Gregorian. If you think that text needs re-wording to > > clarify that, I can certainly change it. > > Yes, I think that the rscale draft should be clarified to note that RSCALE > can appear in an RRULE in any iCalendar context where RRULE is allowed, not > just VEVENT, and in particular it can appear in VTIMEZONE. The new text in version -03 of rscale satisfies this nicely. Thank you! -- Jonathan Lennox lennox@cs.columbia.edu From nobody Fri Jan 16 09:22:26 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C011AD0F0 for ; Fri, 16 Jan 2015 09:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKhDuhWqO_l9 for ; Fri, 16 Jan 2015 09:22:21 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641C11ACEA4 for ; Fri, 16 Jan 2015 09:22:21 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-01v.sys.comcast.net with comcast id ghMa1p0012XD5SV01hNLnC; Fri, 16 Jan 2015 17:22:20 +0000 Received: from MacPro12.local ([73.199.70.120]) by resomta-ch2-20v.sys.comcast.net with comcast id ghNK1p00b2bi90x01hNL2d; Fri, 16 Jan 2015 17:22:20 +0000 Message-ID: <54B948CD.2030304@CoxSoftwareArchitects.com> Date: Fri, 16 Jan 2015 12:22:21 -0500 From: William Cox User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: calsify@ietf.org References: <54AD5995.2070405@gmail.com> In-Reply-To: <54AD5995.2070405@gmail.com> Content-Type: multipart/alternative; boundary="------------050002090709090908090708" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1421428940; bh=kJWOsNquAdFa8zT/hC3k3hjrH5zWKPQKNdUvlk7yFD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NgaxPmkN2o18dsX7OSnVK0Gft/WXrILnJ7g1/edFxRZZrDFASL3VeNNb7q1r5qez0 pQ/AqiRAA5aI1O/7pSc82vo11td/R5j8McSAXriG03KYPaZkzhBCFqN5XivQIQZoa2 HW6AT8B8zpH8WMN8UrJ4hLxwviS6VBz4tjokzBvzQgkBaO+7BWY9C1d4BDN9SXOaDo mRsBjvppNjs6Dri7afs0pt00DD1wXz+UAYmE+tCHQEuZAP83Szd4lTDLKm6FWOUKxO cSp5caLVDIknNRLxM4bGG98mB186i/eh3tbQhdDQhwbA9T6Gc4NeIHAX6Y4BcoKT4d UGalMPDPKVLTQ== Archived-At: Subject: Re: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:22:24 -0000 This is a multi-part message in MIME format. --------------050002090709090908090708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this specification. bill cox -- *William Cox* Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile On 1/7/15 11:06 AM, Mike Douglass wrote: > I support adoption of this specification. > > On 12/19/2014 01:49 PM, Anganes, Amanda L wrote: >> Greetings, >> >> This is a call for comments on the adoption of >> draft-daboo-calendar-availability-05 as an official Calendering >> Extensions Working Group draft. Due to the holiday season, this call >> for adoption will run a bit longer – please comment by January 16th. >> >> Thanks, >> >> Amanda & Donald >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------050002090709090908090708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I support adoption of this specification.

bill cox
--

William Cox 

Email: wtcox@CoxSoftwareArchitects.com 

Web: http://www.CoxSoftwareArchitects.com 

+1 862 485 3696 mobile


On 1/7/15 11:06 AM, Mike Douglass wrote:
I support adoption of this specification.

On 12/19/2014 01:49 PM, Anganes, Amanda L wrote:
Greetings,

This is a call for comments on the adoption of draft-daboo-calendar-availability-05 as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer – please comment by January 16th.

Thanks,

Amanda & Donald



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




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

--------------050002090709090908090708-- From nobody Fri Jan 16 09:22:48 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E91AD151 for ; Fri, 16 Jan 2015 09:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61m9rFkAUlfe for ; Fri, 16 Jan 2015 09:22:41 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2521AD0EA for ; Fri, 16 Jan 2015 09:22:40 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with comcast id ghMY1p0082GyhjZ01hNgEb; Fri, 16 Jan 2015 17:22:40 +0000 Received: from MacPro12.local ([73.199.70.120]) by resomta-ch2-09v.sys.comcast.net with comcast id ghNf1p00R2bi90x01hNfdg; Fri, 16 Jan 2015 17:22:40 +0000 Message-ID: <54B948E1.1000802@CoxSoftwareArchitects.com> Date: Fri, 16 Jan 2015 12:22:41 -0500 From: William Cox User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: calsify@ietf.org References: <54AD59BD.4040108@gmail.com> In-Reply-To: <54AD59BD.4040108@gmail.com> Content-Type: multipart/alternative; boundary="------------000907070504000405050707" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1421428960; bh=s1F12xZQXxXhWbd5s7bs3bXPbKmBpqAp9faQX6dyOuA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wHUSW9bH6gfRAweuLkTWBqt2NJLpgg2i2gZ6R3kb0khKebI7f369GlggIZUhupD/R mGnSSZlBXOrlidU6HUdKYBs7Pv0JTjBOaz6KFd20uG8/s4Nen/mgvFhqellWZxr98Y A9/eBwB+BWfGQnZUligxF5ZwDAmsFDT/g9SLhGPOHr4fJ8h7VBtWbYno7L+SF+ho0z fwvVZKjq3Ac0oRsJ8WxN5JGRtsjSIuzioHbR1x7PDK+5YKJCqBz1+3Lnq3Zqm3UXSW vvDEdbCoEoRyhQuko2cRaL6TViLsB8Va+iyHOxJy+IZ06iLB6yY0xc/FeH8rmyLMXd PgnjkiJtNTMSw== Archived-At: Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-08 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:22:43 -0000 This is a multi-part message in MIME format. --------------000907070504000405050707 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this specification. bill cox -- *William Cox* Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile On 1/7/15 11:07 AM, Mike Douglass wrote: > I support adoption of this specification. > > On 12/19/2014 01:50 PM, Anganes, Amanda L wrote: >> Greetings, >> >> This is a call for comments on the adoption >> of draft-daboo-icalendar-extensions-08 as an official Calendering >> Extensions Working Group draft. Due to the holiday season, this call >> for adoption will run a bit longer – please comment by January 16th. >> >> Thanks, >> >> Amanda & Donald >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------000907070504000405050707 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I support adoption of this specification.

bill cox
--

William Cox 

Email: wtcox@CoxSoftwareArchitects.com 

Web: http://www.CoxSoftwareArchitects.com 

+1 862 485 3696 mobile


On 1/7/15 11:07 AM, Mike Douglass wrote:
I support adoption of this specification.

On 12/19/2014 01:50 PM, Anganes, Amanda L wrote:
Greetings,

This is a call for comments on the adoption of draft-daboo-icalendar-extensions-08 as an official Calendering Extensions Working Group draft. Due to the holiday season, this call for adoption will run a bit longer – please comment by January 16th.

Thanks,

Amanda & Donald



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




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

--------------000907070504000405050707-- From nobody Mon Jan 26 09:23:43 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ADF1ACD39 for ; Mon, 26 Jan 2015 09:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN4jb8sCLMny for ; Mon, 26 Jan 2015 09:23:36 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id A859B1A90C5 for ; Mon, 26 Jan 2015 09:23:27 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 407B933E047 for ; Mon, 26 Jan 2015 12:23:27 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 376F03AE03E for ; Mon, 26 Jan 2015 12:23:27 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.251]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0224.002; Mon, 26 Jan 2015 12:23:26 -0500 From: "Anganes, Amanda L" To: "Anganes, Amanda L" , "calsify@ietf.org" Thread-Topic: icalendar-extensions-08 adopted as WG Draft Thread-Index: AQHQOYzLcUVHxT9G9EOyvnccJXcIww== Date: Mon, 26 Jan 2015 17:23:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.146.16.28] Content-Type: multipart/alternative; boundary="_000_D0EBE1DC274B4aanganesmitreorg_" MIME-Version: 1.0 Archived-At: Subject: [calsify] icalendar-extensions-08 adopted as WG Draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 17:23:39 -0000 --_000_D0EBE1DC274B4aanganesmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, Based on the positive feedback we've received, draft-daboo-icalendar-extens= ions-08 will be accepted as an official WG draft. Cheers, Amanda & Donald From: , "Anganes, Amanda L" > Date: Friday, December 19, 2014 at 1:50 PM To: "calsify@ietf.org" > Subject: [calsify] Call for WG Adoption: draft-daboo-icalendar-extensions-0= 8 Greetings, This is a call for comments on the adoption of draft-daboo-icalendar-extens= ions-08 as an official Calendering Extensions Working Group draft. Due to t= he holiday season, this call for adoption will run a bit longer =96 please = comment by January 16th. Thanks, Amanda & Donald --_000_D0EBE1DC274B4aanganesmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <08C89334BC3A914C8AEB7774577E354B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Hello,

Based on the positive feedback we've received, draft-daboo-icalendar-e= xtensions-08 will be accepted as an official WG draft. 

Cheers,

Amanda & Donald

From: <Anganes>, "Angane= s, Amanda L" <aanganes@mitre.= org>
Date: Friday, December 19, 2014 at = 1:50 PM
To: "calsify@ietf.org" <calsify@ietf.org>
Subject: [calsify] Call for WG Adop= tion: draft-daboo-icalendar-extensions-08

Greetings,

This is a call for comments on the adoption of draft-daboo-icalen= dar-extensions-08 as an official Calendering Extensions Working Group = draft. Due to the holiday season, this call for adoption will run a bit lon= ger =96 please comment by January 16th.

Thanks,

Amanda & Donald

 --_000_D0EBE1DC274B4aanganesmitreorg_-- From nobody Mon Jan 26 09:24:34 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67931ACD34 for ; Mon, 26 Jan 2015 09:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y4CAzetw4TU for ; Mon, 26 Jan 2015 09:24:26 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 052121ACD3C for ; Mon, 26 Jan 2015 09:24:08 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B03683AE0A8 for ; Mon, 26 Jan 2015 12:24:07 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id A7DBC33203F for ; Mon, 26 Jan 2015 12:24:07 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0224.002; Mon, 26 Jan 2015 12:24:07 -0500 From: "Anganes, Amanda L" To: "Anganes, Amanda L" , "calsify@ietf.org" Thread-Topic: calendar-availability-05 accepted as WG draft Thread-Index: AQHQOYzj++0VXX37yEOCDB0gQvhwZg== Date: Mon, 26 Jan 2015 17:24:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.146.16.28] Content-Type: multipart/alternative; boundary="_000_D0EBE240274B8aanganesmitreorg_" MIME-Version: 1.0 Archived-At: Subject: [calsify] calendar-availability-05 accepted as WG draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 17:24:30 -0000 --_000_D0EBE240274B8aanganesmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, Based on the positive feedback we've received, draft-daboo-calendar-availab= ility-05 will be accepted as an official WG draft. Cheers, Amanda & Donald From: , "Anganes, Amanda L" > Date: Friday, December 19, 2014 at 1:49 PM To: "calsify@ietf.org" > Subject: [calsify] Call for WG Adoption: draft-daboo-calendar-availability-= 05 Greetings, This is a call for comments on the adoption of draft-daboo-calendar-availab= ility-05 as an official Calendering Extensions Working Group draft. Due to = the holiday season, this call for adoption will run a bit longer =96 please= comment by January 16th. Thanks, Amanda & Donald --_000_D0EBE240274B8aanganesmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello,

Based on the positive feedback we've received, draft-daboo-calend= ar-availability-05 will be accepted as an official WG draft. 

Cheers,

Amanda & Donald

From: <Anganes>, "Angane= s, Amanda L" <aanganes@mitre.= org>
Date: Friday, December 19, 2014 at = 1:49 PM
To: "calsify@ietf.org" <calsify@ietf.org>
Subject: [calsify] Call for WG Adop= tion: draft-daboo-calendar-availability-05

Greetings,

This is a call for comments on the adoption of draft-daboo-calendar-av= ailability-05 as an official Calendering Extensions Working Group draft. Du= e to the holiday season, this call for adoption will run a bit longer =96 p= lease comment by January 16th.

Thanks,

Amanda & Donald

 --_000_D0EBE240274B8aanganesmitreorg_-- From nobody Wed Jan 28 15:05:24 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A61A1BF6 for ; Wed, 28 Jan 2015 15:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.622 X-Spam-Level: ** X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DC2AcWQ_1dL for ; Wed, 28 Jan 2015 15:05:20 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4CA1A1BF5 for ; Wed, 28 Jan 2015 15:05:20 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 142so10578223ykq.10 for ; Wed, 28 Jan 2015 15:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=hfFcePv7+QOY4mgCJ+dDfisWbeLl9p7tCyUBm3S3EuQ=; b=H4l0g6tQ/S9B2z0c0B05idtA9dCFfzSABZuDIqOg/5x6WgiMetSF9Xcn/NMyZnzreP nyvuz+q5Ojh8G1ovvQ6yibA2Z+grLkJnZoGOyHQlHqwoQveO1o1Tqpznf7cqi+PyMPuy YmhLglYn9x4yOhudvKJXSo9TG8cqdtMx8HlRcCMjBC2hZ2OLGjUNBad3Vj4gLKmjI10N O4+zJIdMAOCEfsLdwS4xcX7tdS4tk2UD+3i0i6SIs4e+dj3lvOiPIzvvJsYBMY6PNsRc 67w7eBSnhyJGw0oWXeJ8t4vUTouTV9sOnL/htGdzCCw888Mt+0rHRNC7sq9Tz93QLK0z C4LA== MIME-Version: 1.0 X-Received: by 10.170.204.196 with SMTP id v187mr2280416yke.97.1422486318864; Wed, 28 Jan 2015 15:05:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.170.50.18 with HTTP; Wed, 28 Jan 2015 15:05:18 -0800 (PST) Date: Thu, 29 Jan 2015 00:05:18 +0100 X-Google-Sender-Auth: Vv2LkrwxC0QfrSpZhkcE0BdF7v0 Message-ID: From: Barry Leiba To: "calsify@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-calext-rscale.all@tools.ietf.org Subject: [calsify] AD review of draft-ietf-calext-rscale-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:05:22 -0000 The chairs requested publication of the subject document, and I've done my AD review of it. See the review below, with points numbered for reference. 0. I asked Donald, in his role as document shepherd, about the use of "updates" metadata with respect to the iCalendar, xCal, and jCal specs. Here's his response: > The document changes iCalendar, xCal, and jCal by performing surgery > on the language syntax in a way not anticipated when the base > documents were written. See the three indented one-sentence paragraphs > at the end of Section 1. Sorry we failed to change the word "extend" > to "change" in the first of those. That would be easy to fix. But that's the thing: I don't believe it does. There's nothing done here that requires all iCalendar implementations to support it. This is an extension... if you don't know about the extension, then you don't support the extension, but I don't think this qualifies as "updates". We've often been fluffy and inconsistent about whether we should use "updates" for extensions, and, for example, IMAP does this particularly badly: it's pretty arbitrary when you look at which IMAP extensions "update" 3501, and which don't. But we (the IESG, at least) are trying to be more consistent about when we use that label. If y'all have a strong objection to removing the "updates" tags, I'll stop objecting, and see if any other ADs bring it up. 1. Section 2 Where you explain the {C} (etc.) notation, it'd probably help to be explicitly clear that it's only for illustrative purposes, and that {X} never appears in actual iCalendar objects. 2. Section 4 It seems funny that SKIP has a fixed default, rather than being dependent upon the RSCALE. For the Hebrew calendar, for example, the default is wrong, and one always needs SKIP=FORWARD. It seems likely that there'll be lots of errors involved in forgetting the SKIP and having the default be wrong for the calendar that's being used, which will cause interoperability problems that would be avoided if the default depended on the calendar. (See also my comment #8 below about Section 4.2.4.) 3. Also, I don't want to break existing implementations, but "SKIP=YES" doesn't seem to be the right way to put it... something parallel to "BACKWARD" and "FORWARD" would be better. Perhaps "SKIP=OMIT". 4. Also also, in the grammar, please make this change: OLD ; and MUST only be present if "RSCALE" is present. NEW ; and MUST NOT be present if "RSCALE" is not present. (I don't think the "MUST only" construct is clear, especially to all varieties of non-native speakers.) 5. Section 4.1 In the last paragraph, I suggest being even clearer in the final sentence, to avoid misunderstandings on the mapping: 'In iCalendar, this would map to months 1 through 12 with "5L" as the leap month (ICU month 6). ICU months 7 through 13 would map to iCalendar months 6 through 12.' 6. Section 4.2.1 It seemed odd to me at first that you were repeating the example. Maybe explicitly saying that will make it less odd: "Consider the Chinese New Year example above:" (and then go ahead and repeat the example). 7. Section 4.2.2 I don't understand why this example needs the BYMONTH value, and why FREQ=YEARLY isn't enough. Isn't this exactly the same as the example in 4.2.1, where "BYMONTH=1" isn't needed? 8. Section 4.2.4 Ooh, this seems completely wrong unless SKIP is redefined to be dependent upon the calendar. In 4.2.3, you're showing me how SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, that's what we want to happen, but how can I know that from the explanation of SKIP? More to the point, it's clear from these two examples that the behaviour of SKIP has to depend upon the calendar that's in effect, and trying to define it to be independent doesn't work. Or have I missed something? 9. Section 5 I have never understood the statement that things in iCalendar are case insensitive, but "SHOULD be in upper case." If they're case insensitive, why does it matter? And, certainly, why does it matter at a SHOULD level? What's this "for consistency" thing? Does that mean that it's nicer, when humans read it, to have things in a consistent case? If so, that's a fine thing to say, but it's not an interoperability SHOULD. 10. Where you talk about CLDR alias values, you say they 'MUST be treated as valid "RSCALE" element values.' Of course they must, as I presume they're syntactically valid. The point you want is that the aliases MUST be treated as the same calendar as what they alias, yes? 11. Section 6 I don't understand why this section is only for iTIP. The iTIP responses are, sure, but what to do if you encounter an RSCALE with a calendar you don't support is not, and advice on that needs to be given more generally. -- I think points 2, 7, and 8 are ones that we need to sort out before I send it out for last call. Any others we fix now is/are/am great too. So let's please discuss. I'll take responses from the authors and/or from any working group participants (and chairs) who would like to get involved. Obviously, changes such as what I propose in points 2, 3, 8, and 9 need to have the working group's agreement behind them, if they are to be made. Barry, Applications AD From nobody Wed Jan 28 16:28:16 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6F1A8911 for ; Wed, 28 Jan 2015 16:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWskQVolJiwR for ; Wed, 28 Jan 2015 16:28:13 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B94F1A8914 for ; Wed, 28 Jan 2015 16:28:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 59E95A32461; Wed, 28 Jan 2015 19:28:10 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sImS24DnxM0M; Wed, 28 Jan 2015 19:28:10 -0500 (EST) Received: from [10.1.0.120] (173-228-7-224.dsl.static.fusionbroadband.com [173.228.7.224]) by daboo.name (Postfix) with ESMTPSA id 9EBF2A32456; Wed, 28 Jan 2015 19:28:08 -0500 (EST) Date: Wed, 28 Jan 2015 16:28:05 -0800 From: Cyrus Daboo To: Barry Leiba , calsify@ietf.org Message-ID: <3A7C407AAE3B688C6B8D19AF@cyrus.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=394 Archived-At: Cc: draft-ietf-calext-rscale.all@tools.ietf.org Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 00:28:15 -0000 Hi Barry, --On January 29, 2015 at 12:05:18 AM +0100 Barry Leiba wrote: > The chairs requested publication of the subject document, and I've > done my AD review of it. See the review below, with points numbered > for reference. Thanks for your review. I am at the CalConnect meeting this week so I will provide a detailed reply once I get back. -- Cyrus Daboo From aronroberts@gmail.com Wed Jan 28 20:49:07 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22A61A8AFE for ; Wed, 28 Jan 2015 20:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.822 X-Spam-Level: * X-Spam-Status: No, score=1.822 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpQrq41g5GOc for ; Wed, 28 Jan 2015 20:49:02 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6C11A1BB3 for ; Wed, 28 Jan 2015 20:49:02 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id r20so19054603wiv.4 for ; Wed, 28 Jan 2015 20:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=VF3vCmj+9VNYEKvHeoV7xxr4/bunwmzHTMraDqjmLSc=; b=HKbY8aUlr6iZaE+zoT1qdKbpFuOtj/Vag79hnOxnzRY3/hgf3iO3rvlp3q++miO6aM XrIrrXxZU3++s6QqS3cT1xtce2f326wuN/C5aggWgPViho2J5YXScGgbn/b0syIitbyw geZrwITaLsxeaaBbSU3PaZ6kmnEBj+zMFKYAt6Rh2WksGzKgUbudA3XHHo9CPs002eFM 0qB2pmjRbIkHvgESBO9caaMWUk5UpXQEtPZTNW2NB8Uxe2zHlcZhqAwqMHSpH4JNOypz 04hofgUf+82xYGcx6fzgJZLZkGVP3BGtwDkj82Ie7GSdfJOFEF7wMGmfFOZuxouPEiGe UDqw== MIME-Version: 1.0 X-Received: by 10.180.206.14 with SMTP id lk14mr379105wic.71.1422506941198; Wed, 28 Jan 2015 20:49:01 -0800 (PST) Sender: aronroberts@gmail.com Received: by 10.27.126.69 with HTTP; Wed, 28 Jan 2015 20:49:01 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 20:49:01 -0800 X-Google-Sender-Auth: L5bGHOOeuq2S5e3qwAhrVmCxt7w Message-ID: From: Aron Roberts To: Barry Leiba , "calsify@ietf.org" , draft-ietf-calext-rscale.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c38dacebb825050dc334be Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 05:02:01 -0000 --001a11c38dacebb825050dc334be Content-Type: text/plain; charset=UTF-8 With apologies in advance for this brief dive into this conversation, since I'm not currently an active member of the Calendering and Scheduling communities. (I attended one CalConnect event years ago, in a previous position.) Barry Leiba suggested, in his comment number 4, pertaining to "4. Extended RRULE Property" in http://tools.ietf.org/html/draft-ietf-calext-rscale-03, that as a possible alternative to the second line here: ; Optional, with default value "BACKWARD", ; and MUST only be present if "RSCALE" is present. the following wording might be clearer, especially to non-native readers: ; and MUST NOT be present if "RSCALE" is not present. I proposed this additional alternative to Barry, in a private communication: ; and MUST NOT be present unless "RSCALE" is present. And he kindly considered this and responded: "Yes, your version with "unless" works too, and captures my concern in the same way as my suggestion. I'm equally happy with either one." FYI, Aron Roberts OCIO - Research IT University of California, Berkeley On Wed, Jan 28, 2015 at 3:05 PM, Barry Leiba wrote: > The chairs requested publication of the subject document, and I've > done my AD review of it. See the review below, with points numbered > for reference. > > 0. I asked Donald, in his role as document shepherd, about the use of > "updates" metadata with respect to the iCalendar, xCal, and jCal > specs. Here's his response: > > > The document changes iCalendar, xCal, and jCal by performing surgery > > on the language syntax in a way not anticipated when the base > > documents were written. See the three indented one-sentence paragraphs > > at the end of Section 1. Sorry we failed to change the word "extend" > > to "change" in the first of those. That would be easy to fix. > > But that's the thing: I don't believe it does. There's nothing done > here that requires all iCalendar implementations to support it. This > is an extension... if you don't know about the extension, then you > don't support the extension, but I don't think this qualifies as > "updates". > > We've often been fluffy and inconsistent about whether we should use > "updates" for extensions, and, for example, IMAP does this > particularly badly: it's pretty arbitrary when you look at which IMAP > extensions "update" 3501, and which don't. But we (the IESG, at > least) are trying to be more consistent about when we use that label. > > If y'all have a strong objection to removing the "updates" tags, I'll > stop objecting, and see if any other ADs bring it up. > > 1. Section 2 > Where you explain the {C} (etc.) notation, it'd probably help to be > explicitly clear that it's only for illustrative purposes, and that > {X} never appears in actual iCalendar objects. > > 2. Section 4 > It seems funny that SKIP has a fixed default, rather than being > dependent upon the RSCALE. For the Hebrew calendar, for example, the > default is wrong, and one always needs SKIP=FORWARD. It seems likely > that there'll be lots of errors involved in forgetting the SKIP and > having the default be wrong for the calendar that's being used, which > will cause interoperability problems that would be avoided if the > default depended on the calendar. (See also my comment #8 below > about Section 4.2.4.) > > 3. Also, I don't want to break existing implementations, but > "SKIP=YES" doesn't seem to be the right way to put it... something > parallel to "BACKWARD" and "FORWARD" would be better. Perhaps > "SKIP=OMIT". > > 4. Also also, in the grammar, please make this change: > OLD > ; and MUST only be present if "RSCALE" is present. > NEW > ; and MUST NOT be present if "RSCALE" is not present. > > (I don't think the "MUST only" construct is clear, especially to all > varieties of non-native speakers.) > > 5. Section 4.1 > In the last paragraph, I suggest being even clearer in the final > sentence, to avoid misunderstandings on the mapping: 'In iCalendar, > this would map to months 1 through 12 with "5L" as the leap month (ICU > month 6). ICU months 7 through 13 would map to iCalendar months 6 > through 12.' > > 6. Section 4.2.1 > It seemed odd to me at first that you were repeating the example. > Maybe explicitly saying that will make it less odd: "Consider the > Chinese New Year example above:" (and then go ahead and repeat the > example). > > 7. Section 4.2.2 > I don't understand why this example needs the BYMONTH value, and why > FREQ=YEARLY isn't enough. Isn't this exactly the same as the example > in 4.2.1, where "BYMONTH=1" isn't needed? > > 8. Section 4.2.4 > Ooh, this seems completely wrong unless SKIP is redefined to be > dependent upon the calendar. In 4.2.3, you're showing me how > SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the > same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, > that's what we want to happen, but how can I know that from the > explanation of SKIP? More to the point, it's clear from these two > examples that the behaviour of SKIP has to depend upon the calendar > that's in effect, and trying to define it to be independent doesn't > work. > > Or have I missed something? > > 9. Section 5 > I have never understood the statement that things in iCalendar are > case insensitive, but "SHOULD be in upper case." If they're case > insensitive, why does it matter? And, certainly, why does it matter > at a SHOULD level? What's this "for consistency" thing? Does that > mean that it's nicer, when humans read it, to have things in a > consistent case? If so, that's a fine thing to say, but it's not an > interoperability SHOULD. > > 10. Where you talk about CLDR alias values, you say they 'MUST be > treated as valid "RSCALE" element values.' Of course they must, as I > presume they're syntactically valid. The point you want is that the > aliases MUST be treated as the same calendar as what they alias, yes? > > 11. Section 6 > I don't understand why this section is only for iTIP. The iTIP > responses are, sure, but what to do if you encounter an RSCALE with a > calendar you don't support is not, and advice on that needs to be > given more generally. > > -- > I think points 2, 7, and 8 are ones that we need to sort out before I > send it out for last call. Any others we fix now is/are/am great too. > So let's please discuss. I'll take responses from the authors and/or > from any working group participants (and chairs) who would like to get > involved. Obviously, changes such as what I propose in points 2, 3, > 8, and 9 need to have the working group's agreement behind them, if > they are to be made. > > Barry, Applications AD > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c38dacebb825050dc334be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With apologies in advance for this brief dive into th= is conversation, since I'm not currently an active member of the Calend= ering and Scheduling communities. (I attended one CalConnect event years ag= o, in a previous position.)

Barry Leiba suggested, in his comment nu= mber 4, pertaining to "4. Extended RRULE Property" in http://tools.ietf.o= rg/html/draft-ietf-calext-rscale-03, that as a possible alternative to = the second line here:

; Optional, with default value "BACKWARD&= quot;,
; and MUST only be present if "RSCALE" is present.
<= br>the following wording might be clearer, especially to non-native readers= :

; and MUST NOT be present if "RSCALE" is not present.
I proposed this additional alternative to Barry, in a private communic= ation:

; and MUST NOT be present unless "RSCALE" is presen= t.

And he kindly considered this and responded:
"Yes, your v= ersion with "unless" works too, and captures my concern in the sa= me way as my suggestion.=C2=A0 I'm equally happy with either one."=

FYI,

Aron Roberts
OCIO - Research IT
Univer= sity of California, Berkeley


<= div class=3D"gmail_quote">On Wed, Jan 28, 2015 at 3:05 PM, Barry Leiba <barryleiba@computer.org> wrote:
The chairs requested publication of the subject document, and I= 9;ve
done my AD review of it.=C2=A0 See the review below, with points numbered for reference.

0. I asked Donald, in his role as document shepherd, about the use of
"updates" metadata with respect to the iCalendar, xCal, and jCal<= br> specs.=C2=A0 Here's his response:

> The document changes iCalendar, xCal, and jCal by performing surgery > on the language syntax in a way not anticipated when the base
> documents were written. See the three indented one-sentence paragraphs=
> at the end of Section 1. Sorry we failed to change the word "exte= nd"
> to "change" in the first of those. That would be easy to fix= .

But that's the thing: I don't believe it does.=C2=A0 There's no= thing done
here that requires all iCalendar implementations to support it.=C2=A0 This<= br> is an extension... if you don't know about the extension, then you
don't support the extension, but I don't think this qualifies as "updates".

We've often been fluffy and inconsistent about whether we should use "updates" for extensions, and, for example, IMAP does this
particularly badly: it's pretty arbitrary when you look at which IMAP extensions "update" 3501, and which don't.=C2=A0 But we (the = IESG, at
least) are trying to be more consistent about when we use that label.

If y'all have a strong objection to removing the "updates" ta= gs, I'll
stop objecting, and see if any other ADs bring it up.

1. Section 2
Where you explain the {C} (etc.) notation, it'd probably help to be
explicitly clear that it's only for illustrative purposes, and that
{X} never appears in actual iCalendar objects.

2. Section 4
It seems funny that SKIP has a fixed default, rather than being
dependent upon the RSCALE.=C2=A0 For the Hebrew calendar, for example, the<= br> default is wrong, and one always needs SKIP=3DFORWARD.=C2=A0 It seems likel= y
that there'll be lots of errors involved in forgetting the SKIP and
having the default be wrong for the calendar that's being used, which will cause interoperability problems that would be avoided if the
default depended on the calendar.=C2=A0 (See also my comment #8 below
about Section 4.2.4.)

3. Also, I don't want to break existing implementations, but
"SKIP=3DYES" doesn't seem to be the right way to put it... so= mething
parallel to "BACKWARD" and "FORWARD" would be better.= =C2=A0 Perhaps
"SKIP=3DOMIT".

4. Also also, in the grammar, please make this change:
OLD
; and MUST only be present if "RSCALE" is present.
NEW
; and MUST NOT be present if "RSCALE" is not present.

(I don't think the "MUST only" construct is clear, especially= to all
varieties of non-native speakers.)

5. Section 4.1
In the last paragraph, I suggest being even clearer in the final
sentence, to avoid misunderstandings on the mapping: 'In iCalendar,
this would map to months 1 through 12 with "5L" as the leap month= (ICU
month 6).=C2=A0 ICU months 7 through 13 would map to iCalendar months 6
through 12.'

6. Section 4.2.1
It seemed odd to me at first that you were repeating the example.
Maybe explicitly saying that will make it less odd: "Consider the
Chinese New Year example above:" (and then go ahead and repeat the
example).

7. Section 4.2.2
I don't understand why this example needs the BYMONTH value, and why FREQ=3DYEARLY isn't enough.=C2=A0 Isn't this exactly the same as th= e example
in 4.2.1, where "BYMONTH=3D1" isn't needed?

8. Section 4.2.4
Ooh, this seems completely wrong unless SKIP is redefined to be
dependent upon the calendar.=C2=A0 In 4.2.3, you're showing me how
SKIP=3DFORWARD turns 5L-08 into 6-08, but then here you tell me that the same SKIP=3DFORWARD turns 2-29 into 3-01, rather than 3-29.=C2=A0 Of course= ,
that's what we want to happen, but how can I know that from the
explanation of SKIP?=C2=A0 More to the point, it's clear from these two=
examples that the behaviour of SKIP has to depend upon the calendar
that's in effect, and trying to define it to be independent doesn't=
work.

Or have I missed something?

9. Section 5
I have never understood the statement that things in iCalendar are
case insensitive, but "SHOULD be in upper case."=C2=A0 If they= 9;re case
insensitive, why does it matter?=C2=A0 And, certainly, why does it matter at a SHOULD level?=C2=A0 What's this "for consistency" thing?= =C2=A0 Does that
mean that it's nicer, when humans read it, to have things in a
consistent case?=C2=A0 If so, that's a fine thing to say, but it's = not an
interoperability SHOULD.

10. Where you talk about CLDR alias values, you say they 'MUST be
treated as valid "RSCALE" element values.'=C2=A0 Of course th= ey must, as I
presume they're syntactically valid.=C2=A0 The point you want is that t= he
aliases MUST be treated as the same calendar as what they alias, yes?

11. Section 6
I don't understand why this section is only for iTIP.=C2=A0 The iTIP responses are, sure, but what to do if you encounter an RSCALE with a
calendar you don't support is not, and advice on that needs to be
given more generally.

--
I think points 2, 7, and 8 are ones that we need to sort out before I
send it out for last call.=C2=A0 Any others we fix now is/are/am great too.=
So let's please discuss.=C2=A0 I'll take responses from the authors= and/or
from any working group participants (and chairs) who would like to get
involved.=C2=A0 Obviously, changes such as what I propose in points 2, 3, 8, and 9 need to have the working group's agreement behind them, if
they are to be made.

Barry, Applications AD

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

--001a11c38dacebb825050dc334be-- From nobody Wed Jan 28 23:43:30 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A681A8FD2 for ; Wed, 28 Jan 2015 23:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWYvMZ6KI8k1 for ; Wed, 28 Jan 2015 23:43:25 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B03E1A8F51 for ; Wed, 28 Jan 2015 23:43:24 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id y19so22646505wgg.11 for ; Wed, 28 Jan 2015 23:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=CKqvy/xvpG1uN6/gCWPt9x1+VDy13cPKYe8m7D5sJZ8=; b=rBQcW4wS41hMvJsdEW1LJWcztx1TrMyNYVsTY6tXz93bQuvpmJHl6ZvIwIvGml50bp Jz/5xscsqyLcEGZp20xWv+WGuRLPeoc9gI/rjI0KQ3lm1LT0ogSptFCdRj7+m/LM+isQ a9v1upHAJTElKMYtOMMTFcs8giHPzkV1hqoiXQW3G9FNfKmuJ7Op1G2WhQ0qFKdHby2O UpDQam2JjHAPyTD95gazitHDcqZ7o/R2JvUgECFLKgfAELqa6Wxu6nG3mvG6UtMKaugj gFP9NYYtE/Ohk9bv+fiJPYL2hvMLZlwbZfZKHqzCABN4m5KvqUAi+9y81jPf/0PPeowf Tihg== X-Received: by 10.194.23.6 with SMTP id i6mr15389854wjf.26.1422517403272; Wed, 28 Jan 2015 23:43:23 -0800 (PST) Received: from smtp.dmfs.org (pD9EA6E3E.dip0.t-ipconnect.de. [217.234.110.62]) by mx.google.com with ESMTPSA id x6sm9269942wjf.24.2015.01.28.23.43.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Jan 2015 23:43:20 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (c-71-198-93-57.hsd1.ca.comcast.net [71.198.93.57]) by smtp.dmfs.org (Postfix) with ESMTPSA id 706D760A for ; Thu, 29 Jan 2015 08:43:17 +0100 (CET) Message-ID: <54C9E490.2020806@dmfs.org> Date: Wed, 28 Jan 2015 23:43:12 -0800 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090704020205070005020506" Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 07:43:28 -0000 This is a multi-part message in MIME format. --------------090704020205070005020506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Barry, in general I agree with most of your points, except for the ones below: #2: Having the same default value for all calendar scales at least guarantees consistent results among different implementations when you forget the SKIP value. IMHO, having per-calendar-scale default values adds unnecessary complexity and it's questionable if you can find consensus on what the default should be for various scales (I don't think that the CLDR has defined default skip values so far). Also, I think the likelihood of implementing the per-calendar-scale default values wrong, is probably just as high as forgetting a SKIP value. Setting the default to "SKIP=YES" (or "SKIP=OMIT", which sounds reasonable to me) would be the simplest solution, because it's the current behavior anyway. #7: True, it's not necessary to specify BYMONTH and BYMONTHDAY in sections 4.2.2 and 4.2.3. But according to RFC 5545 it's completely valid and you can see many rules like that in the wild. The purpose of an example is to show how an RRULE could look like in real life and how you have to interpret it. To me it perfectly makes sense to give examples of both types of rules (i.e. with and without redundant BYMONTH and BYMONTHDAY parts). #8: The idea is: If you skip a leap month, you go forward (or backwards) by one month. If you skip a leap day you go forward (or backwards) by one day. I guess that should be pointed out somewhere. #9: I think that part has been added after I asked about the case-sensitivity of the RSCALE value. In general most calendar applications tend to use the upper-case representation of names and tokens, but the CLDR calendar scale names are defined in lower case (as in http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml). I know it's just an implementation detail rather than being relevant for this standard, but being able to make assumptions about the case allows for certain optimization that wouldn't be possible otherwise. On a mobile device with very limited resources that can make a difference. In this context I think "for consistency" means consistency between implementations, i.e. ideally all implementations would use the upper-case version, even though the standard doesn't enforce it (because most things in RFC 5545 are, by definition, case-insensitive). I guess the same applies to the SKIP values and the "L" of leap months. Does this spec allow a lower case "l"? cheers Marten Am 28.01.2015 um 15:05 schrieb Barry Leiba: > The chairs requested publication of the subject document, and I've > done my AD review of it. See the review below, with points numbered > for reference. > > 0. I asked Donald, in his role as document shepherd, about the use of > "updates" metadata with respect to the iCalendar, xCal, and jCal > specs. Here's his response: > >> The document changes iCalendar, xCal, and jCal by performing surgery >> on the language syntax in a way not anticipated when the base >> documents were written. See the three indented one-sentence paragraphs >> at the end of Section 1. Sorry we failed to change the word "extend" >> to "change" in the first of those. That would be easy to fix. > But that's the thing: I don't believe it does. There's nothing done > here that requires all iCalendar implementations to support it. This > is an extension... if you don't know about the extension, then you > don't support the extension, but I don't think this qualifies as > "updates". > > We've often been fluffy and inconsistent about whether we should use > "updates" for extensions, and, for example, IMAP does this > particularly badly: it's pretty arbitrary when you look at which IMAP > extensions "update" 3501, and which don't. But we (the IESG, at > least) are trying to be more consistent about when we use that label. > > If y'all have a strong objection to removing the "updates" tags, I'll > stop objecting, and see if any other ADs bring it up. > > 1. Section 2 > Where you explain the {C} (etc.) notation, it'd probably help to be > explicitly clear that it's only for illustrative purposes, and that > {X} never appears in actual iCalendar objects. > > 2. Section 4 > It seems funny that SKIP has a fixed default, rather than being > dependent upon the RSCALE. For the Hebrew calendar, for example, the > default is wrong, and one always needs SKIP=FORWARD. It seems likely > that there'll be lots of errors involved in forgetting the SKIP and > having the default be wrong for the calendar that's being used, which > will cause interoperability problems that would be avoided if the > default depended on the calendar. (See also my comment #8 below > about Section 4.2.4.) > > 3. Also, I don't want to break existing implementations, but > "SKIP=YES" doesn't seem to be the right way to put it... something > parallel to "BACKWARD" and "FORWARD" would be better. Perhaps > "SKIP=OMIT". > > 4. Also also, in the grammar, please make this change: > OLD > ; and MUST only be present if "RSCALE" is present. > NEW > ; and MUST NOT be present if "RSCALE" is not present. > > (I don't think the "MUST only" construct is clear, especially to all > varieties of non-native speakers.) > > 5. Section 4.1 > In the last paragraph, I suggest being even clearer in the final > sentence, to avoid misunderstandings on the mapping: 'In iCalendar, > this would map to months 1 through 12 with "5L" as the leap month (ICU > month 6). ICU months 7 through 13 would map to iCalendar months 6 > through 12.' > > 6. Section 4.2.1 > It seemed odd to me at first that you were repeating the example. > Maybe explicitly saying that will make it less odd: "Consider the > Chinese New Year example above:" (and then go ahead and repeat the > example). > > 7. Section 4.2.2 > I don't understand why this example needs the BYMONTH value, and why > FREQ=YEARLY isn't enough. Isn't this exactly the same as the example > in 4.2.1, where "BYMONTH=1" isn't needed? > > 8. Section 4.2.4 > Ooh, this seems completely wrong unless SKIP is redefined to be > dependent upon the calendar. In 4.2.3, you're showing me how > SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the > same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, > that's what we want to happen, but how can I know that from the > explanation of SKIP? More to the point, it's clear from these two > examples that the behaviour of SKIP has to depend upon the calendar > that's in effect, and trying to define it to be independent doesn't > work. > > Or have I missed something? > > 9. Section 5 > I have never understood the statement that things in iCalendar are > case insensitive, but "SHOULD be in upper case." If they're case > insensitive, why does it matter? And, certainly, why does it matter > at a SHOULD level? What's this "for consistency" thing? Does that > mean that it's nicer, when humans read it, to have things in a > consistent case? If so, that's a fine thing to say, but it's not an > interoperability SHOULD. > > 10. Where you talk about CLDR alias values, you say they 'MUST be > treated as valid "RSCALE" element values.' Of course they must, as I > presume they're syntactically valid. The point you want is that the > aliases MUST be treated as the same calendar as what they alias, yes? > > 11. Section 6 > I don't understand why this section is only for iTIP. The iTIP > responses are, sure, but what to do if you encounter an RSCALE with a > calendar you don't support is not, and advice on that needs to be > given more generally. > > -- > I think points 2, 7, and 8 are ones that we need to sort out before I > send it out for last call. Any others we fix now is/are/am great too. > So let's please discuss. I'll take responses from the authors and/or > from any working group participants (and chairs) who would like to get > involved. Obviously, changes such as what I propose in points 2, 3, > 8, and 9 need to have the working group's agreement behind them, if > they are to be made. > > Barry, Applications AD > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------090704020205070005020506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Barry,

in general I agree with most of your points, except for the ones below:

#2:
Having the same default value for all calendar scales at least guarantees consistent results among different implementations when you forget the SKIP value. IMHO, having per-calendar-scale default values adds unnecessary complexity and it's questionable if you can find consensus on what the default should be for various scales (I don't think that the CLDR has defined default skip values so far).
Also, I think the likelihood of implementing  the per-calendar-scale default values wrong, is probably just as high as forgetting a SKIP value.

Setting the default to "SKIP=YES" (or "SKIP=OMIT", which sounds reasonable to me) would be the simplest solution, because it's the current behavior anyway.

#7:
True, it's not necessary to specify BYMONTH and BYMONTHDAY in sections 4.2.2 and 4.2.3. But according to RFC 5545 it's completely valid and you can see many rules like that in the wild.
The purpose of an example is to show how an RRULE could look like in real life and how you have to interpret it. To me it perfectly makes sense to give examples of both types of rules (i.e. with and without redundant BYMONTH and BYMONTHDAY parts).

#8:
The idea is: If you skip a leap month, you go forward (or backwards) by one month. If you skip a leap day you go forward (or backwards) by one day.
I guess that should be pointed out somewhere.

#9:
I think that part has been added after I asked about the case-sensitivity of the RSCALE value. In general most calendar applications tend to use the upper-case representation of names and tokens, but the CLDR calendar scale names are defined in lower case (as in http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml).
I know it's just an implementation detail rather than being relevant for this standard, but being able to make assumptions about the case allows for certain optimization that wouldn't be possible otherwise. On a mobile device with very limited resources that can make a difference.
In this context I think "for consistency" means consistency between implementations, i.e. ideally all implementations would use the upper-case version, even though the standard doesn't enforce it (because most things in RFC 5545 are, by definition, case-insensitive).
I guess the same applies to the SKIP values and the "L" of leap months. Does this spec allow a lower case "l"?

cheers

Marten

Am 28.01.2015 um 15:05 schrieb Barry Leiba:
The chairs requested publication of the subject document, and I've
done my AD review of it.  See the review below, with points numbered
for reference.

0. I asked Donald, in his role as document shepherd, about the use of
"updates" metadata with respect to the iCalendar, xCal, and jCal
specs.  Here's his response:


The document changes iCalendar, xCal, and jCal by performing surgery
on the language syntax in a way not anticipated when the base
documents were written. See the three indented one-sentence paragraphs
at the end of Section 1. Sorry we failed to change the word "extend"
to "change" in the first of those. That would be easy to fix.

But that's the thing: I don't believe it does.  There's nothing done
here that requires all iCalendar implementations to support it.  This
is an extension... if you don't know about the extension, then you
don't support the extension, but I don't think this qualifies as
"updates".

We've often been fluffy and inconsistent about whether we should use
"updates" for extensions, and, for example, IMAP does this
particularly badly: it's pretty arbitrary when you look at which IMAP
extensions "update" 3501, and which don't.  But we (the IESG, at
least) are trying to be more consistent about when we use that label.

If y'all have a strong objection to removing the "updates" tags, I'll
stop objecting, and see if any other ADs bring it up.

1. Section 2
Where you explain the {C} (etc.) notation, it'd probably help to be
explicitly clear that it's only for illustrative purposes, and that
{X} never appears in actual iCalendar objects.

2. Section 4
It seems funny that SKIP has a fixed default, rather than being
dependent upon the RSCALE.  For the Hebrew calendar, for example, the
default is wrong, and one always needs SKIP=FORWARD.  It seems likely
that there'll be lots of errors involved in forgetting the SKIP and
having the default be wrong for the calendar that's being used, which
will cause interoperability problems that would be avoided if the
default depended on the calendar.  (See also my comment #8 below
about Section 4.2.4.)

3. Also, I don't want to break existing implementations, but
"SKIP=YES" doesn't seem to be the right way to put it... something
parallel to "BACKWARD" and "FORWARD" would be better.  Perhaps
"SKIP=OMIT".

4. Also also, in the grammar, please make this change:
OLD
; and MUST only be present if "RSCALE" is present.
NEW
; and MUST NOT be present if "RSCALE" is not present.

(I don't think the "MUST only" construct is clear, especially to all
varieties of non-native speakers.)

5. Section 4.1
In the last paragraph, I suggest being even clearer in the final
sentence, to avoid misunderstandings on the mapping: 'In iCalendar,
this would map to months 1 through 12 with "5L" as the leap month (ICU
month 6).  ICU months 7 through 13 would map to iCalendar months 6
through 12.'

6. Section 4.2.1
It seemed odd to me at first that you were repeating the example.
Maybe explicitly saying that will make it less odd: "Consider the
Chinese New Year example above:" (and then go ahead and repeat the
example).

7. Section 4.2.2
I don't understand why this example needs the BYMONTH value, and why
FREQ=YEARLY isn't enough.  Isn't this exactly the same as the example
in 4.2.1, where "BYMONTH=1" isn't needed?

8. Section 4.2.4
Ooh, this seems completely wrong unless SKIP is redefined to be
dependent upon the calendar.  In 4.2.3, you're showing me how
SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the
same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29.  Of course,
that's what we want to happen, but how can I know that from the
explanation of SKIP?  More to the point, it's clear from these two
examples that the behaviour of SKIP has to depend upon the calendar
that's in effect, and trying to define it to be independent doesn't
work.

Or have I missed something?

9. Section 5
I have never understood the statement that things in iCalendar are
case insensitive, but "SHOULD be in upper case."  If they're case
insensitive, why does it matter?  And, certainly, why does it matter
at a SHOULD level?  What's this "for consistency" thing?  Does that
mean that it's nicer, when humans read it, to have things in a
consistent case?  If so, that's a fine thing to say, but it's not an
interoperability SHOULD.

10. Where you talk about CLDR alias values, you say they 'MUST be
treated as valid "RSCALE" element values.'  Of course they must, as I
presume they're syntactically valid.  The point you want is that the
aliases MUST be treated as the same calendar as what they alias, yes?

11. Section 6
I don't understand why this section is only for iTIP.  The iTIP
responses are, sure, but what to do if you encounter an RSCALE with a
calendar you don't support is not, and advice on that needs to be
given more generally.

--
I think points 2, 7, and 8 are ones that we need to sort out before I
send it out for last call.  Any others we fix now is/are/am great too.
So let's please discuss.  I'll take responses from the authors and/or
from any working group participants (and chairs) who would like to get
involved.  Obviously, changes such as what I propose in points 2, 3,
8, and 9 need to have the working group's agreement behind them, if
they are to be made.

Barry, Applications AD

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

--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

--------------090704020205070005020506-- From nobody Thu Jan 29 11:55:14 2015 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA0B1A7005 for ; Thu, 29 Jan 2015 11:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkfr7RrWw45z for ; Thu, 29 Jan 2015 11:55:01 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3351A6F33 for ; Thu, 29 Jan 2015 11:55:01 -0800 (PST) Received: from ken.name (173-228-7-224.dsl.static.fusionbroadband.com [173.228.7.224]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t0TJswPw002262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 29 Jan 2015 14:54:59 -0500 Message-ID: <54CA9012.9090603@andrew.cmu.edu> Date: Thu, 29 Jan 2015 14:54:58 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.29.194222 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203 Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 19:55:05 -0000 Hi Barry, My comments/suggestions to select points are inline. For the others I either agree with your assessment/suggestion or don't have a strong opinion and would be fine with any changes on those. On 01/28/2015 06:05 PM, Barry Leiba wrote: > The chairs requested publication of the subject document, and I've > done my AD review of it. See the review below, with points numbered > for reference. > > 0. I asked Donald, in his role as document shepherd, about the use of > "updates" metadata with respect to the iCalendar, xCal, and jCal > specs. Here's his response: > > ... > > If y'all have a strong objection to removing the "updates" tags, I'll > stop objecting, and see if any other ADs bring it up. No objection here. > 2. Section 4 > It seems funny that SKIP has a fixed default, rather than being > dependent upon the RSCALE. For the Hebrew calendar, for example, the > default is wrong, and one always needs SKIP=FORWARD. It seems likely > that there'll be lots of errors involved in forgetting the SKIP and > having the default be wrong for the calendar that's being used, which > will cause interoperability problems that would be avoided if the > default depended on the calendar. (See also my comment #8 below > about Section 4.2.4.) Perhaps an alternative to having a per-calendar default would be to make SKIP mandatory in the presence of RSCALE, thereby forcing the user/client to be explicit in their expectations. > 3. Also, I don't want to break existing implementations, but > "SKIP=YES" doesn't seem to be the right way to put it... something > parallel to "BACKWARD" and "FORWARD" would be better. Perhaps > "SKIP=OMIT". Grisha (co-author) and I both have running code, but I personally don't have an issue with this change due to the fact that my RSCALE implementation in Libical hasn't been officially released yet. I don't know the status of Grisha's deployment, so I will let him protest on his own if need be. > 7. Section 4.2.2 > I don't understand why this example needs the BYMONTH value, and why > FREQ=YEARLY isn't enough. Isn't this exactly the same as the example > in 4.2.1, where "BYMONTH=1" isn't needed? As you point out, BYMONTH technically isn't needed. I had suggested this example to Cyrus to illustrate to readers the fact that BYMONTH can take a value > 12 depending on the calendar. If you feel that illustrating this point isn't necessary, or feel that a better example should be considered, I'm fine either way. > 8. Section 4.2.4 > Ooh, this seems completely wrong unless SKIP is redefined to be > dependent upon the calendar. In 4.2.3, you're showing me how > SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the > same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, > that's what we want to happen, but how can I know that from the > explanation of SKIP? More to the point, it's clear from these two > examples that the behaviour of SKIP has to depend upon the calendar > that's in effect, and trying to define it to be independent doesn't > work. I'd be in favor of additional text clarifying that the effect of SKIP depends on whether the recurrence falls on an intercalary day or month. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University