From kewisch@gmail.com Tue Jan 15 00:53:51 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6367621F87F3 for ; Tue, 15 Jan 2013 00:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKfZOMjQaJxv for ; Tue, 15 Jan 2013 00:53:50 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0810221F87ED for ; Tue, 15 Jan 2013 00:53:49 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id gg13so3623918lbb.34 for ; Tue, 15 Jan 2013 00:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type; bh=J7N53CgpXlO/WHrsqgIVzwFCpqsAJ19skFuSTBXtpfk=; b=pAuB8Wx3gUmKLOvqnNQoEYqVMr9t7ci8LIQRtDri8FHLt38sPDLqbd2/O2PtzAmTwf RCnR8NX1EdajB1+EXS5CVzLsGFX/kGk0nC6xQAHqpRbdgkDCAMxjLOmMq3SK0MYbBB5L wRFCJv/TCEdVQshFOMqGZXSxZCWteAVttftxc5KW0xlfX+orUu5iB5M4MwTemg0nvF7u s9znIXR51hANV8U2yW6YAL4oHbDWKWCSPg6uCnfXwZMdsUMHIMY22lnA+bu8KHWFPXXh IhMekoqycwZxHO8lJlJO9JPaf2Dda7QJhDX6CSRLLpRESZgSxuxFwEGm+qTpZRV0QqbL dq4g== X-Received: by 10.112.40.129 with SMTP id x1mr36852772lbk.95.1358240028681; Tue, 15 Jan 2013 00:53:48 -0800 (PST) Received: from cwlcl-35.fh-wedel.de (kewis.ch. [178.17.162.74]) by mx.google.com with ESMTPS id b3sm6385886lbl.0.2013.01.15.00.53.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 00:53:48 -0800 (PST) Message-ID: <50F5191D.5060806@gmail.com> Date: Tue, 15 Jan 2013 09:53:49 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: calsify@ietf.org References: <50F5124F.8070609@gmail.com> In-Reply-To: <50F5124F.8070609@gmail.com> X-Forwarded-Message-Id: <50F5124F.8070609@gmail.com> Content-Type: multipart/alternative; boundary="------------020709030902040800000207" Subject: [calsify] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:53:51 -0000 This is a multi-part message in MIME format. --------------020709030902040800000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Folks, Based on discussion we have had within the calconnect group, I have just posted a new version of draft-kewisch-et-al-icalendar-in-json with the following changes. You can find the draft here . * Added information on how to handle multi-value parameter. The decision leads to a cleaner draft for a similar proposal for vcard. * Removed the open discussion point section regarding the mime media type in favor of adding one. I would appreciate your feedback on the draft in order to advance on this topic. Also, especially or the vcarddav folks, please also take a look at my previous email to get a comparison between the vcarddav-json draft and the format we propose for iCalendar. I would like to push forward with this and come to a consensus so we can provide a compatible draft for vcards. I am also happy to announce that Mozilla is already testing this draft in the field with the Firefox OS calendaring application. To do so, we are using the ical.js library I have been working on, see . Regards, Philipp --------------020709030902040800000207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Folks,

Based on discussion we have had within the calconnect group, I have just posted a new version of draft-kewisch-et-al-icalendar-in-json with the following changes. You can find the draft here <http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt>.

      *  Added information on how to handle multi-value parameter.  The
         decision leads to a cleaner draft for a similar proposal for
         vcard.

      *  Removed the open discussion point section regarding the mime
         media type in favor of adding one.
I would appreciate your feedback on the draft in order to advance on this topic.

Also, especially or the vcarddav folks, please also take a look at my previous email <http://www.ietf.org/mail-archive/web/vcarddav/current/msg02678.html> to get a comparison between the vcarddav-json draft and the format we propose for iCalendar. I would like to push forward with this and come to a consensus so we can provide a compatible draft for vcards.

I am also happy to announce that Mozilla is already testing this draft in the field with the Firefox OS calendaring application. To do so, we are using the ical.js library I have been working on, see <https://github.com/kewisch/ical.js/>.

Regards,
Philipp


