From nobody Fri Jul 10 09:43: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 810621B2A1F for ; Fri, 10 Jul 2015 09:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IS1xaap0ho03 for ; Fri, 10 Jul 2015 09:43:30 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id A05FB1B2A22 for ; Fri, 10 Jul 2015 09:43:30 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E76AB2E84F; Fri, 10 Jul 2015 12:43:31 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 326B952E0A5; Fri, 10 Jul 2015 12:43:31 -0400 (EDT) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 10 Jul 2015 12:43:29 -0400 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 10 Jul 2015 12:43:29 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Fri, 10 Jul 2015 12:43:29 -0400 Received: from BY1PR09MB0808.namprd09.prod.outlook.com (10.162.143.26) by BY1PR09MB0805.namprd09.prod.outlook.com (10.162.143.23) with Microsoft SMTP Server (TLS) id 15.1.213.14; Fri, 10 Jul 2015 16:43:21 +0000 Received: from BY1PR09MB0808.namprd09.prod.outlook.com ([10.162.143.26]) by BY1PR09MB0808.namprd09.prod.outlook.com ([10.162.143.26]) with mapi id 15.01.0213.000; Fri, 10 Jul 2015 16:43:21 +0000 From: "Anganes, Amanda L" To: Ken Murchison , Calsify Thread-Topic: [calsify] Request for feedback/discussion Thread-Index: AQHQnwd9bOzkamuUvk2VR+nPYGe9gp2c88CAgDfqMwA= Date: Fri, 10 Jul 2015 16:43:21 +0000 Message-ID: References: <5570D64B.5060306@andrew.cmu.edu> In-Reply-To: <5570D64B.5060306@andrew.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 authentication-results: andrew.cmu.edu; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.51.88] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0805; 5:otIvDlZ7MhXx/kpbtgqu8926UkOq+8qRL5FnerXhkOsuZRi1nkDstoIYHfjVCHdLOHJX5GGx1K3brzJrFqkU15lvTyVFCZFs7Has00/WvJ9vyGW1KXCPql/IN7dRTbuDg1+ams2TBKmJBK3n4DgDiw==; 24:JKrHb+6fhVvIJdC6vM8VIXqU0Fq1HG27LnP6wfJbYffZGUQfBMN9Mt5jCpRodKZ27LgQqKJW0H5QyWUH0OD/IJrvcRekGljEciBKrM7y0L0=; 20:esNSOZiOg7TmCU65LrnFcJjlqwfaYcQuN4wqeVAFenqP36Z2xfoJyP8BAiIqWibuXFLofnEc3fXIbNhUAx41vg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0805; by1pr09mb0805: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR09MB0805; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0805; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(84964002)(377454003)(479174004)(24454002)(189998001)(86362001)(5001960100002)(106116001)(40100003)(66066001)(19580405001)(5002640100001)(77156002)(19580395003)(122556002)(2656002)(87936001)(107886002)(83506001)(54356999)(19617315012)(76176999)(2950100001)(46102003)(15975445007)(62966003)(50986999)(5001770100001)(102836002)(92566002)(36756003)(16236675004)(77096005)(2900100001)(4001350100001)(2171001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0805; H:BY1PR09MB0808.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1C56D7A32914aanganesmitreorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 16:43:21.1468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0805 X-OriginatorOrg: mitre.org Archived-At: Subject: Re: [calsify] Request for feedback/discussion 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, 10 Jul 2015 16:43:33 -0000 --_000_D1C56D7A32914aanganesmitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ken, Have you received answers for these two questions/concerns? If not, WG, please read and respond to the messages Ken's linked below. Amanda Anganes WG Co-Chair From: Ken Murchison > Organization: Carnegie Mellon University Date: Thursday, June 4, 2015 at 6:50 PM To: "Anganes, Amanda L" >, Ca= lsify > Subject: Re: [calsify] Request for feedback/discussion Hi Amanda, I sent out messages on April 7 concerning both these documents: http://www.ietf.org/mail-archive/web/calsify/current/msg02689.html http://www.ietf.org/mail-archive/web/calsify/current/msg02692.html Cyrus proposed some new clarifying text for draft-ietf-calext-extensions which pro= bably needs to be posted as -01. I don't believe that my comments regarding draft-ietf-calext-availability h= ave been addressed yet. On 06/04/2015 04:46 PM, Anganes, Amanda L wrote: Hi CalExt WG, We have two remaining drafts to finish, and discussion has slowed down late= ly. The two drafts are: Draft-ietf-calext-availability-00 and Draft-ietf-calext-extensions-00 Please review these two documents, and reply back to the WG with any commen= ts, questions, concerns, or to let us know if you think they're ready for W= G Last Call. Looking forward to hearing from you, -Amanda & Donald, CalExt Co-chairs _______________________________________________ calsify mailing list calsify@ietf.orghttps://www.ietf.org/mailman/listi= nfo/calsify -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --_000_D1C56D7A32914aanganesmitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8E0FCB6F57C46845A388CF39E8FAE4C4@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Ken,

Have you received answers for these two questions/concerns? 

If not, WG, please read and respond to the messages Ken’s linked= below.

Amanda Anganes
WG Co-Chair

From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon Unive= rsity
Date: Thursday, June 4, 2015 at 6:5= 0 PM
To: "Anganes, Amanda L" &= lt;aanganes@mitre.org>, Calsif= y <calsify@ietf.org>
Subject: Re: [calsify] Request for = feedback/discussion

Hi Amanda,

I sent out messages on April 7 concerning both these documents:

http://www.ietf.org/mail-archive/web/calsify/current/msg02689.html<= br> http://www.ietf.org/mail-archive/web/calsify/current/msg02692.html<= br>
Cyrus proposed some new clarifying text for draft-ietf-calext-extensions which probably needs t= o be posted as -01.

I don't believe that my comments regarding draft-ietf-calext-availability h= ave been addressed yet.



On 06/04/2015 04:46 PM, Anganes, Amanda L wrote:
Hi CalExt WG,

We have two remaining drafts to finish, and discussion has slowed down= lately. The two drafts are:


Please review these two documents, and reply back to the WG with any c= omments, questions, concerns, or to let us know if you think they’re = ready for WG Last Call.

Looking forward to hearing from you,

—Amanda & Donald, CalExt Co-chairs



_______________________________________________
calsify mailing list
cals=
ify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsif=
y


--=20
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--_000_D1C56D7A32914aanganesmitreorg_-- From nobody Fri Jul 10 09:50:55 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 1F39F1B2A2A for ; Fri, 10 Jul 2015 09:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hym4FN8tmpPj for ; Fri, 10 Jul 2015 09:50:50 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1AC1B2A27 for ; Fri, 10 Jul 2015 09:50:50 -0700 (PDT) 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 t6AGomhm004429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Jul 2015 12:50:49 -0400 Message-ID: <559FF7E8.7090700@andrew.cmu.edu> Date: Fri, 10 Jul 2015 12:50:48 -0400 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: "Anganes, Amanda L" , Calsify References: <5570D64B.5060306@andrew.cmu.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060909020207020108060404" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.10.164516 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, BODY_PARA_IS_SENTENCE_URL 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 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, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_URI_IN_BODY 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_IN_BODY 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.202 Archived-At: Subject: Re: [calsify] Request for feedback/discussion 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, 10 Jul 2015 16:50:54 -0000 This is a multi-part message in MIME format. --------------060909020207020108060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Amanda, The question about calext-extensions was addressed by Cyrus with some proposed text. I don't believe there was a response to my calext-availability comments. On 07/10/2015 12:43 PM, Anganes, Amanda L wrote: > Hi Ken, > > Have you received answers for these two questions/concerns? > > If not, WG, please read and respond to the messages Ken's linked below. > > Amanda Anganes > WG Co-Chair > > From: Ken Murchison > > Organization: Carnegie Mellon University > Date: Thursday, June 4, 2015 at 6:50 PM > To: "Anganes, Amanda L" >, Calsify > > Subject: Re: [calsify] Request for feedback/discussion > > Hi Amanda, > > I sent out messages on April 7 concerning both these documents: > > http://www.ietf.org/mail-archive/web/calsify/current/msg02689.html > http://www.ietf.org/mail-archive/web/calsify/current/msg02692.html > > Cyrus proposed some new clarifying text > > for draft-ietf-calext-extensions which probably needs to be posted as -01. > > I don't believe that my comments regarding > draft-ietf-calext-availability have been addressed yet. > > > > On 06/04/2015 04:46 PM, Anganes, Amanda L wrote: >> Hi CalExt WG, >> >> We have two remaining drafts to finish, and discussion has slowed >> down lately. The two drafts are: >> >> Draft-ietf-calext-availability-00 >> and >> Draft-ietf-calext-extensions-00 >> >> >> Please review these two documents, and reply back to the WG with any >> comments, questions, concerns, or to let us know if you think they're >> ready for WG Last Call. >> >> Looking forward to hearing from you, >> >> ---Amanda & Donald, CalExt Co-chairs >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------060909020207020108060404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Amanda,

The question about calext-extensions was addressed by Cyrus with some proposed text.  I don't believe there was a response to my calext-availability comments.



On 07/10/2015 12:43 PM, Anganes, Amanda L wrote:
Hi Ken,

Have you received answers for these two questions/concerns? 

If not, WG, please read and respond to the messages Ken’s linked below.

Amanda Anganes
WG Co-Chair

From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
Date: Thursday, June 4, 2015 at 6:50 PM
To: "Anganes, Amanda L" <aanganes@mitre.org>, Calsify <calsify@ietf.org>
Subject: Re: [calsify] Request for feedback/discussion

Hi Amanda,

I sent out messages on April 7 concerning both these documents:

http://www.ietf.org/mail-archive/web/calsify/current/msg02689.html
http://www.ietf.org/mail-archive/web/calsify/current/msg02692.html

Cyrus proposed some new clarifying text for draft-ietf-calext-extensions which probably needs to be posted as -01.

I don't believe that my comments regarding draft-ietf-calext-availability have been addressed yet.



On 06/04/2015 04:46 PM, Anganes, Amanda L wrote:
Hi CalExt WG,

We have two remaining drafts to finish, and discussion has slowed down lately. The two drafts are:


Please review these two documents, and reply back to the WG with any comments, questions, concerns, or to let us know if you think they’re ready for WG Last Call.

Looking forward to hearing from you,

—Amanda & Donald, CalExt Co-chairs



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


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University



-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------060909020207020108060404-- From nobody Fri Jul 10 13:29:54 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 365EF1A0076 for ; Fri, 10 Jul 2015 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 EINWMFp0-X-6 for ; Fri, 10 Jul 2015 13:29:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E40081A0074 for ; Fri, 10 Jul 2015 13:29:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 79BD8180206; Fri, 10 Jul 2015 13:26:10 -0700 (PDT) To: bernard.desruisseaux@oracle.com, barryleiba@computer.org, lear@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150710202610.79BD8180206@rfc-editor.org> Date: Fri, 10 Jul 2015 13:26:10 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, calsify@ietf.org, joseph.silvestre@cozycloud.cc Subject: [calsify] [Editorial Errata Reported] RFC5545 (4414) 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, 10 Jul 2015 20:29:53 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4414 -------------------------------------- Type: Editorial Reported by: Joseph Silvestre Section: 3.3.10 Original Text ------------- The UNTIL rule part defines a DATE or DATE-TIME value that bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this DATE or DATE-TIME becomes the last instance of the recurrence. The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. If not present, and the COUNT rule part is also not present, the "RRULE" is considered to repeat forever. Corrected Text -------------- The UNTIL rule part defines a DATE or DATE-TIME value that bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this DATE or DATE-TIME becomes the last instance of the recurrence. The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If not present, and the COUNT rule part is also not present, the "RRULE" is considered to repeat forever. Notes ----- The following sentence from RFC 2445 should have been removed from the text. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Jul 10 14:14: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 9AF481B2AF8 for ; Fri, 10 Jul 2015 14:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v8ocVyFRf8mR for ; Fri, 10 Jul 2015 14:14:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 CE6B11B2AC2 for ; Fri, 10 Jul 2015 14:14:23 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6ALBmnA000859 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jul 2015 21:11:48 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t6ALBlP5021676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2015 21:11:47 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6ALBle2014927; Fri, 10 Jul 2015 21:11:47 GMT Received: from [10.156.45.76] (/10.156.45.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Jul 2015 14:11:47 -0700 Message-ID: <55A03512.1010204@oracle.com> Date: Fri, 10 Jul 2015 17:11:46 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: RFC Errata System , barryleiba@computer.org, lear@cisco.com References: <20150710202610.79BD8180206@rfc-editor.org> In-Reply-To: <20150710202610.79BD8180206@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: calsify@ietf.org, joseph.silvestre@cozycloud.cc Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (4414) 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, 10 Jul 2015 21:14:25 -0000 Approved. On 10/07/2015 4:26 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4414 > > -------------------------------------- > Type: Editorial > Reported by: Joseph Silvestre > > Section: 3.3.10 > > Original Text > ------------- > The UNTIL rule part defines a DATE or DATE-TIME value that bounds > the recurrence rule in an inclusive manner. If the value > specified by UNTIL is synchronized with the specified recurrence, > this DATE or DATE-TIME becomes the last instance of the > recurrence. The value of the UNTIL rule part MUST have the same > value type as the "DTSTART" property. Furthermore, if the > "DTSTART" property is specified as a date with local time, then > the UNTIL rule part MUST also be specified as a date with local > time. If the "DTSTART" property is specified as a date with UTC > time or a date with local time and time zone reference, then the > UNTIL rule part MUST be specified as a date with UTC time. In the > case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > rule part MUST always be specified as a date with UTC time. If > specified as a DATE-TIME value, then it MUST be specified in a UTC > time format. If not present, and the COUNT rule part is also not > present, the "RRULE" is considered to repeat forever. > > Corrected Text > -------------- > The UNTIL rule part defines a DATE or DATE-TIME value that bounds > the recurrence rule in an inclusive manner. If the value > specified by UNTIL is synchronized with the specified recurrence, > this DATE or DATE-TIME becomes the last instance of the > recurrence. The value of the UNTIL rule part MUST have the same > value type as the "DTSTART" property. Furthermore, if the > "DTSTART" property is specified as a date with local time, then > the UNTIL rule part MUST also be specified as a date with local > time. If the "DTSTART" property is specified as a date with UTC > time or a date with local time and time zone reference, then the > UNTIL rule part MUST be specified as a date with UTC time. In the > case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > rule part MUST always be specified as a date with UTC time. > If not present, and the COUNT rule part is also not > present, the "RRULE" is considered to repeat forever. > > Notes > ----- > The following sentence from RFC 2445 should have been removed from the text. > > If > specified as a DATE-TIME value, then it MUST be specified in a UTC > time format. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplification > Area : Applications > Stream : IETF > Verifying Party : IESG > From nobody Mon Jul 13 21:13:32 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 4C8221A8ADD for ; Mon, 13 Jul 2015 21:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 DyXpyZS65rah for ; Mon, 13 Jul 2015 21:13:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F4D1A8ADE for ; Mon, 13 Jul 2015 21:13:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F286F202C3 for ; Tue, 14 Jul 2015 00:13:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 14 Jul 2015 00:13:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ppA coWbKGGvot3ycAd6DTB+9zc0=; b=LAYBLBtKIef2HK08Y1O61OxGKnRJPy055Bs mzYYR15f611BQNyyuEpwSNk8HvH4XtdgPLwEJ61l29Z1cYtpS5lkRQ4ZkwZWf/GO FhFH3dxZuvgrQEAqe+G+IxNwfnuNq4FgNWxDHSzyiirsHFNJfaS8yhNPKeGaZ0pq EAansGg4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ppAcoWbKGGvot3ycAd6DTB+9zc0=; b=qjzgm bGXAdqupRcR/RrRIugMp1Ms71Ymi19LyZV2PACby2r+UGwM7pCZ4wnkjFD2Q6bC4 JNihdw+mnq7dCsjBP1zw6/SXssKTbgNkEOX8sePqLPFZXTQmB/awuM+GYKxNWEVc 2qPcMou9VRqJoCvejRvTdKQLObV5VEGQM4X3Bo= X-Sasl-enc: fjrKFwc6EZD9t9TqoBvD9W7tsXNYjFblU+33e9zHdeHe 1436847207 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E48668012C for ; Tue, 14 Jul 2015 00:13:27 -0400 (EDT) Message-ID: <55A48C66.30905@evertpot.com> Date: Tue, 14 Jul 2015 00:13:26 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [calsify] VAVAILABILITY and priorities 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, 14 Jul 2015 04:13:31 -0000 Hey guys, I'm in the process of implementing VAVAILABILITY into sabre/dav. We are interested in the specification and it solves a real need. So far the specification looks pretty great, but if I'm interpreting it correctly, I do have some concerns: ### non-unique priorities The current draft states[1]: > If > two or more vavailability components have the same PRIORITY value, > then their AVAILABILITY components which fall within the date range > of interest are combined. It is up to the creator of such components > to ensure that combining them produces a consistent and expected > result. This basically leaves it up to the implementer to decide how to interpret the result, and could leave to inconsistencies. I don't know for instance which BUSYTYPE to take as the default. The difference is subtle, but could lead to frustrations in the future. I would want to suggest one of three solutions: 1. Force uniqueness of the value of PRIORITY. 2. Take the order in which the VAVAILABILITY component appears as significant, and treat the ones that appear later as a slightly higher priority. (assuming people will generally want to append) 3. Remove PRIORITY altogether and *only* use the order of components as their priority. ### Order of AVAILABLE Similar to VAVAILABILITY, multiple AVAILABLE components within a single VAVAILABILITY can also generate conflicting, overlapping results. The way I'm currently processing this is simply by using their specified order, and treat the last AVAILABLE component as "most significant". I feel that it would be good to *if* this is the intended behavior, that this is also specified. ### Cosmetic: casing I noticed there's a lot of variation in the document in how VAVAILABILITY (or vavailability or Vavailability) is written. ### Question: relation to VFREEBUSY Both VAVAILABILITY and VFREEBUSY address a similar use-case, the ability to indicate when somebody is available or busy. VAVAILABILITY does this much better because it can use recurrence rules, but VAVAILABILITY is not great for marking off small parts of the day (when there's an event for instance). What do I do if I want to publish my availability information that: * Is timezone and recurrence aware * Can also block off specific timeslots I feel that it's very useful for say, a dentist to be able to publish office hours as well as which timeslots are already booked off. Could I just create a single document that has both VFREEBUSY and VAVAILABILITY components? Cheers and well done =) Evert [1]: https://tools.ietf.org/html/draft-daboo-calendar-availability-05#section-4 From nobody Thu Jul 16 18:08:53 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 7F0FC1B2CF0 for ; Thu, 16 Jul 2015 18:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 7S4XZVQKg21M for ; Thu, 16 Jul 2015 18:08:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C3E1B2CEC for ; Thu, 16 Jul 2015 18:08:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3FADC20498 for ; Thu, 16 Jul 2015 21:08:50 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 16 Jul 2015 21:08:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=H/f kD1VGmON812n8cpPFgWLPS7w=; b=O2PvHlkpGVhz51Ccx+oDWiJG4p4WIGwgVy8 D9sSdAIqvSChW/u4ZqBTDn8dqNw7VzvxdZMbWHiatKkluFMjopz4AYM2XE+fXb4h TJJyACBV6RpkNJXSOBxVkd5aWLER10VYF7KUhZV460LkS+F64RVGNGce5NNG6kcL /FrfPgYw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=H/fkD1VGmON812n8cpPFgWLPS7w=; b=nxxJg fpqsYu1LC8b49xyESTI/fHxFNVxKj0dzLvQBx6/aTWAzkLIrNYAq3zSSnKPHSWqD sLoCmZk/P0zKLUrv0XWMEJ5KPDnqYD9pfKFJORqm55B/eabDMLu9xZSj1TpOrqeR OANvkytgqin9XeZ3OBzr2W0jlpGeH0O+rf8kA8= X-Sasl-enc: v0Bf7y4UaniFDvmfuUv4+TNsfx/pej4zdEAaM+4GU2PI 1437095330 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 0105EC0001C for ; Thu, 16 Jul 2015 21:08:49 -0400 (EDT) Message-ID: <55A855A1.2020808@evertpot.com> Date: Thu, 16 Jul 2015 21:08:49 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [calsify] VAVAILABILITY, problem with AVAILABLE component 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, 17 Jul 2015 01:08:52 -0000 Hi guys, I just ran into the following issue with the VAVAILABILITY spec. Note the definition of the AVAILABLE component: availableprop = *( ; ; the following are REQUIRED, ; but MUST NOT occur more than once ; dtstamp / dtstart / uid / ; ; either 'dtend' or 'duration' MAY appear ; once, but 'dtend' and 'duration' MUST NOT ; occur in the same 'availableprop'. ; 'duration' MUST NOT be present if 'dtstart' ; is not present ; dtend / duration / ; ; the following are OPTIONAL, ; but MUST NOT occur more than once ; created / description / last-mod / recurid / rrule / summary / ; ; the following are OPTIONAL, ; and MAY occur more than once ; categories / comment / contact / exdate / rdate / x-prop / iana-prop ) It states that DTSTART is REQUIRED, but then it also states: ; 'duration' MUST NOT be present if 'dtstart' ; is not present which makes no sense. I think it should simply say that either DURATION or DTEND MUST be specified. Evert From nobody Thu Jul 16 18:20:15 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 DA9501B2D22 for ; Thu, 16 Jul 2015 18:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 eHMsLPBEmgGV for ; Thu, 16 Jul 2015 18:20:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE1C1B2D29 for ; Thu, 16 Jul 2015 18:20:13 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BC96420470 for ; Thu, 16 Jul 2015 21:20:12 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 16 Jul 2015 21:20:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=toa FNbGV6IsGQ726eIRJF7BKBcI=; b=de/yPp9Tzm1ykD4112N2TTlBnYO+/dXTjFz eHbCRC9yJ/BETiXVHDTrgQQzk5xofpmVDoy1NF6myyOQ+5mGFCJk0pu42uH4aJds jexz6lXBu6IMI6YKF/NkdeWw/dB6iGhUi6Je4co6rgj4KqDVwr0TFxO8Y3RbRNYk dFyZjVSM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=toaFNbGV6IsGQ726eIRJF7BKBcI=; b=aXz8c UWU2ZZW3SHLof8tOrzfOUVcG++2/JwJRRMfayjb6ykTQZZd17EFRto101uU5OFGa U8OAj8SfIgvAux3vSetj2Eh+zi2kdMUhBHFR/OPaR80mFKLUvZv/QyXXunAeQYPX jtYn1xjj/qLmyxTZHrLYYCcxSBGrIVO28DOYMs= X-Sasl-enc: +QKQ6AM/SNpltmQl/AHuLyqVqwqPUH6bj3DOrorfNFDd 1437096012 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D6F2C00017 for ; Thu, 16 Jul 2015 21:20:12 -0400 (EDT) Message-ID: <55A8584C.1070405@evertpot.com> Date: Thu, 16 Jul 2015 21:20:12 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [calsify] VAVAILABILITY - multiple overriding mechanisms 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, 17 Jul 2015 01:20:15 -0000 Hey guys, I hope I follow proper etiquette by opening several threads with different subjects as opposed to cramming them all in one. I have a bit of a design concern/question. VAVAILABILITY at its core allows us to specify when we are usually busy using recurrences. To specify exceptions to regular rules (e.g.: normally I'm available 9-5 but certain weeks I might be on vacation) we can use PRIORITY and a a new VAVAILABILITY component to specify this. I just noticed however that there's a secondary way to do overrides: using additional AVAILABLE components with RECURRENCE-ID and/or EXDATE. This makes it all a bit harder to implement. My question pretty much comes down to: is overriding of AVAILABLE instances really needed? Yes, it increases the flexibility of complex rules, but is this flexibility really needed. Are there legit use-cases? Could those use-cases still be fulfilled by removing this feature? At the moment I'm going to not implement this. I worry that I just introduce a path in my code that will never be executed, but it also depends a bit on your response. Cheers, Evert From nobody Fri Jul 17 07:06:55 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 28A801B3428 for ; Fri, 17 Jul 2015 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 msI1wljmLHl8 for ; Fri, 17 Jul 2015 07:06:50 -0700 (PDT) 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 A07E41B3425 for ; Fri, 17 Jul 2015 07:06:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E22E41951BE9; Fri, 17 Jul 2015 10:06:49 -0400 (EDT) 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 zaZgyS9OQMUM; Fri, 17 Jul 2015 10:06:49 -0400 (EDT) Received: from [10.0.1.14] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 00D781951BDE; Fri, 17 Jul 2015 10:06:48 -0400 (EDT) Date: Fri, 17 Jul 2015 10:06:40 -0400 From: Cyrus Daboo To: Evert Pot , calsify@ietf.org Message-ID: <1DCEC8BE46DAF5224EC1FAF3@cyrus.local> In-Reply-To: <55A48C66.30905@evertpot.com> References: <55A48C66.30905@evertpot.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=4766 Archived-At: Subject: Re: [calsify] VAVAILABILITY and priorities 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, 17 Jul 2015 14:06:54 -0000 Hi Evert, Thanks for your review - comments in line. I'll work through your other emails too. --On July 14, 2015 at 12:13:26 AM -0400 Evert Pot wrote: >### non-unique priorities > > The current draft states[1]: > >> If >> two or more vavailability components have the same PRIORITY value, >> then their AVAILABILITY components which fall within the date range >> of interest are combined. It is up to the creator of such components >> to ensure that combining them produces a consistent and expected >> result. > > This basically leaves it up to the implementer to decide how to > interpret the result, and could leave to inconsistencies. I don't know > for instance which BUSYTYPE to take as the default. > > The difference is subtle, but could lead to frustrations in the future. > I would want to suggest one of three solutions: > > 1. Force uniqueness of the value of PRIORITY. > 2. Take the order in which the VAVAILABILITY component appears as > significant, and treat the ones that appear later as a slightly > higher priority. (assuming people will generally want to append) > 3. Remove PRIORITY altogether and *only* use the order of components as > their priority. I don't think we can rely on order as (1) iCalendar itself puts no requirements on ordering of components so it is quite possible that existing iCalendar libraries can re-order components in an arbitrary fashion (and they would not be wrong to do so), and (2) that does not help when combining availability from multiple iCalendar resources on a CalDAV server as again there is no well-defined ordering for resources. So, for this case what I propose doing is adding text to clarify how overlapping, same-priority, VAVAILABILITY should be handled: When two or more VAVAILABILITY components overlap, and they have the same PRIORITY value, the overlapping busy time type is determined by the following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. i.e., if one component has a BUSYTYPE set to BUSY, and the another has BUSYTYPE set to BUSY-UNAVAILABLE, then the effective busy time type over the time range that they overlap would be BUSY. >### Order of AVAILABLE > > Similar to VAVAILABILITY, multiple AVAILABLE components within a single > VAVAILABILITY can also generate conflicting, overlapping results. > > The way I'm currently processing this is simply by using their specified > order, and treat the last AVAILABLE component as "most significant". > > I feel that it would be good to *if* this is the intended behavior, that > this is also specified. Each AVAILABLE component "carves out" a block of free time from the "background" busy time range defined by the VAVAILABILITY component that encompasses the AVAILABLE component. So overlapping components result in the aggregate time-range being marked as free. e.g., AVAILABLE #1 starts at 9 am ends at 12 pm, AVAILABLE #2 starts at 11 am ends at 3 pm, then the overall free time is 9 am to 3 pm. I think that is described by the following text: Step through the resulting list of "VAVAILABILITY" components. For each, the time range covered by the "VAVAILABILITY" component is set to busy and then portions of it defined by the "AVAILABLE" components in the "VAVAILABILITY" component are set to free. If you want I can add a sentence or two to the end of that to clarify the overlapping behavior. > >### Cosmetic: casing > > I noticed there's a lot of variation in the document in how > VAVAILABILITY (or vavailability or Vavailability) is written. Yup - I will go through and fix that. >### Question: relation to VFREEBUSY > > Both VAVAILABILITY and VFREEBUSY address a similar use-case, the ability > to indicate when somebody is available or busy. > > VAVAILABILITY does this much better because it can use recurrence rules, > but VAVAILABILITY is not great for marking off small parts of the day > (when there's an event for instance). > > What do I do if I want to publish my availability information that: > > * Is timezone and recurrence aware > * Can also block off specific timeslots > > I feel that it's very useful for say, a dentist to be able to publish > office hours as well as which timeslots are already booked off. Could I > just create a single document that has both VFREEBUSY and VAVAILABILITY > components? Yes, that is fine. In fact I think that is described in Section 5 which shows how the overall free-time of a calendar user is calculated based on all the iCalendar components that apply to them. In the case of CalDAV those components would all be separate resources in one or more of their calendars, but for other situations it could be whatever is in a "monolithic" iCalendar file. -- Cyrus Daboo From nobody Fri Jul 17 07:11:13 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 A9F601B33FE for ; Fri, 17 Jul 2015 07:11:12 -0700 (PDT) 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 Y9edV_TE1xbN for ; Fri, 17 Jul 2015 07:11:11 -0700 (PDT) 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 7158A1A19EF for ; Fri, 17 Jul 2015 07:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C61BF195206A; Fri, 17 Jul 2015 10:11:10 -0400 (EDT) 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 OTRhW25Mt40J; Fri, 17 Jul 2015 10:11:10 -0400 (EDT) Received: from [10.0.1.14] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 13B30195205E; Fri, 17 Jul 2015 10:11:09 -0400 (EDT) Date: Fri, 17 Jul 2015 10:11:08 -0400 From: Cyrus Daboo To: Evert Pot , calsify@ietf.org Message-ID: <817C230BA63AAE437A1B713F@cyrus.local> In-Reply-To: <55A855A1.2020808@evertpot.com> References: <55A855A1.2020808@evertpot.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=710 Archived-At: Subject: Re: [calsify] VAVAILABILITY, problem with AVAILABLE component 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, 17 Jul 2015 14:11:12 -0000 Hi Evert, --On July 16, 2015 at 9:08:49 PM -0400 Evert Pot wrote: > It states that DTSTART is REQUIRED, but then it also states: > > ; 'duration' MUST NOT be present if 'dtstart' > ; is not present > > which makes no sense. I think it should simply say that either DURATION > or DTEND MUST be specified. I will copy the text from RFC5545 that is used to define VEVENT: ; Either 'dtend' or 'duration' MAY appear in ; an 'availableprop', but 'dtend' and 'duration' ; MUST NOT occur in the same 'availableprop'. ; dtend / duration / -- Cyrus Daboo From nobody Fri Jul 17 07:29: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 C277D1B3456 for ; Fri, 17 Jul 2015 07:29:06 -0700 (PDT) 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 Yi0TSSeOYN32 for ; Fri, 17 Jul 2015 07:29:03 -0700 (PDT) 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 419021B345B for ; Fri, 17 Jul 2015 07:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8C3C81952359; Fri, 17 Jul 2015 10:28:33 -0400 (EDT) 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 RifqVvoG9r6f; Fri, 17 Jul 2015 10:28:33 -0400 (EDT) Received: from [10.0.1.14] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id ABD9E195234E; Fri, 17 Jul 2015 10:28:32 -0400 (EDT) Date: Fri, 17 Jul 2015 10:28:30 -0400 From: Cyrus Daboo To: Evert Pot , calsify@ietf.org Message-ID: <53A931A4626AC8AB20CFF6B2@cyrus.local> In-Reply-To: <55A8584C.1070405@evertpot.com> References: <55A8584C.1070405@evertpot.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=2139 Archived-At: Subject: Re: [calsify] VAVAILABILITY - multiple overriding mechanisms 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, 17 Jul 2015 14:29:07 -0000 Hi Evert, --On July 16, 2015 at 9:20:12 PM -0400 Evert Pot wrote: > Hey guys, I hope I follow proper etiquette by opening several threads > with different subjects as opposed to cramming them all in one. Multiple threads is fine - makes it a little easier to track specific issues. > I have a bit of a design concern/question. > > > VAVAILABILITY at its core allows us to specify when we are usually busy > using recurrences. > > To specify exceptions to regular rules (e.g.: normally I'm available 9-5 > but certain weeks I might be on vacation) we can use PRIORITY and a a > new VAVAILABILITY component to specify this. > > I just noticed however that there's a secondary way to do overrides: > using additional AVAILABLE components with RECURRENCE-ID and/or EXDATE. > > This makes it all a bit harder to implement. My question pretty much > comes down to: is overriding of AVAILABLE instances really needed? Yes, > it increases the flexibility of complex rules, but is this flexibility > really needed. Are there legit use-cases? Could those use-cases still be > fulfilled by removing this feature? > > At the moment I'm going to not implement this. I worry that I just > introduce a path in my code that will never be executed, but it also > depends a bit on your response. >From my perspective I don't see it as being more complex - if you already have a recurrence processing "engine" to handle VEVENTs, then dealing with overrides and EXDATEs in AVAILABLE is not that hard. You are right that this does lead to redundancy in that there are two ways to "override", but I think overrides using PRIORITY are meant to be applied to large blocks of time where the overall pattern of available time needs to be changed, as opposed to AVAILABLE overrides where small adjustments to a single "schedule" are needed. I do think being able to override AVAILABLE components is useful - most particularly being able to add EXDATEs as that is the most efficient way to remove available slots on, for example, a holiday. I'd like to get Mike's take on this too (he is out on vacation this week). -- Cyrus Daboo From nobody Fri Jul 17 09:28:47 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 8F5A01A889C for ; Fri, 17 Jul 2015 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 uwQlCVdqZuqQ for ; Fri, 17 Jul 2015 09:28:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724681A897F for ; Fri, 17 Jul 2015 09:28:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CE57820BEB for ; Fri, 17 Jul 2015 12:28:42 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 17 Jul 2015 12:28:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=x9YbIsHN53D/e9aJDCEH7syf87g=; b=Ls8ROD 2xPJ8OxIUxZa+rfoFTz/hx+3A/rmCMALU+N+ADIUdq1QXPgxpu0ppuIyOX7eKQVw VEeTHUTiXMMEKWWak0jdUsGbXte0mJeGJfcYw3wuE6HzVeG9yorZtai6mQu4ugw9 RJNdkyMv+b/5POiM4FAhsEw81PZV2S3Gz6lKo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=x9YbIsHN53D/e9a JDCEH7syf87g=; b=hpC65SDqVz21AR6BGChCqTP74xCDHxlhtzXrI4+Fc/O2oKZ pzgCx8mrNsObY1ARPyzdQx6NSNWNgzOCNRHS37jsQcevy29jUU1/ZUzQkQALzuR7 YjYhw6HvV27plRy1hYloX1TqMV0A2IBJQGnpkySLA9eP0z+SOX83jrdAa0T8= X-Sasl-enc: LWSOdDiBwN/nNDFlu1eJW9bpx/T+Dumr41OmzUP6LSn8 1437150522 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 86B1A68012C; Fri, 17 Jul 2015 12:28:42 -0400 (EDT) Message-ID: <55A92D3A.50702@evertpot.com> Date: Fri, 17 Jul 2015 12:28:42 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <55A48C66.30905@evertpot.com> <1DCEC8BE46DAF5224EC1FAF3@cyrus.local> In-Reply-To: <1DCEC8BE46DAF5224EC1FAF3@cyrus.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] VAVAILABILITY and priorities 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, 17 Jul 2015 16:28:45 -0000 Hi Cyrus, > > I don't think we can rely on order as (1) iCalendar itself puts no > requirements on ordering of components so it is quite possible that > existing iCalendar libraries can re-order components in an arbitrary > fashion (and they would not be wrong to do so), and (2) that does not > help when combining availability from multiple iCalendar resources on a > CalDAV server as again there is no well-defined ordering for resources. > > So, for this case what I propose doing is adding text to clarify how > overlapping, same-priority, VAVAILABILITY should be handled: > > When two or more VAVAILABILITY components overlap, and they have the > same PRIORITY value, the overlapping busy time type is determined by > the following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. i.e., if > one component has a BUSYTYPE set to BUSY, and the another has BUSYTYPE > set to BUSY-UNAVAILABLE, then the effective busy time type over the > time range that they overlap would be BUSY. Hm... even then there would be a chance of multiple overlapping components, if they have the same BUSYTYPE. Even if the answer to that is that it's 'left undefined', it would still be worthwhile to update that paragraph to say that. I think in real-life scenarios it might not really be important. > >> ### Order of AVAILABLE >> >> Similar to VAVAILABILITY, multiple AVAILABLE components within a single >> VAVAILABILITY can also generate conflicting, overlapping results. >> >> The way I'm currently processing this is simply by using their specified >> order, and treat the last AVAILABLE component as "most significant". >> >> I feel that it would be good to *if* this is the intended behavior, that >> this is also specified. > > Each AVAILABLE component "carves out" a block of free time from the > "background" busy time range defined by the VAVAILABILITY component that > encompasses the AVAILABLE component. So overlapping components result in > the aggregate time-range being marked as free. e.g., AVAILABLE #1 starts > at 9 am ends at 12 pm, AVAILABLE #2 starts at 11 am ends at 3 pm, then > the overall free time is 9 am to 3 pm. I think that is described by the > following text: > > Step through the resulting list of "VAVAILABILITY" components. For > each, the time range covered by the "VAVAILABILITY" component is set to > busy and then portions of it defined by the "AVAILABLE" components in > the "VAVAILABILITY" component are set to free. > > If you want I can add a sentence or two to the end of that to clarify > the overlapping behavior. I actually take back this comment. I'm further along implementing this and now this makes total sense =) > >> >> ### Cosmetic: casing >> >> I noticed there's a lot of variation in the document in how >> VAVAILABILITY (or vavailability or Vavailability) is written. > > Yup - I will go through and fix that. > >> ### Question: relation to VFREEBUSY >> >> Both VAVAILABILITY and VFREEBUSY address a similar use-case, the ability >> to indicate when somebody is available or busy. >> >> VAVAILABILITY does this much better because it can use recurrence rules, >> but VAVAILABILITY is not great for marking off small parts of the day >> (when there's an event for instance). >> >> What do I do if I want to publish my availability information that: >> >> * Is timezone and recurrence aware >> * Can also block off specific timeslots >> >> I feel that it's very useful for say, a dentist to be able to publish >> office hours as well as which timeslots are already booked off. Could I >> just create a single document that has both VFREEBUSY and VAVAILABILITY >> components? > > Yes, that is fine. In fact I think that is described in Section 5 which > shows how the overall free-time of a calendar user is calculated based > on all the iCalendar components that apply to them. In the case of > CalDAV those components would all be separate resources in one or more > of their calendars, but for other situations it could be whatever is in > a "monolithic" iCalendar file. Thanks, that sounds good! Evert From nobody Fri Jul 17 09:29: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 225541A889C for ; Fri, 17 Jul 2015 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 psBr969S1Xeb for ; Fri, 17 Jul 2015 09:29:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9741A8981 for ; Fri, 17 Jul 2015 09:29:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2D24220364 for ; Fri, 17 Jul 2015 12:29:50 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 17 Jul 2015 12:29:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=OXHo3X1l5nkmM8GwC8m2bm18zGU=; b=RzHNkd xwx8qVK/lMQ/+5kpzp2ODlISovjDlEURzkVk8qjUP69QfpdKJugYqPHwDdlJrsfn k4K3N9J/PDIQdOS/2u6TY0Usb+lZ1yw3LTpsfth+YBgcHk5k4LZa0ahi0HK9/r7/ twAjmzW3IMS6k+GyykJ3cIB+jCov0TGbw5yN4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OXHo3X1l5nkmM8G wC8m2bm18zGU=; b=fUTJDA5UoF1zFCXw5JT/wkuNL5Kzz50O7TCeypkldj6KsGP JK1p8P6EZTO4Ufag95ChYfucQOvMakv8GuflqY2LosEcstW9VmUZsZqcatz2MeiN 7W/jJgN6nVEAm2OdYnbI/GpRj3dUsaU6F4ciFfneM4HOn1Egouk3lXcyfDIA= X-Sasl-enc: rG+M4VJTihyrqvry2MNyq2miqTzi/hGb2SHPXb08gyzA 1437150589 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id DC273680081; Fri, 17 Jul 2015 12:29:49 -0400 (EDT) Message-ID: <55A92D7D.7000800@evertpot.com> Date: Fri, 17 Jul 2015 12:29:49 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <55A855A1.2020808@evertpot.com> <817C230BA63AAE437A1B713F@cyrus.local> In-Reply-To: <817C230BA63AAE437A1B713F@cyrus.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] VAVAILABILITY, problem with AVAILABLE component 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, 17 Jul 2015 16:29:53 -0000 On 2015-07-17 10:11 AM, Cyrus Daboo wrote: > Hi Evert, > > --On July 16, 2015 at 9:08:49 PM -0400 Evert Pot wrote: > >> It states that DTSTART is REQUIRED, but then it also states: >> >> ; 'duration' MUST NOT be present if 'dtstart' >> ; is not present >> >> which makes no sense. I think it should simply say that either DURATION >> or DTEND MUST be specified. > > I will copy the text from RFC5545 that is used to define VEVENT: > > ; Either 'dtend' or 'duration' MAY appear in > ; an 'availableprop', but 'dtend' and 'duration' > ; MUST NOT occur in the same 'availableprop'. > ; > dtend / duration / > > I think it should say: Either 'dtend' or 'duration' MUST appear An AVAILABILE component without DTEND or DURATION is meaningless as it would free up no actual time. Evert From nobody Fri Jul 17 13:09:33 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 5F6791B3015 for ; Fri, 17 Jul 2015 13:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 umIgVNntUXFi for ; Fri, 17 Jul 2015 13:09:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5221B3016 for ; Fri, 17 Jul 2015 13:09:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B5A1420CB0 for ; Fri, 17 Jul 2015 16:09:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 17 Jul 2015 16:09:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=PEO3D5E5ncqOGPDF143IZh7N2lw=; b=PmXBiR AQ2Gy9OQFlfBe1s2wgIf+RgALfgQit7KVMVZOTHgIAoar/5EOK7ACl6x6E2DuzPw xX2I/5MCZmxqf48rlPEM0KedhZU80kKNBtsL+ErnFppUBKG6FI3/Sey499nXAfp8 PZxUesKGdDY9M/ipXBSCOyYQgANcyVLb8BXbg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PEO3D5E5ncqOGPD F143IZh7N2lw=; b=EcoH0sr/E/itmJlR4Bh/+lkkvE2FL59n50O5Lk43xaXlMbI GCcS7KXxKZfS2dWTZww8/JIBPPI9eDqcTLHopwM/ndtbzdI/8+uLRI+hsGGsllcq bnNnPGVAi3gKnEPdaB+pVrHA4HBJoP8/EpdFTUCvlGrfi7ePYHrjXvejZKnw= X-Sasl-enc: a+HYwuCKiTpdx7R2fbJJY3tyirx13roomIYHd1mRfc2f 1437163757 Received: from Pasta.local (cpebc4dfba28f23-cmbc4dfba28f20.cpe.net.cable.rogers.com [174.113.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 697A66801E0; Fri, 17 Jul 2015 16:09:17 -0400 (EDT) Message-ID: <55A960ED.1050801@evertpot.com> Date: Fri, 17 Jul 2015 16:09:17 -0400 From: Evert Pot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <55A8584C.1070405@evertpot.com> <53A931A4626AC8AB20CFF6B2@cyrus.local> In-Reply-To: <53A931A4626AC8AB20CFF6B2@cyrus.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] VAVAILABILITY - multiple overriding mechanisms 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, 17 Jul 2015 20:09:31 -0000 > >> From my perspective I don't see it as being more complex - if you already > have a recurrence processing "engine" to handle VEVENTs, then dealing > with overrides and EXDATEs in AVAILABLE is not that hard. You are right > that this does lead to redundancy in that there are two ways to > "override", but I think overrides using PRIORITY are meant to be applied > to large blocks of time where the overall pattern of available time > needs to be changed, as opposed to AVAILABLE overrides where small > adjustments to a single "schedule" are needed. > > I do think being able to override AVAILABLE components is useful - most > particularly being able to add EXDATEs as that is the most efficient way > to remove available slots on, for example, a holiday. > > I'd like to get Mike's take on this too (he is out on vacation this week). > The issue I see has a bit to do with user interfaces as well. I worry that we'll never actually see viable user interfaces that can take full advantage of this built-in flexibility. Just based on the examples I've seen, I believe it's more likely that clients will pick a smaller subset, as for example the apple clients have done. I think scope reduction is always a great thing if we can get away with it ;) Even if you have code lined up to make this easy to do. This topic leads me to the next question as well: Given that the clients that exist today *already* are likely going to support a limited subset, can we give any recommendations in the spec describing what a client should do with VAVAILABILITY components that are too complex to express in the UI? Is the client expected to wipe out the existing data when making changes, or should it attempt to preserve any existing data and just write VAVAILABILITY components. If it's the latter, we should probably try to describe the strategy for this doing this, including reordering existing PRIORITY's. Let me know if this makes sense. Evert From nobody Fri Jul 17 21:23:05 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 B6B6A1A88AC for ; Fri, 17 Jul 2015 21:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 m4ewNqt8XjJv for ; Fri, 17 Jul 2015 21:23:02 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5D81A88A4 for ; Fri, 17 Jul 2015 21:23:01 -0700 (PDT) Received: by qkdl129 with SMTP id l129so81477767qkd.0 for ; Fri, 17 Jul 2015 21:23:01 -0700 (PDT) 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:content-transfer-encoding; bh=s0GjuSSR+iddM8ox2Bl5+KjBveXqnGm/hAzAyFug25o=; b=oVFsAT9SQTUn1JoZrHhPnowdlElh6ndhPD4bjX+/DcvUwOO5BE3OoD+l3mWr5SLpDd cgf6hNM/Y9KivBOcoe8dwB+MruB7KML9pRTPzrNW5S03F5nSqYz39745b0nAHzpkc7iX 6UQZgxfcJzxj7y84iJJNU7I0WN8C86LzJICczpMeidhjfboP5JagPi4xuH7f+o/tR14V oRCjH313dTttVFv6fwKI3pTxwYA5HGM92Z99K83cSCNadH0N+1YVFjaupF3dameHnl1u k3loW6WjT1LRg9n0rCncTlxxYMBlMhkuRcC9Zbl5a/QjFRX6SMM8EC16JXZDigSJi5LK 0ffQ== X-Received: by 10.55.43.84 with SMTP id r81mr31313515qkh.8.1437193381264; Fri, 17 Jul 2015 21:23:01 -0700 (PDT) Received: from Michaels-MBP.hotspot (cpe-76-179-140-229.maine.res.rr.com. [76.179.140.229]) by smtp.googlemail.com with ESMTPSA id g33sm6981538qgg.4.2015.07.17.21.23.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 21:23:00 -0700 (PDT) Message-ID: <55A9D4B0.608@gmail.com> Date: Sat, 18 Jul 2015 01:23:12 -0300 From: Michael Douglass User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org References: <55A8584C.1070405@evertpot.com> <53A931A4626AC8AB20CFF6B2@cyrus.local> In-Reply-To: <53A931A4626AC8AB20CFF6B2@cyrus.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] VAVAILABILITY - multiple overriding mechanisms 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: Sat, 18 Jul 2015 04:23:03 -0000 There's a significant difference - and this was important for some usages. Overrides are a requirement for laying out time which might not follow a completely rule based pattern. That is exactly the same approach as for events and tasks. The use case for availability is that somebody would describe their regular availabiity with a single base vavailability component including any necessary overrides. For exceptional periods - such as vacations conferences etc - providing a new VAVAILABILITY with higher priority allows one to overrride a period of time without modifying the original component. This is also of use in the smartgrid work - in fact it was that group that first asked about the algebra of availability The first part as Cyrus said is already implemented - it's how we handle events and tasks. The second part - using priority - is important to a number of use cases Availability is a little different from events. People lay out their availability - 9-12 on weds, 15:00-17:00 on thurs etc - and want to be able to leave it untouched. On 7/17/15 11:28, Cyrus Daboo wrote: > Hi Evert, > > --On July 16, 2015 at 9:20:12 PM -0400 Evert Pot wrote: > >> Hey guys, I hope I follow proper etiquette by opening several threads >> with different subjects as opposed to cramming them all in one. > > Multiple threads is fine - makes it a little easier to track specific > issues. > >> I have a bit of a design concern/question. >> >> >> VAVAILABILITY at its core allows us to specify when we are usually busy >> using recurrences. >> >> To specify exceptions to regular rules (e.g.: normally I'm available 9-5 >> but certain weeks I might be on vacation) we can use PRIORITY and a a >> new VAVAILABILITY component to specify this. >> >> I just noticed however that there's a secondary way to do overrides: >> using additional AVAILABLE components with RECURRENCE-ID and/or EXDATE. >> >> This makes it all a bit harder to implement. My question pretty much >> comes down to: is overriding of AVAILABLE instances really needed? Yes, >> it increases the flexibility of complex rules, but is this flexibility >> really needed. Are there legit use-cases? Could those use-cases still be >> fulfilled by removing this feature? >> >> At the moment I'm going to not implement this. I worry that I just >> introduce a path in my code that will never be executed, but it also >> depends a bit on your response. > >> From my perspective I don't see it as being more complex - if you >> already > have a recurrence processing "engine" to handle VEVENTs, then dealing > with overrides and EXDATEs in AVAILABLE is not that hard. You are > right that this does lead to redundancy in that there are two ways to > "override", but I think overrides using PRIORITY are meant to be > applied to large blocks of time where the overall pattern of available > time needs to be changed, as opposed to AVAILABLE overrides where > small adjustments to a single "schedule" are needed. > > I do think being able to override AVAILABLE components is useful - > most particularly being able to add EXDATEs as that is the most > efficient way to remove available slots on, for example, a holiday. > > I'd like to get Mike's take on this too (he is out on vacation this > week). > From nobody Fri Jul 17 21:30:20 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 220171A8968 for ; Fri, 17 Jul 2015 21:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 sNWazH_xpWkb for ; Fri, 17 Jul 2015 21:30:18 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4175D1A885E for ; Fri, 17 Jul 2015 21:30:18 -0700 (PDT) Received: by qkfc129 with SMTP id c129so38634363qkf.1 for ; Fri, 17 Jul 2015 21:30:17 -0700 (PDT) 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:content-transfer-encoding; bh=1LStpcnW8AuvIhpqLEX96fn3wffesRBhRH6LdmhyXZM=; b=qlBSuTU+llqMvjUAJmqWkTdbgOEjZEF5YvEfSeOzyCzllJvbOedCnmzn3l1e7E1NfR mVhvryDjefQ1TH9mYZzSnJrb3bCw4F6VR5pw4uvKY2vfuEWgLxYwIZbCvW9e6rtOUjcV J6mvhV+kOocnEcJSMlh3lzAU4Qneh96peEPJRSuhf5xS2RKFfMJ2r6Zz586aTUgSnJeq 1hRh/6BDdWIS2wx5H+/zgf30IEXLu6DKyWjkvgElMAVjQ7C1HdwWg/W1HMIQW28oBQ00 /f36zX83aqK9esBHy5nWNzn9DUsmv4d8O3Jsmu0m0Dg2+irnC8LHi5txd7/ognc0fN/g nfRQ== X-Received: by 10.140.150.142 with SMTP id 136mr25095962qhw.17.1437193817524; Fri, 17 Jul 2015 21:30:17 -0700 (PDT) Received: from Michaels-MBP.hotspot (cpe-76-179-140-229.maine.res.rr.com. [76.179.140.229]) by smtp.googlemail.com with ESMTPSA id d6sm6988278qgf.0.2015.07.17.21.30.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 21:30:17 -0700 (PDT) Message-ID: <55A9D664.6080007@gmail.com> Date: Sat, 18 Jul 2015 01:30:28 -0300 From: Michael Douglass User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org References: <55A8584C.1070405@evertpot.com> <53A931A4626AC8AB20CFF6B2@cyrus.local> <55A960ED.1050801@evertpot.com> In-Reply-To: <55A960ED.1050801@evertpot.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] VAVAILABILITY - multiple overriding mechanisms 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: Sat, 18 Jul 2015 04:30:20 -0000 On 7/17/15 17:09, Evert Pot wrote: >>> From my perspective I don't see it as being more complex - if you already >> have a recurrence processing "engine" to handle VEVENTs, then dealing >> with overrides and EXDATEs in AVAILABLE is not that hard. You are right >> that this does lead to redundancy in that there are two ways to >> "override", but I think overrides using PRIORITY are meant to be applied >> to large blocks of time where the overall pattern of available time >> needs to be changed, as opposed to AVAILABLE overrides where small >> adjustments to a single "schedule" are needed. >> >> I do think being able to override AVAILABLE components is useful - most >> particularly being able to add EXDATEs as that is the most efficient way >> to remove available slots on, for example, a holiday. >> >> I'd like to get Mike's take on this too (he is out on vacation this week). >> > The issue I see has a bit to do with user interfaces as well. I worry > that we'll never actually see viable user interfaces that can take full > advantage of this built-in flexibility. > > Just based on the examples I've seen, I believe it's more likely that > clients will pick a smaller subset, as for example the apple clients > have done. > > I think scope reduction is always a great thing if we can get away with > it ;) Even if you have code lined up to make this easy to do. This was a feature that was requested. I don't know that we go about adding complexity without some reason. We hadn't considered this issue until we were asked to. I've had a number of questions from tha OASIS group on this issue which leads me to believe they are actively implementing it. > > This topic leads me to the next question as well: > > Given that the clients that exist today *already* are likely going to > support a limited subset, can we give any recommendations in the spec > describing what a client should do with VAVAILABILITY components that > are too complex to express in the UI? > > Is the client expected to wipe out the existing data when making > changes, or should it attempt to preserve any existing data and just > write VAVAILABILITY components. If it's the latter, we should probably > try to describe the strategy for this doing this, including reordering > existing PRIORITY's. I believe the priority approach makes it easier to handle and represent. However, apparently we already have the situation where clients don't support RDATE which would have thought was the easier part. Not sure what to say about that. I'll be out of touch again periodically - back in the US but travelling around Maine > > Let me know if this makes sense. > > Evert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Tue Jul 21 07:42:08 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 6A8301A88D2; Tue, 21 Jul 2015 07:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 bt-RsI-PwHxB; Tue, 21 Jul 2015 07:42:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id CE0E31A88B4; Tue, 21 Jul 2015 07:42:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3648518045A; Tue, 21 Jul 2015 07:38:10 -0700 (PDT) To: joseph.silvestre@cozycloud.cc, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150721143810.3648518045A@rfc-editor.org> Date: Tue, 21 Jul 2015 07:38:10 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, calsify@ietf.org Subject: [calsify] [Errata Verified] RFC5545 (4414) 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, 21 Jul 2015 14:42:03 -0000 The following errata report has been verified for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4414 -------------------------------------- Status: Verified Type: Editorial Reported by: Joseph Silvestre Date Reported: 2015-07-10 Verified by: Barry Leiba (IESG) Section: 3.3.10 Original Text ------------- The UNTIL rule part defines a DATE or DATE-TIME value that bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this DATE or DATE-TIME becomes the last instance of the recurrence. The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. If not present, and the COUNT rule part is also not present, the "RRULE" is considered to repeat forever. Corrected Text -------------- The UNTIL rule part defines a DATE or DATE-TIME value that bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this DATE or DATE-TIME becomes the last instance of the recurrence. The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If not present, and the COUNT rule part is also not present, the "RRULE" is considered to repeat forever. Notes ----- The following sentence from RFC 2445 should have been removed from the text. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Jul 27 11:14:05 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 34C3E1B3183 for ; Mon, 27 Jul 2015 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 CqUri5fk7fMO for ; Mon, 27 Jul 2015 11:14:01 -0700 (PDT) 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 3BF8F1B3186 for ; Mon, 27 Jul 2015 11:14:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 83AD41A1C205; Mon, 27 Jul 2015 14:14:00 -0400 (EDT) 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 Qp2EMgJyOBne; Mon, 27 Jul 2015 14:13:59 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 306FB1A1C1FA; Mon, 27 Jul 2015 14:13:59 -0400 (EDT) Date: Mon, 27 Jul 2015 14:13:57 -0400 From: Cyrus Daboo To: calsify@ietf.org Message-ID: <1C7A218743F29CB5A61E7CEE@caldav.corp.apple.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=1169 Archived-At: Cc: Barry Leiba Subject: [calsify] Errata for 6868 (parameter encoding) 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, 27 Jul 2015 18:14:04 -0000 Hi folks, An error report was recently filed against RFC6868 (). The error relates to how to decode something like: FOO=^^n The report suggests there is ambiguity in the spec about how that should be processed and I agree with that. The question is how best to address this problem. The two possibilities are: 1) A 3-pass approach where each pattern from the decode list in Section 3, is decoded. i.e., one pass to decode all the ^n patterns, another to decode all ^^, another to decode ^'. 2) A single-pass (left-to-right) approach where the first occurrence of a ^ character triggers a check of the next character for decoding. I prefer #2 (as that is how I coded my own implementation, and from a parsing performance standpoint, I think is better than the 3-pass approach). I'd like to hear from others who have implemented this spec and see which of the above approaches were used. If we can agree on #2 then I will ask for the current errata to be rejected in favor of a new one that I will file with appropriate text to cover single-pass/left-to-right processing. -- Cyrus Daboo From nobody Mon Jul 27 11:27:13 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 71CD91B31BA for ; Mon, 27 Jul 2015 11:27:12 -0700 (PDT) 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, 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 UB0SJPdnsH3D for ; Mon, 27 Jul 2015 11:27:10 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3421AC44E for ; Mon, 27 Jul 2015 11:27:10 -0700 (PDT) Received: by wibud3 with SMTP id ud3so151333452wib.1 for ; Mon, 27 Jul 2015 11:27:09 -0700 (PDT) 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=zwmEQ5ePuVdBuE1X77ch7nvGo+Zg85sNJdzFbAvYY5Q=; b=P2HNKrsSaafbopXdY6DiZS/Ua3VoLtmTZYwMVK8cXIVGGCH7Q0g8LTyNAgjgUc+hfD iymiLaVMZW1XUI+2K3l6YdKxHoXtP+FyrcCZP0qbj6fs0fdinBvdEj1K5NJMDsS4sFc0 QPCLR13F4Fc5lPRp6T+adX4t1VQJw/indrSnRTnYzFeILTdNkXOrtU6gA3H+WDTgmhx3 CFU1s984SxCZb/Nqdf+aXDJH/ksf7bom4jOdiavOX0mICZbrs+tr9XqG1gjzwR3oSDEI LmZ8zk+XJ3ULfH3irzQms6ds0eP564gLv0QM6d1+mSEtP4nBpYEUrJlzkMzgVUstv4H3 O06A== X-Received: by 10.194.58.109 with SMTP id p13mr63421192wjq.36.1438021629027; Mon, 27 Jul 2015 11:27:09 -0700 (PDT) Received: from smtp.dmfs.org (p4FF0EC36.dip0.t-ipconnect.de. [79.240.236.54]) by smtp.googlemail.com with ESMTPSA id b13sm14912284wic.15.2015.07.27.11.27.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 11:27:05 -0700 (PDT) Sender: Marten Gajda Received: from localhost.localdomain (p3EE07D55.dip0.t-ipconnect.de [62.224.125.85]) by smtp.dmfs.org (Postfix) with ESMTPSA id D6413656 for ; Mon, 27 Jul 2015 20:27:03 +0200 (CEST) Message-ID: <55B677ED.7050404@dmfs.org> Date: Mon, 27 Jul 2015 20:26:53 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: calsify@ietf.org References: <1C7A218743F29CB5A61E7CEE@caldav.corp.apple.com> In-Reply-To: <1C7A218743F29CB5A61E7CEE@caldav.corp.apple.com> Content-Type: multipart/alternative; boundary="------------030702040305090301050804" Archived-At: Subject: Re: [calsify] Errata for 6868 (parameter encoding) 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, 27 Jul 2015 18:27:12 -0000 This is a multi-part message in MIME format. --------------030702040305090301050804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree that #2 is the best choice. That goes in line with how '\' escaping is handled in general (BASH, SQL, C, Java, , ...). Everything else would be very confusing and non-intuitive. cheers Marten Am 27.07.2015 um 20:13 schrieb Cyrus Daboo: > Hi folks, > An error report was recently filed against RFC6868 > (). > The error relates to how to decode something like: > > FOO=^^n > > The report suggests there is ambiguity in the spec about how that > should be processed and I agree with that. The question is how best to > address this problem. The two possibilities are: > > 1) A 3-pass approach where each pattern from the decode list in > Section 3, is decoded. i.e., one pass to decode all the ^n patterns, > another to decode all ^^, another to decode ^'. > > 2) A single-pass (left-to-right) approach where the first occurrence > of a ^ character triggers a check of the next character for decoding. > > I prefer #2 (as that is how I coded my own implementation, and from a > parsing performance standpoint, I think is better than the 3-pass > approach). > > I'd like to hear from others who have implemented this spec and see > which of the above approaches were used. > > If we can agree on #2 then I will ask for the current errata to be > rejected in favor of a new one that I will file with appropriate text > to cover single-pass/left-to-right processing. > -- *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 --------------030702040305090301050804 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I agree that #2 is the best choice. That goes in line with how '\' escaping is handled in general (BASH, SQL, C, Java, <you name it>, ...). Everything else would be very confusing and non-intuitive.

cheers

Marten


Am 27.07.2015 um 20:13 schrieb Cyrus Daboo:
Hi folks,
An error report was recently filed against RFC6868 (<https://www.rfc-editor.org/errata_search.php?rfc=6868&eid=4374>). The error relates to how to decode something like:

FOO=^^n

The report suggests there is ambiguity in the spec about how that should be processed and I agree with that. The question is how best to address this problem. The two possibilities are:

1) A 3-pass approach where each pattern from the decode list in Section 3, is decoded. i.e., one pass to decode all the ^n patterns, another to decode all ^^, another to decode ^'.

2) A single-pass (left-to-right) approach where the first occurrence of a ^ character triggers a check of the next character for decoding.

I prefer #2 (as that is how I coded my own implementation, and from a parsing performance standpoint, I think is better than the 3-pass approach).

I'd like to hear from others who have implemented this spec and see which of the above approaches were used.

If we can agree on #2 then I will ask for the current errata to be rejected in favor of a new one that I will file with appropriate text to cover single-pass/left-to-right processing.


--

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

--------------030702040305090301050804--