Subject: [calsify] iCalendar and vCard in JSON: WG draft charter

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 Feb 2013 17:11:15 -0500

Hi folks,
At the prompting of the Weirds WG there is a need to move more quickly on 
developing specifications for JSON-based data formats for iCalendar and 
vCard data, without necessarily waiting on other (proposed) JSON working 
group work to proceed.

A proposed charter for a "fast-track" Working Group is posted at 
<http://trac.tools.ietf.org/wg/appsawg/trac/wiki/jcardcal> for feedback. 
The charter defines aggressive milestones and attempts to limit the 
objectives such that those are achievable. Please review and post comments 
back to the apps-discuss list.

Whilst initial focus will be on the draft charter, some drafts have already 
been published describing possible (different) approaches. One for 
iCalendar: 
<https://datatracker.ietf.org/doc/draft-kewisch-et-al-icalendar-in-json/>, 
and one for vCard: 
<http://tools.ietf.org/id/draft-bhat-vcarddav-json-00.txt>. We also hope to 
have an alternative jCard draft published in the next day or two that uses 
the same approach as draft-kewisch-et-al-icalendar-in-json. These should 
provide a good basis for initial input into the working group.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Feb 2013 19:02:52 -0500

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 <[email-masked]> wrote:
> <http://trac.tools.ietf.org/wg/appsawg/trac/wiki/jcardcal> for feedback. The
> charter defines aggressive milestones and attempts to limit the objectives
> such that those are achievable. Please review and post comments back to the
> apps-discuss list.
>

---

From: Philipp Kewisch <[email-masked]>
Date: Wed, 13 Feb 2013 22:18:58 +0100

Hi Markus,

while I agree that re-using formats is often a good idea, I'm with Paul 
in this case. The amount of data in a vcard object is not that high, so 
adding the overhead of JSON-LD doesn't bring much advantage to my mind. 
Also, property parameters and structured values make the key-value based 
approach quickly come to its limits.

For vCard, the amount of processing needed is fairly low. Accessing 
object members is most of the deal. This does warrant considering 
JSON-LD since as I've read, the goal is a lightweight data format. If 
the amount of processing is considerably higher (as for iCalendar in 
JSON, for example: timezones, recurrence expansion, ...) a dedicated 
library for processing is needed.

To my mind I think the format for vCard in JSON and iCalendar in JSON 
should be similar, since the format for vCard and iCalendar is also 
similar. Given there is a need for a dedicated library for iCalendar in 
JSON anyway, I wouldn't go with JSON-LD.

This is of course just my personal opinion, I don't object putting 
JSON-LD on the table for discussion in the WG.

Philipp

On 2/13/13 8:21 PM, Paul E. Jones wrote:
> Markus,
>
> While my opinion is just one, I personally don't see the point of adding
> JSON-LD to the mix.  Use of JSON-LD just means there is another 50+ page
> specification to go read and more work to ensure data is properly formatted.
>
> Whether JSON-LD is used or not, the jCard spec would have to describe the
> name/value pairs, arrays, or objects inside the JSON object specific to the
> jCard.  Just using JSON the same example might be:
>
>   {
>     "FN": "John Doe",
>     "ROLE": "Mr. Anonymous"
>   }
>
> The common underlying syntax is JSON and that's what all devices can parse.
> JSON-LD seems like an unnecessary layer to me.
>
> Paul
>
>> -----Original Message-----
>> From: [email-masked] [mailto:apps-discuss-
>> [email-masked]] On Behalf Of Markus Lanthaler
>> Sent: Wednesday, February 13, 2013 5:06 AM
>> To: 'Barry Leiba'; 'Cyrus Daboo'
>> Cc: 'IETF Apps Discuss'; [email-masked]; 'CardDAV'
>> Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft
>> charter
>>
>> Even though I don't have any *major* objections I still wanted to raise
>> some concerns about the consequences of such highly specialized formats,
>> all similar but nevertheless not truly interoperable/compatible. As a
>> developer you basically have to write specific code for each of those
>> formats.
>>
>> I was wondering if it was ever considered to use, e.g., something like
>> JSON-LD [1] as the base for formats like these and limit the
>> standardization to a shared vocabulary (i.e., URLs for the required
>> properties) and a set of constraints and conventions captured in a
>> profile (see [2] for details).
>>
>> The advantage would be that much more code could be reused and data-
>> integration would become much simpler. It might look complicated at
>> first sight, but in reality most of what's needed is already there. For
>> example, the work to define URLs for the various properties for both
>> iCalendar [3] and vCard [4] has already been done at W3C (not as a REC
>> though).
>>
>> So, a simple vCard represented in JSON-LD would look as follows:
>>
>> {
>>    "@context": {
>>      "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#"
>>    },
>>    "FN": "John Doe",
>>    "ROLE": "Mr. Anonymous"
>> }
>>
>> You would have to define a number of constraints in the form of a
>> profile if you also want clients that process this as JSON instead of
>> JSON-LD to be able to interpret the data. The reason is that in JSON-LD
>> you can serialize the exactly the same data in a number of different
>> ways (e.g., you could use different field names that still expand to the
>> same URLs; the context defines those mappings). JSON-only clients are
>> less flexible and thus need to know the exact structure and field names.
>>
>> The question I thus would like to ask is: Is there a compelling reason
>> why this can't be based on a format as JSON-LD? Taking out the potential
>> complexity by requiring a profile defining a number of constraints on
>> how the data is serialized, I only see advantages of doing so.
>>
>>
>> Cheers,
>> Markus
>>
>>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 21 Feb 2013 11:59:54 -0500

Hi Pete,

--On February 21, 2013 at 9:51:12 AM -0600 Pete Resnick 
<[email-masked]> wrote:

> OLD
>      Requirements from other working groups looking to adopt the jCard or
>      jCal data formats will be considered. Requirements that are not
>      explicitly mentioned in this charter will be considered so long as
>      they do not conflict with the other stated objectives. Specific
>      requirements for consideration are:
>
> NEW
>      Syntactic requirements from other working groups looking to adopt
>      the jCard or jCal data formats will be considered. However, changes
>      to the semantics of vCard and iCalendar are out of scope.
>      Requirements that are not explicitly mentioned in this charter will
>      be considered so long as they do not conflict with the other stated
>      objectives. Specific requirements for consideration are:
>
> Any objections?

No.

-- 
Cyrus Daboo