--------------020709030902040800000207-- From swl@stanford.edu Tue Jan 15 11:06:15 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3121F84E3 for ; Tue, 15 Jan 2013 11:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEvyQpzUqWT0 for ; Tue, 15 Jan 2013 11:06:14 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4EF21F84CE for ; Tue, 15 Jan 2013 11:06:14 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 34D966440EB for ; Tue, 15 Jan 2013 11:06:13 -0800 (PST) Received: from mail-pa0-f72.google.com (mail-pa0-f72.google.com [209.85.220.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id CBA45644310 for ; Tue, 15 Jan 2013 11:06:12 -0800 (PST) Received: by mail-pa0-f72.google.com with SMTP id fb10so648931pad.3 for ; Tue, 15 Jan 2013 11:06:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=FYwch48TMRYNZlns4XflYGO9vZSN1PgCqw4pAgSBfYg=; b=G51Ldyt+Uv8GsO03kmdpRRND84J09ONGFFDOwMTb/cnLkjBv72hDGawio2vXRR+4SP W6AYsTTL7lHogPr12AAXlwETLCXgJHzqklkeUv3H1lMSUXs9yfGKDhHkgyaw45qo3mtX QZZUihkd8T4mBKePztg/7zoXzRDBv+Z1N7MynjVOu6Y8X8ZId2OfOSNk4w2W65ZFDoMP Uy2Iv9A3fjq7/0d8Y5MlLUJ2kijnjwBOQde7iGUAjbkmhCblbWQJISvVQ5xSOukAhut1 ZGlbOzQ5mYEUZRHSjJEx5hBUYvvXaqZancQ0slZSJ6YAkwdAajq37WTAkTTm6w3/Jahm C34Q== X-Received: by 10.68.220.161 with SMTP id px1mr117272774pbc.167.1358276772516; Tue, 15 Jan 2013 11:06:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.220.161 with SMTP id px1mr117272761pbc.167.1358276772419; Tue, 15 Jan 2013 11:06:12 -0800 (PST) Received: by 10.68.11.37 with HTTP; Tue, 15 Jan 2013 11:06:12 -0800 (PST) In-Reply-To: <50F5191D.5060806@gmail.com> References: <50F5124F.8070609@gmail.com> <50F5191D.5060806@gmail.com> Date: Tue, 15 Jan 2013 11:06:12 -0800 Message-ID: From: Scotty Logan To: Philipp Kewisch Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnEHyQWdM9OlNkF18ipIlfg4JHPdpvCxp+aJvgdMsPN+50Y4Sjn/dAZy5JciwUJugbHM06f7RqF1R8BuLqPVBf9UjrgkqWAl1QaA1v7FombMRia4CK1KY0+sHW8jFxBBilnZw4wORhRRf40Dqpt27Mvv/+6sw== Cc: calsify@ietf.org Subject: Re: [calsify] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:06:15 -0000 I've been lurking on this list, but this caught my eye since I've been working with a lot of JSON recently. I think that's the most un-JSON-like JSON I've ever seen. If you're going to use JSON, please use the ON part, and use objects to represent non-array data. The example in B.2.2. would be easier to work with if it was more JSON-ish: { "prodid": "-//Example Corp.//Example Client//EN"], "version": "2.0", "vtimezones": [ { "tzid": "US/Eastern", "last-modified": "2004-01-10T03:28:45Z", "daylight": { "tzname": "EDT", "tzoffsetfrom": "-05:00", "tzoffsetto": "-04:00", "dtstart": "2000-04-04T02:00:00", "rrule": { "freq": "yearly", "byday": "1su", "bymonth": 4 }, }, "standard": { "tzname": "EST", "tzoffsetfrom": "-04:00", "tzoffsetto": "-05:00", "dtstart": "2000-10-26T02:00:00", "rrule": { "freq": "yearly", "byday": "1su", "bymonth": 10 } } } ], "vevents": [ { "dtstamp": "2006-02-06T00:11:21Z", "dtstart": { "tzid": "US/Eastern", "type": "date-time", "value": "2006-01-02T12:00:00" }, "duration": "PT1H", "rrule": { "freq": "daily", "count": 5 } "rdate": { "tzid": "US/Eastern", "type": "period", "value": "2006-01-02T15:00:00/PT2H" }, "summary": "Event #2", "description": "We are having ... 12 pm meetings.", "uid": "00959BC664CA650E933C892C@example.com" }, { "dtstamp": "2006-02-06T00:11:21Z", "dtstart": { "tzid": "US/Eastern", "type": "date-time", "value": "2006-01-02T14:00:00" }, "duration": "PT1H", "recurrence-id": { "tzid": "US/Eastern", "type": "date-time", "value": "2006-01-04T12:00:00" }, "summary": "Event #2 bis", "uid": "00959BC664CA650E933C892C@example.com" } ] } Now the data can be processed with code like: var jcal =3D getJCalData(=85); jcal.vevents.forEach(function (vevent) { var dtstart =3D null; if (typeof vevent.dtstart =3D=3D=3D 'string') { dtstart =3D new Date(vevent.dtstart); } else { if (vevent.dtstart.tzid) { =85 } =85 } ... } Scotty On Tue, Jan 15, 2013 at 12:53 AM, Philipp Kewisch wrote= : > Hello Folks, > > Based on discussion we have had within the calconnect group, I have just > posted a new version of draft-kewisch-et-al-icalendar-in-json with the > following changes. You can find the draft here > . > > * Added information on how to handle multi-value parameter. The > decision leads to a cleaner draft for a similar proposal for > vcard. > > * Removed the open discussion point section regarding the mime > media type in favor of adding one. > > I would appreciate your feedback on the draft in order to advance on this > topic. > > Also, especially or the vcarddav folks, please also take a look at my > previous email > to = get > a comparison between the vcarddav-json draft and the format we propose fo= r > iCalendar. I would like to push forward with this and come to a consensus= so > we can provide a compatible draft for vcards. > > I am also happy to announce that Mozilla is already testing this draft in > the field with the Firefox OS calendaring application. To do so, we are > using the ical.js library I have been working on, see > . > > Regards, > Philipp > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > From cyrus@daboo.name Fri Jan 18 06:51:52 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DDC21F8888; Fri, 18 Jan 2013 06:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta8xAqVxdxTh; Fri, 18 Jan 2013 06:51:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DFCD721F8865; Fri, 18 Jan 2013 06:51:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8774E3B3B4DB; Fri, 18 Jan 2013 09:51:51 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yv1UvJc_9fh; Fri, 18 Jan 2013 09:51:50 -0500 (EST) Received: from [17.45.162.221] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id CB5833B3B440; Fri, 18 Jan 2013 09:51:48 -0500 (EST) Date: Fri, 18 Jan 2013 09:51:51 -0500 From: Cyrus Daboo To: Simon Perreault , Michael Angstadt Message-ID: <8E5D2A65B43C8BA442589924@cyrus.local> In-Reply-To: <50F9608F.4020902@viagenie.ca> References: <50F5124F.8070609@gmail.com> <50F95952.4040209@viagenie.ca> <50F9608F.4020902@viagenie.ca> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=405 Cc: Calsify , vcarddav@ietf.org Subject: Re: [calsify] [VCARDDAV] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:51:52 -0000 Hi Simon, --On January 18, 2013 3:47:43 PM +0100 Simon Perreault wrote: >> According to the specs, jCard supports 2.1 and 3.0, not just version 4. > > This is wrong, it should only support version 4. Doing otherwise would be > asking for a lot of trouble. That would be one way to encourage more adoption of version 4, which would be a good thing IMHO. -- Cyrus Daboo From kewisch@gmail.com Sat Jan 26 00:43:13 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5A21F8477; Sat, 26 Jan 2013 00:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjeKqfFCFBOP; Sat, 26 Jan 2013 00:43:12 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id E384E21F8B02; Sat, 26 Jan 2013 00:43:11 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so556027eek.40 for ; Sat, 26 Jan 2013 00:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=Zu51d52bmrinomnXFzisP0pXMKPXFow9XSDlf0bO3jY=; b=MydyCZaDstEfsPbcVovYjqIFaZXQTZ2bpQtFSO9SopXAclJrUZvqv+ktdjFsRDYBXQ 21Hf2vea1HkxmFip0X9rsPqTvSr9whSglm8SkZJ91QoYS+eARXWakYjKL/7XHG/H7kg0 0ykZEYmIAtgF6OUQPdplDZMI6rtOM0sKgVzR/0RyaiiJweqkqTNQpGTVQBtHQW6bDCOD 3MfMlVYALZFGD1N1w1YFQ7ibAUQkWp89A83wsaRL92LdGF2tepalRb8uvuIsCnBkEQcb PdxXFQoH513RJymXcFDIxr4xD9yrhQq0i0GEhNXxnQP93V9l0qQllngyjWPwLCteZIa8 h+PA== X-Received: by 10.14.174.73 with SMTP id w49mr27741895eel.17.1359189791005; Sat, 26 Jan 2013 00:43:11 -0800 (PST) Received: from oskar.fritz.box (g231130092.adsl.alicedsl.de. [92.231.130.92]) by mx.google.com with ESMTPS id 6sm5324827eea.3.2013.01.26.00.43.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 00:43:10 -0800 (PST) Message-ID: <5103971E.4050507@gmail.com> Date: Sat, 26 Jan 2013 09:43:10 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: vcarddav@ietf.org, calsify@ietf.org References: <50F5124F.8070609@gmail.com> <50F5191D.5060806@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040004080206060601080905" Subject: Re: [calsify] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 08:43:13 -0000 This is a multi-part message in MIME format. --------------040004080206060601080905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: > > { > "prodid": "-//Example Corp.//Example Client//EN"], > "version": "2.0", > "vtimezones": [ What rule would this go by? Use the component name and add 's' ? > { > "tzid": "US/Eastern", > "last-modified": "2004-01-10T03:28:45Z", > "daylight": { 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. > "dtstamp": "2006-02-06T00:11:21Z", > "dtstart": { > "tzid": "US/Eastern", > "type": "date-time", > "value": "2006-01-02T12:00:00" > }, So dates can have two different formats? What to use when? What if there is a parameter named TYPE ? > "summary": "Event #2", > "description": "We are having ... 12 pm meetings.", > "uid": "00959BC664CA650E933C892C@example.com" What happens with properties that can occur multiple times or have multiple values (like CATEGORIES)? My next idea back then was to turn it into an array, i.e "category": ["abc", "def"], but then you run into consistency/performance issues again. Add an array for everything, i.e "summary": ["Event #2"] or do type checking each time? > > > Now the data can be processed with code like: > > var jcal = getJCalData(…); > > jcal.vevents.forEach(function (vevent) { While I understand it would be nice to process jCal without a library (and you can, even with our draft), in many cases you will just end up duplicating code that a js library will provide to you. The easier we make this, the more likely it is that people will produce wrong jCal, because their code evolves from something simple. I hope this give you a better feeling with the format we propose, let me know what you think! Philipp --------------040004080206060601080905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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:


{
    "prodid": "-//Example Corp.//Example Client//EN"],
    "version": "2.0",
    "vtimezones": [
What rule would this go by? Use the component name and add 's' ?
        {
            "tzid": "US/Eastern",
            "last-modified": "2004-01-10T03:28:45Z",
            "daylight": {
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.

            "dtstamp": "2006-02-06T00:11:21Z",
            "dtstart": {
                "tzid": "US/Eastern",
                "type": "date-time",
                "value": "2006-01-02T12:00:00"
            },
So dates can have two different formats? What to use when? What if there is a parameter named TYPE ?

            "summary": "Event #2",
            "description": "We are having ... 12 pm meetings.",
            "uid": "00959BC664CA650E933C892C@example.com"
What happens with properties that can occur multiple times or have multiple values (like CATEGORIES)?

My next idea back then was to turn it into an array, i.e "category": ["abc", "def"], but then you run into consistency/performance issues again. Add an array for everything, i.e "summary": ["Event #2"] or do type checking each time?
     

Now the data can be processed with code like:

    var jcal = getJCalData(…);

    jcal.vevents.forEach(function (vevent) {
While I understand it would be nice to process jCal without a library (and you can, even with our draft), in many cases you will just end up duplicating code that a js library will provide to you. The easier we make this, the more likely it is that people will produce wrong jCal, because their code evolves from something simple.

I hope this give you a better feeling with the format we propose, let me know what you think!
Philipp





--------------040004080206060601080905-- From kewisch@gmail.com Sat Jan 26 00:43:51 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D021F8750; Sat, 26 Jan 2013 00:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3oGX+Ls7yAW; Sat, 26 Jan 2013 00:43:50 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAB21F86BB; Sat, 26 Jan 2013 00:43:50 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so480889eaa.23 for ; Sat, 26 Jan 2013 00:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=2LdclLWZLuYG3yu7iFGZ6lmuI3S3N6qeoX/XNOkFuIs=; b=k9H+KkkDXEnPFsGFOOz9+YuzOHlt3y2V3pYPV+yS4urFylzT1WqJvGdXCeiILYFguM /gx2aXVHPv/V5UfWw2XT7wg1Wk8kbKPsfkk67/B7TIFmTGT+59dtMMi96GK/Lv6I6SMc O+/GVtmUotsBQyc5bl3+Apd6o5DnX9tdTZ4k67d2ohSMVF1447lMm0LRHIHcIjh72z1W Wmmj9vmJc8OymSAipqkMbKK8y+BiEGNPPt0U8G3F3sOnnP8GgDCYvnKsrcUwPTGbTP5+ L6H9TmVfjqnIiqnrYb+xFOHW9vYiou5cmITTUH7RG8vhclUpfa7MRjPkCWmvCPqo6303 nNOg== X-Received: by 10.14.219.72 with SMTP id l48mr27573032eep.37.1359189829385; Sat, 26 Jan 2013 00:43:49 -0800 (PST) Received: from oskar.fritz.box (g231130092.adsl.alicedsl.de. [92.231.130.92]) by mx.google.com with ESMTPS id g2sm5301724eep.16.2013.01.26.00.43.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 00:43:48 -0800 (PST) Message-ID: <51039746.90402@gmail.com> Date: Sat, 26 Jan 2013 09:43:50 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: calsify@ietf.org, vcarddav@ietf.org References: <50F5124F.8070609@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090205090907030303090905" Cc: Michael Angstadt Subject: Re: [calsify] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 08:43:52 -0000 This is a multi-part message in MIME format. --------------090205090907030303090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit TL;DR; version at the end of this email. On 1/16/13 2:24 AM, Michael Angstadt wrote: > (1) Grouping > > A simple solution would be to prepend the group to the property name, > separating it from the property name with some special character, just > like in vCard. For example: > > ["group.email", {}, "text", "johndoe@hotmail.com"] > > (a) Greater compatibility with jCal. > (b) Grouping is a fairly infrequently-used feature. Changing the > syntax would add extra complexity which won't be used in most > situations. I agree, I had thought about grouping, but I preferred a similar syntax so a library that could parse jCal could also parse jCard. For a simple solution, I'd go with just using the whole thing as a property name like you posted: ["group.email", {}, "text", "johndoe@example.com"] Another option that would allow same property names as group names is to add a special type "group" in the jCard spec. ["groupname", {}, "group", [ ["email", {}, "text", "johndoe@example.com"] ] ] Which would serialize to: groupname.EMAIL:johndoe@example.com This would differ from a property named groupname: ["groupname", {}, "text", "foo"] and due to the fact that properties are in an array and not in an object, there is no problem keeping both. The downside for this alternative is that there is an extra set of parameters that does not serialize back to iCalendar/vCard. This would "look" correct but be invalid: ["groupname", { "x-bogus": "param" }, "group", [ ["email", { "x-ok": "param" }, "text", "johndoe@example.com"] ] ] And still serialize to the following, dropping x-bogus. groupname.EMAIL;X-OK=param:johndoe@example.com > (3) JSON objects for property values > > On the flip-side, I think one nice feature about vcarddav-json is that > property values are encoded as JSON objects. This is great for > multi-valued properties like ADR and N because each value can be > indexed by a human-readable name. jCal, however, requires that the > values be appended onto the end of the property array, which means > that they must be retrieved by index. It also means that a > placeholder element (like a "null" value) must be included for any > missing components of the property value in order to preserve the > array indexing. The ADR property is a good example: We've discussed this in the last TC-XML-JSON call, related to a different issue. I think this is something we could find a consensus on and put it into the jCal spec. On the one hand I would like to avoid making property values too diverse and just stay with not splitting the text at all: ["adr", {"type":"work"}, "text", ";2875 boul. Laurier, suite D2-630;Quebec;QC;G1V 2M2;CA"] This would leave the parsing to a library. For jCal this would be sufficient, since the allowed text in an RRULE property value is limited, so its just a matter of val.split(";").forEach(function(part) { let k,v = part.split("="); map[k] = v }); if the library needs to access the parts in a map. Reasons that speak for against using objects (or even arrays) for structured values: * Slight performance loss, which might add up, due to: ** Need for either special-casing of type per property or, to be safe, for every property. ** Additional Objects per property, which might not be needed every time. * Breaks consistency. Which properties are allowed to have objects? * What about unknown properties added via extension? What would this parse to: X-MYTHING:LoOKS=;LIKE=;A=;STrUCTURED=;VAlUE= ** ["x-mything", {}, "text", { "looks": "", "like":"", "a":"","structured":"","value":"" }] ** ["x-mything", {}, "text", "LoOKS=;LIKE=;A=;STrUCTURED=;VAlUE="] * If unknown objects should have a default, what separator to choose? * For jCal, this is only valid for RRULE, which you will need a library anyway to process gracefully (calculate occurrences) On the other hand, especially with vcard in mind, I can see this is useful. Specifically for jCal, we have discussed that it would be good to change GEO and REQUEST-STATUS a single-value property where the value is an array, i.e ["geo", {}, "float", [12.34, 56.78]]. In line with this, we could also allow using an object for RRULE since it has its own type. From your vCard example it seems to me that /any/ "text" value can be structured, so we would need to make using objects as property values something that is generally allowed for and warn parser implementers that they need to check the value type. To handle the issue with unknown properties, we could assert that if the parser does not know about the property that it should treat it as opaque text. So let me summarize whats left to decide: (1) Grouping: a) Leave "groupname.email" as the property name, or b) Add a pseudo-property with the special type "group" and make its value be an array of group members (2) Naming conflicts: We agree here that jCal's mechanism works better (3) Objects for structured property values a) Use an array, possibly with a null value for any structured property b) Use an object, avoids null values and makes access easier c) Do not parse value at all, leave it as an opaque text My personal preferences are 1a and either 3b or 3c. Philipp --------------090205090907030303090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
TL;DR; version at the end of this email.


On 1/16/13 2:24 AM, Michael Angstadt wrote:
(1) Grouping

A simple solution would be to prepend the group to the property name,
separating it from the property name with some special character, just
like in vCard.  For example:

["group.email", {}, "text", "johndoe@hotmail.com"]

(a) Greater compatibility with jCal.
(b) Grouping is a fairly infrequently-used feature.  Changing the
syntax would add extra complexity which won't be used in most
situations.
I agree, I had thought about grouping, but I preferred a similar syntax so a library that could parse jCal could also parse jCard. For a simple solution, I'd go with just using the whole thing as a property name like you posted:
["group.email", {}, "text", "johndoe@example.com"]

Another option that would allow same property names as group names is to add a special type "group" in the jCard spec.

["groupname", {}, "group", [
    ["email", {}, "text", "johndoe@example.com"]
  ]
]

Which would serialize to:

groupname.EMAIL:johndoe@example.com

This would differ from a property named groupname:

["groupname", {}, "text", "foo"]

and due to the fact that properties are in an array and not in an object, there is no problem keeping both. The downside for this alternative is that there is an extra set of parameters that does not serialize back to iCalendar/vCard. This would "look" correct but be invalid:

["groupname", { "x-bogus": "param" }, "group", [
    ["email", { "x-ok": "param" }, "text", "johndoe@example.com"]
  ]
]

And still serialize to the following, dropping x-bogus.

groupname.EMAIL;X-OK=param:johndoe@example.com


(3) JSON objects for property values

On the flip-side, I think one nice feature about vcarddav-json is that
property values are encoded as JSON objects.  This is great for
multi-valued properties like ADR and N because each value can be
indexed by a human-readable name.  jCal, however, requires that the
values be appended onto the end of the property array, which means
that they must be retrieved by index.  It also means that a
placeholder element (like a "null" value) must be included for any
missing components of the property value in order to preserve the
array indexing.  The ADR property is a good example:
We've discussed this in the last TC-XML-JSON call, related to a different issue. I think this is something we could find a consensus on and put it into the jCal spec. On the one hand I would like to avoid making property values too diverse and just stay with not splitting the text at all:

["adr", {"type":"work"}, "text", ";2875 boul. Laurier, suite D2-630;Quebec;QC;G1V 2M2;CA"]

This would leave the parsing to a library. For jCal this would be sufficient, since the allowed text in an RRULE property value is limited, so its just a matter of val.split(";").forEach(function(part) { let k,v = part.split("="); map[k] = v }); if the library needs to access the parts in a map. Reasons that speak for against using objects (or even arrays) for structured values:

* Slight performance loss, which might add up, due to:
   ** Need for either special-casing of type per property or, to be safe, for every property.
   ** Additional Objects per property, which might not be needed every time.
* Breaks consistency. Which properties are allowed to have objects?
* What about unknown properties added via extension? What would this parse to:  X-MYTHING:LoOKS=;LIKE=;A=;STrUCTURED=;VAlUE=
  ** ["x-mything", {}, "text", { "looks": "", "like":"", "a":"","structured":"","value":"" }]
  ** ["x-mything", {}, "text", "LoOKS=;LIKE=;A=;STrUCTURED=;VAlUE="]
* If unknown objects should have a default, what separator to choose?
* For jCal, this is only valid for RRULE, which you will need a library anyway to process gracefully (calculate occurrences)

On the other hand, especially with vcard in mind, I can see this is useful. Specifically for jCal, we have discussed that it would be good to change GEO and REQUEST-STATUS a single-value property where the value is an array, i.e ["geo", {}, "float", [12.34, 56.78]]. In line with this, we could also allow using an object for RRULE since it has its own type.

From your vCard example it seems to me that any "text" value can be structured, so we would need to make using objects as property values something that is generally allowed for and warn parser implementers that they need to check the value type. To handle the issue with unknown properties, we could assert that if the parser does not know about the property that it should treat it as opaque text.



So let me summarize whats left to decide:

(1) Grouping:
  a) Leave "groupname.email" as the property name, or
  b) Add a pseudo-property with the special type "group" and make its value be an array of group members

(2) Naming conflicts: We agree here that jCal's mechanism works better

(3) Objects for structured property values
  a) Use an array, possibly with a null value for any structured property
  b) Use an object, avoids null values and makes access easier
  c) Do not parse value at all, leave it as an opaque text

My personal preferences are 1a and either 3b or 3c.

Philipp

--------------090205090907030303090905-- From swl@stanford.edu Tue Jan 29 13:35:29 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B595421F888C for ; Tue, 29 Jan 2013 13:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVW8td4ztdVQ for ; Tue, 29 Jan 2013 13:35:29 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFD21F8868 for ; Tue, 29 Jan 2013 13:35:29 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A263629607 for ; Tue, 29 Jan 2013 13:35:28 -0800 (PST) Received: from mail-ia0-f199.google.com (mail-ia0-f199.google.com [209.85.210.199]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 500F562960A for ; Tue, 29 Jan 2013 13:35:28 -0800 (PST) Received: by mail-ia0-f199.google.com with SMTP id u20so3261941iag.2 for ; Tue, 29 Jan 2013 13:35:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Q9JZApGGQ/ZD93zOjoj4xiBq4msjS8SknV/5yMFHOgM=; b=VskQMJgahLOfYG3nAIsJAz0TS0HNNgq9Lb+kxc07JjR6fkr6Wx1BbqEsl4HfuUDlOv QEqjZ5bpIWsxTK5ep5K1poVWOLpF8MccHHyzmnv24fTCssWFHH5MsbRhb5fhiHKOhUY3 T7wwyg3ESQ8XtiYfV6gybaOJelXDkNUjq1JRPz8aj/y8oercUq5KIKsI6Lvb1CdY5VJG eX94foiJLv5qo4SoG8xRLyS1zrmNHIcsmJMXzmxiHUYwcRxoB/OPIyLfGVHQp1NWgkXm djj44ySPrehKRD2CnVaVlPH692we7RJkqtZ5m9G0oBD/P9DudYtlxzctaogIAsSvOPFK bFKg== X-Received: by 10.42.46.141 with SMTP id k13mr1598512icf.46.1359495327696; Tue, 29 Jan 2013 13:35:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.46.141 with SMTP id k13mr1598502icf.46.1359495327512; Tue, 29 Jan 2013 13:35:27 -0800 (PST) Received: by 10.42.227.200 with HTTP; Tue, 29 Jan 2013 13:35:27 -0800 (PST) In-Reply-To: <5103971E.4050507@gmail.com> References: <50F5124F.8070609@gmail.com> <50F5191D.5060806@gmail.com> <5103971E.4050507@gmail.com> Date: Tue, 29 Jan 2013 13:35:27 -0800 Message-ID: From: Scotty Logan To: Philipp Kewisch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlz9VZ3w5VODrMYXUXXz6m1TIItVhjy0zQm+EKnLr3kONNxkpn+cu6DAAr7j5JxamMDuoUNMmWSSq5PhwAEFRg4egf5TPZ1i3yBuqr2HF3cWYm+dw5JbrWGfX7PLr0ORk+y8qXC Cc: calsify@ietf.org, vcarddav@ietf.org Subject: Re: [calsify] New Version of the iCalendar in JSON (jCal) draft, feedback requested X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:35:29 -0000 On Sat, Jan 26, 2013 at 12:43 AM, Philipp Kewisch wrote: > I understand that the JSON you see here is slightly different than what you > often see (root being an object), 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