http://permalink.gmane.org/gmane.ietf.calsify hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.calsify/2295 <pre>Yes, I think there's no strong reason for that requirement, we can remove it. The motivation was that RSCALE parameter influences valid ranges of other parameters, so needs to be parsed first. But it is probably not strong enough argument for this requirement. On Tue, May 7, 2013 at 10:47 PM, Caleb Richardson &lt;calebrichardson&lt; at &gt;gmail.com _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Gregory Yakushev 2013-05-07T21:37:15 http://permalink.gmane.org/gmane.ietf.calsify/2294 <pre>Thanks for the comments! We will consider replacing 'L' suffix with BYLEAPMONTH parameter in the next draft. There will be slight delay because my coauthor (Cyrus Daboo) is on vacation. Is there anything else that sticks out in the proposal? On Tue, May 7, 2013 at 1:04 AM, James Lal &lt;james&lt; at &gt;lightsofapollo.com&gt; wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Gregory Yakushev 2013-05-07T20:20:23 http://permalink.gmane.org/gmane.ietf.calsify/2293 <pre>BYLEAPMONTH+1 gives us a clear(er) way to opt-into new features and optimize specifically for them.. On Mon, May 6, 2013 at 2:16 PM, Philipp Kewisch &lt;kewisch&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> James Lal 2013-05-06T23:04:16 http://permalink.gmane.org/gmane.ietf.calsify/2292 <pre>In that case the RSCALE draft should also be changed to add BYLEAPMONTH. I would be fine with this implementation, parsers that don't know rscale won't totally freak out. Philipp On May 6, 2013, at 22:37, Gregory Yakushev &lt;yakushev&lt; at &gt;google.com&gt; wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Philipp Kewisch 2013-05-06T21:16:14 http://permalink.gmane.org/gmane.ietf.calsify/2291 <pre>I see your point about the {8, "11L"} case. As an option, you can do this: [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth": [8], "byleapmonth": [11] } ] On Mon, May 6, 2013 at 10:31 PM, Gregory Yakushev &lt;yakushev&lt; at &gt;google.com&gt;wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Gregory Yakushev 2013-05-06T20:37:20 http://permalink.gmane.org/gmane.ietf.calsify/2290 <pre>Our primary motivation to use 'L' suffix over LEAPMONTH=TRUE was that RRULE is a string anyway, and 'L' is shorter. But if you have a structured representation of RRULE, using a separate boolean makes total sense. To expand the RRULE you will need some library (such as icu-project.org), which probably accepts leap months as a boolean and not an 'L' suffix. For clients not supporting RSCALE parameter it is actually better to fail on recurrence rules that have it, because otherwise they will produce incorrect expansion and cause a date inconsistency. On Mon, May 6, 2013 at 9:25 PM, Philipp Kewisch &lt;kewisch&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Gregory Yakushev 2013-05-06T20:31:40 http://permalink.gmane.org/gmane.ietf.calsify/2289 <pre>That won't work for multiple months where only one of them is leapmonth: [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth": [8, "11L"] } ] Philipp On 5/6/13 9:09 PM, Michael Angstadt wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Philipp Kewisch 2013-05-06T19:25:56 http://permalink.gmane.org/gmane.ietf.calsify/2288 <pre>I wonder how we should handle this for jCal. the rscale draft says that for "leap months", it should be suffixed with an "L". This turns the number value into a string value. I don't know if this is correct in the calendar system, but in theory we could do this: [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth": "11L" } ] A parser expecting a number would be pretty confused though. Philipp On 5/6/13 4:27 PM, Gregory Yakushev wrote: _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Philipp Kewisch 2013-05-06T18:19:55 http://permalink.gmane.org/gmane.ietf.calsify/2287 <pre>A draft RFC to support non-Gregorian recurrence rules in iCalendar is available for discussion. It will allow us to specify events like Chinese New Year, Ramadan or Korean birthdays. Please see the links below. Comments are welcome on the calsify&lt; at &gt;ietf.org mailing list. If adopted, we are likely to start using it at Google, and recurrences with RSCALE parameter will appear in iCalendar data provided by us. Grigory Yakushev Google Inc. Title: Non-Gregorian Recurrence Rules in iCalendar URL: http://www.ietf.org/internet-drafts/draft-daboo-icalendar-rscale-00.txt Status: http://datatracker.ietf.org/doc/draft-daboo-icalendar-rscale Htmlized: http://tools.ietf.org/html/draft-daboo-icalendar-rscale-00 _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Gregory Yakushev 2013-05-06T14:27:54 http://permalink.gmane.org/gmane.ietf.calsify/2286 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:13:13 http://permalink.gmane.org/gmane.ietf.calsify/2285 <pre>Hi folks, Below is the announcement for a new draft that was just posted. This draft, which stems from work done at the Calendaring and Scheduling Consortium, attempts to address the need for iCalendar data to support non-Gregorian recurrence behavior. Rather than making use of the existing "CALSCALE" option in iCalendar (which was considered too disruptive), it instead defines extensions to the "RRULE" property. Please review and discuss on the ietf-calsify list, thanks. ------------ Forwarded Message ----------- Date: April 26, 2013 at 7:12:37 AM -0700 From: internet-drafts&lt; at &gt;ietf.org To: Cyrus Daboo &lt;cyrus&lt; at &gt;daboo.name&gt;, Gregory Yakushev &lt;yakushev&lt; at &gt;google.com&gt; Subject: New Version Notification for draft-daboo-icalendar-rscale-00.txt A new version of I-D, draft-daboo-icalendar-rscale-00.txt has been successfully submitted by Cyrus Daboo and posted to the IETF repository. Filename: draft-daboo-icalendar-rscale Revision: 00 Title: Non-Gregorian Recurrence Rules in iCalendar Creation date: 2013-04-26</pre> Cyrus Daboo 2013-04-26T14:17:00 http://permalink.gmane.org/gmane.ietf.calsify/2284 <pre>Hey Folks, as a basis for discussion for the WG I have put together an etherpad with a summary of iCalendar and vCard specs. It contains examples on how the jCard/jCal looks like. Note for those items that have different proposals, I have included all options. It may be that for some items there has been previous discussion that would rule out the one or other. https://calendar.etherpad.mozilla.org/jcardcal-model I'm looking forward to your comments. If you decide to write something on the etherpad, please fill in your name. For those of you on the calsify/vcarddav lists, this will likely be my last post aside from new version notifications. If you would like to continue to discuss these emerging standards, please subscribe to the jcardcal mailing list. Thanks, Philipp </pre> Philipp Kewisch 2013-03-20T11:29:04 http://permalink.gmane.org/gmane.ietf.calsify/2283 <pre>Hello, As mentioned in the attached email, during discussions on the new vCard resource draft we realized the need to re-use and sometimes enhance the currently defined KIND values to define schedulable resources. This lead to the idea of replicating the concept of Objectclass that LDAP offers. After further discussions the following drafts have been submitted. Any review and comments would be greatly appreciated. - Base vCard objectclass property definition - http://tools.ietf.org/html/draft-vcard-objectclass-00 - Definition of the "schedulable" objectclass value used to define any schedulable entity - http://tools.ietf.org/html/draft-vcard-schedulable-00 - Modified vCard representation of a schedulable resource that makes use of the schedulable objectclass - http://tools.ietf.org/html/draft-cal-resource-vcard-02 Thanks, Ciny _______________________________________________ calsify mailing list calsify&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/calsify </pre> Ciny Joy 2013-02-27T23:54:09 http://permalink.gmane.org/gmane.ietf.calsify/2277 <pre>Hi Tim, --On February 13, 2013 at 11:49:19 PM -0500 Tim Hare &lt;TimHare&lt; at &gt;comcast.net&gt; wrote: To actually address your question: the initial goal of VPOLL is to address a simple "polling" model where an "organizer" sends out a set of possible meetings (varying in one or more attributes like time, location, title, etc), and "voters" get to indicate their preference (on a scale of 0 - 100), and then the "organizer" picks the "winning" meeting and uses regular iTIP behavior to book it. The hairdresser problem is obviously something we also care about and can be done using VPOLL to - with one option being what I refer to as "reverse polling". Here is how that would work: 1. Long haired dude decides they need a haircut so they send their available time in the form of a VAVAILABILITY or VFREEBUSY component to the hairdressers "booking" system. 2. Booking system takes that availability and intersects with the open booking slots and generates a VPOLL for those which then get sent to the long haired dud</pre> Cyrus Daboo 2013-02-15T16:06:07 http://permalink.gmane.org/gmane.ietf.calsify/2275 <pre>Hi Tim, --On February 13, 2013 at 11:49:19 PM -0500 Tim Hare &lt;TimHare&lt; at &gt;comcast.net&gt; wrote: As you may have noticed we did recently post a draft on VPOLL, so calsify seems like an appropriate place to discuss the draft: &lt;https://datatracker.ietf.org/doc/draft-york-vpoll/&gt;. </pre> Cyrus Daboo 2013-02-14T14:53:23 http://permalink.gmane.org/gmane.ietf.calsify/2274 <pre> Is there an informal (or formal) mailing list for work on VPOLL? Are such discussions on Calsify or Caldeveloper? My specific question (right now): is one VPOLL use case the proverbial one of scheduling a haircut? Thanks Tim Hare Interested Bystander, Non-Inc. </pre> Tim Hare 2013-02-14T04:49:19 http://permalink.gmane.org/gmane.ietf.calsify/2271 <pre>Hello apps-discuss, as you might know, the calconnect group has been working on a draft for a JSON based data format for iCalendar, which you can find here [1]. This draft comes with a fully functional javascript parser/converter that you can find at [2]. The library can also process recurrence data and timezone conversion and is being used in the latest version of Firefox OS and is also targeted at the Lightning extension to Thunderbird. The data format we chose has gone through various iterations. Although it may not be the common object-as-root type JSON, I think its suited best for its task: bidirectional, semantically lossless conversion between iCalendar and JSON. It has been discussed on the vcarddav and calsify lists. Consequently, I have created a draft for vCard in JSON using a similar notation [3]. There are of course some slight differences between vCard and iCalendar causing some open issues ready for discussion in a WG. You can find them at the end of the draft, any input is appr</pre> Philipp Kewisch 2013-02-13T20:52:04 http://permalink.gmane.org/gmane.ietf.calsify/2267 <pre>This is going to be Pete's working group, but let me add one thing to what Cyrus said about the aggressive schedule and the "fast track": A while ago, we chartered the imapmove working group on a very fast chartering schedule, and we're looking to do even more here. The idea that "it takes too long to create a working group" is something we need to dispel. In this case, we have an opportunity, with two back-to-back IESG telechats a week apart, so we are looking for *this Friday* (15 Feb) to put this on the telechat agenda for next week (21 Feb), and to have it get final approval on the 28th. That's three weeks from charter proposal to approval. That means that we need to hear any *major* objections to this now -- please have a look at this quickly and call out anything we've really goofed on before Friday. We then have until next Thursday (21st) to get the details of the charter in shape for broad review. Barry, Applications AD On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo &lt;cyrus&lt; at &gt;daboo.name&gt; wrote: </pre> Barry Leiba 2013-02-13T00:02:52 http://permalink.gmane.org/gmane.ietf.calsify/2263 <pre> I started out with a response to each of your points, but then it occurred to me that the problem isn't in the naming ("vtimezone" vs "vtimezones"), or representing values as arrays or strings: the problem, as I see it, is that the JSON draft appears to be an attempt to convert the iCalendar format into JSON, rather than creating a JSON representation of the iCalendar data model. Scotty </pre> Scotty Logan 2013-01-29T21:35:27 http://permalink.gmane.org/gmane.ietf.calsify/2261 <pre>Hi Scotty, I understand that the JSON you see here is slightly different than what you often see (root being an object), but the data we have to handle here is slightly different too. What we have here is definitly ON, as in Javascript, Arrays are also Objects and Arrays are also part of the JSON spec. The JSON you provide looks very much like what I started with when I was working on my library to parse iCalendar data, but as we progressed with the spec, more and more flaws came up. Remember we are designing a data format, not a library to process it. Let me show you some examples of what is not working: What rule would this go by? Use the component name and add 's' ? What happens if there are multiple daylight components? Even if thats not possible in this case, it could for other components so there would have to be lots of per-component exceptions which is neither consistent nor future proof. So dates can have two different formats? What to use when? What if there is a parameter named TYP</pre> Philipp Kewisch 2013-01-26T08:43:10 http://permalink.gmane.org/gmane.ietf.calsify/2259 <pre>Hi Simon, --On January 18, 2013 3:47:43 PM +0100 Simon Perreault &lt;simon.perreault&lt; at &gt;viagenie.ca&gt; wrote: That would be one way to encourage more adoption of version 4, which would be a good thing IMHO. </pre> Cyrus Daboo 2013-01-18T14:51:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.calsify