From cyrus@daboo.name Tue Feb 12 14:11:24 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 4E54021F8AB7; Tue, 12 Feb 2013 14:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx5Qzqu9Qbq4; Tue, 12 Feb 2013 14:11:23 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3D21F8AA6; Tue, 12 Feb 2013 14:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 04F433D44279; Tue, 12 Feb 2013 17:11:20 -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 bzfr350__rQ6; Tue, 12 Feb 2013 17:11:19 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 47E5E3D4426A; Tue, 12 Feb 2013 17:11:18 -0500 (EST) Date: Tue, 12 Feb 2013 17:11:15 -0500 From: Cyrus Daboo To: IETF Apps Discuss Message-ID: 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=1133 Cc: calsify@ietf.org, vcarddav@ietf.org Subject: [calsify] iCalendar and vCard in JSON: WG draft charter 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, 12 Feb 2013 22:11:24 -0000 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 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: , and one for vCard: . 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 barryleiba.mailing.lists@gmail.com Tue Feb 12 16:02:55 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 4DB0521F88FD; Tue, 12 Feb 2013 16:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNJ8IlDaErKM; Tue, 12 Feb 2013 16:02:54 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6AD21F88CF; Tue, 12 Feb 2013 16:02:53 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so628104vea.2 for ; Tue, 12 Feb 2013 16:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OJXwuYH7Bgl9b6520+uUo2NyWrF3PkPNMtscJjM+mLA=; b=g9GDDzBEZizcYMpshVjoOZROSk22HRSEh70Qd+g2Lt8dy6+rm6TMBESLSaGI2vGqla NKaih1rBFAyvicQKh0fapq2snQBOh9AaAL9hjT9gtak1rT/2/52219FhvgSRfbDrsJED 2X4589ZX5Ofrd6/kVNkFlCyrdoYAgLQaCUU3qAzRKRtwACP1Vtt9of+W3Z8mjhoQ9WO3 6vOcNc29PZTDqQ7vl09Mus6wNlmrws0KK0IVNaf2/4kRW/3HbuzBdZJrjL5gfjqQONtL +Z/9a6Pf4wHsTXYGAta8bid7pn7tykDgKGnqaobQv00CegtKi1sLDtYykwc/dSBprkzH 3MqA== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr26497199vec.22.1360713772535; Tue, 12 Feb 2013 16:02:52 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Tue, 12 Feb 2013 16:02:52 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 19:02:52 -0500 X-Google-Sender-Auth: Y7CviMKJb1SV_A7uA7pbszEu6TU Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Cc: CardDAV , calsify@ietf.org, IETF Apps Discuss Subject: Re: [calsify] [apps-discuss] iCalendar and vCard in JSON: WG draft charter 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: Wed, 13 Feb 2013 00:02:55 -0000 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 wrote: > 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 > 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: > , > and one for vCard: > . 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 kewisch@gmail.com Wed Feb 13 12:52:07 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 6189C21E8054; Wed, 13 Feb 2013 12:52:07 -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 ixe8wlGzbA58; Wed, 13 Feb 2013 12:52:06 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1E621E803D; Wed, 13 Feb 2013 12:52:05 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id ik5so757948bkc.10 for ; Wed, 13 Feb 2013 12:52:04 -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:x-forwarded-message-id:content-type; bh=Aa951Efl2pF1RHcVlQQQPPWxwhdtxz8z7KjSJo2uvk4=; b=zg2RtzsAk7gJpcLsCASTzhMij5/tJQnUQoZk0SIXD9U6zsLFQH0q3GKc8HrjrkGlUS XfK8SFKfx4t6GTJ5mVcLH0418NQG1jBoqBooAjq/HysEs2cyY6K3Wh0i3gFelm6h2T7y XXDo2srCVoed6w03TVRXLAOQuZkt5hn44xQFEEDczQeGUHfneN7XhA9BxPWVMyjtNcKE oNyuwcNSxoK4lU1GhteTTwZxo0OrVel438kPE74tzSttytp7hpOOA2Wtp5ThccvbJO8o 8Nhifh9D+1oenEDmptH6CXqS35Tyt9SfGJEmrcCs8Hh8blMD8iZBJzTnijQloZ/NKQQJ 3UUw== X-Received: by 10.204.157.150 with SMTP id b22mr7024088bkx.121.1360788724711; Wed, 13 Feb 2013 12:52:04 -0800 (PST) Received: from oskar.fritz.box (e177139085.adsl.alicedsl.de. [85.177.139.85]) by mx.google.com with ESMTPS id o9sm15986019bko.15.2013.02.13.12.52.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 12:52:04 -0800 (PST) Message-ID: <511BFCF4.6080606@gmail.com> Date: Wed, 13 Feb 2013 21:52:04 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> In-Reply-To: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090902060206030403080102" Cc: calsify@ietf.org, vcarddav@ietf.org Subject: [calsify] New Internet-Draft: jCard: The JSON format for vCard 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: Wed, 13 Feb 2013 20:52:07 -0000 This is a multi-part message in MIME format. --------------090902060206030403080102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 appreciated. For additional reading, check out some related discussion on the calsify [4] and vcarddav [5] lists. I have not yet adapted my ical.js parser to also read data as in this draft, but the changes are so minimal that it should not be a big deal. I'll be happy to take part in any WG calls or discussion related to moving vCard in JSON forward, so let me know what you think. Philipp [1] http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt [2] https://github.com/kewisch/ical.js/ [3] http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt [4] http://www.ietf.org/mail-archive/web/calsify/current/maillist.html [5] http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html -------- Original Message -------- Subject: New Version Notification for draft-kewisch-vcard-in-json-00.txt Date: Wed, 13 Feb 2013 12:03:24 -0800 From: internet-drafts@ietf.org To: mozilla@kewis.ch A new version of I-D, draft-kewisch-vcard-in-json-00.txt has been successfully submitted by Philipp Kewisch and posted to the IETF repository. Filename: draft-kewisch-vcard-in-json Revision: 00 Title: jCard: The JSON format for vCard Creation date: 2013-02-13 Group: Individual Submission Number of pages: 25 URL: http://www.ietf.org/internet-drafts/draft-kewisch-vcard-in-json-00.txt Status: http://datatracker.ietf.org/doc/draft-kewisch-vcard-in-json Htmlized: http://tools.ietf.org/html/draft-kewisch-vcard-in-json-00 Abstract: This specification defines "jCard", a JSON format for vCard data. The IETF Secretariat --------------090902060206030403080102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 appreciated. For additional reading, check out some related discussion on the calsify [4] and vcarddav [5] lists. I have not yet adapted my ical.js parser to also read data as in this draft, but the changes are so minimal that it should not be a big deal.

I'll be happy to take part in any WG calls or discussion related to moving vCard in JSON forward, so let me know what you think.

Philipp

[1] http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt
[2] https://github.com/kewisch/ical.js/
[3] http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt
[4] http://www.ietf.org/mail-archive/web/calsify/current/maillist.html
[5] http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html


-------- Original Message --------
Subject: New Version Notification for draft-kewisch-vcard-in-json-00.txt
Date: Wed, 13 Feb 2013 12:03:24 -0800
From: internet-drafts@ietf.org
To: mozilla@kewis.ch 


A new version of I-D, draft-kewisch-vcard-in-json-00.txt
has been successfully submitted by Philipp Kewisch and posted to the
IETF repository.

Filename:	 draft-kewisch-vcard-in-json
Revision:	 00
Title:		 jCard: The JSON format for vCard
Creation date:	 2013-02-13
Group:		 Individual Submission
Number of pages: 25
URL:             http://www.ietf.org/internet-drafts/draft-kewisch-vcard-in-json-00.txt
Status:          http://datatracker.ietf.org/doc/draft-kewisch-vcard-in-json
Htmlized:        http://tools.ietf.org/html/draft-kewisch-vcard-in-json-00


Abstract:
   This specification defines "jCard", a JSON format for vCard data.

                                                                                  


The IETF Secretariat


--------------090902060206030403080102-- From kewisch@gmail.com Wed Feb 13 13:19:05 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 C896C21F8891; Wed, 13 Feb 2013 13:19:05 -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 01hON03AYYE6; Wed, 13 Feb 2013 13:19:04 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB621F8890; Wed, 13 Feb 2013 13:19:03 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id jk7so768886bkc.1 for ; Wed, 13 Feb 2013 13:19:03 -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=5J6ZgONjpSLPGFMyvZxrRz/iH6FtpyqnG60PWH7f+To=; b=QtqOLraW+lL7JxfJ31oHv8zk8vHE+esTc8rUSdPenc7hNuSRvhiJDqrGDw/k8IVfbD K1NR+f+SJKXjD4vmcZy3wa2L7VO2YFHwwwntHMcGanJLjmwMpcSqH11CqtCXGwsbmnjM xVLGbQ5RxHjYQApHTwBuSMZCB6DdWnxKTFskJnx19DMuO7GwSiGa+2j2gLJ9ghTecRhE ubMTQ8D8O6hCv2KQXQHYcOEIFLAqZyi3lMCLRiZrmETXPsrb3sJOV3QGLjc4gQSI0hO1 2QwTfj3GQDpNq/0TmjT3gIEhV2IJN5wcNhgC3kxvvdZluNW98TvQ2MQyNnXkzDcSzvSL K3YQ== X-Received: by 10.204.5.211 with SMTP id 19mr7123845bkw.29.1360790342562; Wed, 13 Feb 2013 13:19:02 -0800 (PST) Received: from oskar.fritz.box (e177139085.adsl.alicedsl.de. [85.177.139.85]) by mx.google.com with ESMTPS id v2sm3541824bkw.5.2013.02.13.13.18.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 13:19:01 -0800 (PST) Message-ID: <511C0342.1030302@gmail.com> Date: Wed, 13 Feb 2013 22:18:58 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Paul E. Jones" , 'Markus Lanthaler' References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <038501ce0a1f$54d3e580$fe7bb080$@packetizer.com> In-Reply-To: <038501ce0a1f$54d3e580$fe7bb080$@packetizer.com> Content-Type: multipart/alternative; boundary="------------070704070201080706070504" Cc: 'IETF Apps Discuss' , calsify@ietf.org, 'CardDAV' Subject: Re: [calsify] [apps-discuss] iCalendar and vCard in JSON: WG draft charter 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: Wed, 13 Feb 2013 21:19:06 -0000 This is a multi-part message in MIME format. --------------070704070201080706070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Markus Lanthaler >> Sent: Wednesday, February 13, 2013 5:06 AM >> To: 'Barry Leiba'; 'Cyrus Daboo' >> Cc: 'IETF Apps Discuss'; calsify@ietf.org; '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 >> >> --------------070704070201080706070504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of Markus Lanthaler
Sent: Wednesday, February 13, 2013 5:06 AM
To: 'Barry Leiba'; 'Cyrus Daboo'
Cc: 'IETF Apps Discuss'; calsify@ietf.org; '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

--------------070704070201080706070504-- From timhare@comcast.net Wed Feb 13 20:49:26 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 A03DC21F866E for ; Wed, 13 Feb 2013 20:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.578 X-Spam-Level: X-Spam-Status: No, score=-98.578 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 ej9qmtPn-1fC for ; Wed, 13 Feb 2013 20:49:26 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3F621F8651 for ; Wed, 13 Feb 2013 20:49:22 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id 04h51l0011ei1Bg584pNH3; Thu, 14 Feb 2013 04:49:22 +0000 Received: from THARE ([98.230.25.31]) by omta24.westchester.pa.mail.comcast.net with comcast id 04pM1l00l0gFhxu3k4pNrR; Thu, 14 Feb 2013 04:49:22 +0000 From: "Tim Hare" To: , "'Calsify'" References: <51111E04.3000400@rpi.edu> In-Reply-To: <51111E04.3000400@rpi.edu> Date: Wed, 13 Feb 2013 23:49:19 -0500 Message-ID: <000301ce0a6e$a66e2640$f34a72c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4DsVKWZdGb4ND0Rte4ooY0Kx2aMwGvO3TA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360817362; bh=bdWyBFF+HTHAzh2GiCipa97l9IbgZrYSbW9OCNvsJ0c=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rtr+q3dQV9sKezSlKulNhRY2uV6nTA9JddaRf8VZV4/cbdUY3UcmtyYF+Se8vQtro u8w4aFfw3VmgFjuxdte+sGUWjAlpFluosZ71iw2QNn2Kh7GJWtSpGncrWR1vMyAhJE NzUYzX5/wQ7gZz2FWzXo2byiN9Y/tnVlf4ejmFCdrQeB9nV3MZfPCExtuVBPGOD6FB mNOl6pIJs4Xo0iBA3/EaoZr/+R1q6MlK7wuo6fmWRsezG+k0Hi5KxZN9NIOzfeFm10 ZQRFJd56h/EbEd0ehidnlJzJObcQdNB4Y3m5d2Y2IzIKTSa3fROuMto7iAkp023G2G zpPfrnBORoXMA== Subject: [calsify] VPOLL? 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: Thu, 14 Feb 2013 04:49:26 -0000 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? =20 Thanks Tim Hare Interested Bystander, Non-Inc. From cyrus@daboo.name Thu Feb 14 06:53:35 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 63A9221F8846 for ; Thu, 14 Feb 2013 06:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 J9wxyUNilZbD for ; Thu, 14 Feb 2013 06:53:33 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 229E921F8836 for ; Thu, 14 Feb 2013 06:53:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6A6E93D5E5F0; Thu, 14 Feb 2013 09:53:28 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMUe1n2aAy-J; Thu, 14 Feb 2013 09:53:27 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id CB72A3D5E5E5; Thu, 14 Feb 2013 09:53:26 -0500 (EST) Date: Thu, 14 Feb 2013 09:53:23 -0500 From: Cyrus Daboo To: Tim Hare , caldeveloper-l@lists.calconnect.org, 'Calsify' Message-ID: <7C0A57D474B4A3E138E0993C@caldav.corp.apple.com> In-Reply-To: <000301ce0a6e$a66e2640$f34a72c0$@net> References: <51111E04.3000400@rpi.edu> <000301ce0a6e$a66e2640$f34a72c0$@net> 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=521 Subject: Re: [calsify] VPOLL? 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: Thu, 14 Feb 2013 14:53:35 -0000 Hi Tim, --On February 13, 2013 at 11:49:19 PM -0500 Tim Hare wrote: > 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? As you may have noticed we did recently post a draft on VPOLL, so calsify seems like an appropriate place to discuss the draft: . -- Cyrus Daboo From cyrus@daboo.name Fri Feb 15 07:52:08 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 753C421F88B6; Fri, 15 Feb 2013 07:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 fX2yyCZ9ICJw; Fri, 15 Feb 2013 07:52:07 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id F185321F88A3; Fri, 15 Feb 2013 07:52:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5DAAB3D6F725; Fri, 15 Feb 2013 10:51:58 -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 xALI-2H3Mala; Fri, 15 Feb 2013 10:51:57 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id F1ECB3D6F71A; Fri, 15 Feb 2013 10:51:56 -0500 (EST) Date: Fri, 15 Feb 2013 10:51:53 -0500 From: Cyrus Daboo To: vcarddav@ietf.org, Calsify Message-ID: <119F1DF22591D4E13D8FD08D@caldav.corp.apple.com> 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=407 Subject: [calsify] Parameter encoding spec published 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, 15 Feb 2013 15:52:08 -0000 Hi folks, FYI the new parameter encoding spec has just been published as an RFC: . I've already added support for it to the Python iCalendar/vCard library: . I am interested in knowing if there are other implementations so that maybe we can do some interop testing. -- Cyrus Daboo From cyrus@daboo.name Fri Feb 15 08:06: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 A300021F857B for ; Fri, 15 Feb 2013 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Xrb0ClwnsZzH for ; Fri, 15 Feb 2013 08:06:13 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 17A3D21F8428 for ; Fri, 15 Feb 2013 08:06:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B31C23D6FB8E; Fri, 15 Feb 2013 11:06:12 -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 sng3KmQ1-8Ph; Fri, 15 Feb 2013 11:06:11 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 835DB3D6FB83; Fri, 15 Feb 2013 11:06:10 -0500 (EST) Date: Fri, 15 Feb 2013 11:06:07 -0500 From: Cyrus Daboo To: Tim Hare , caldeveloper-l@lists.calconnect.org, 'Calsify' Message-ID: In-Reply-To: <000301ce0a6e$a66e2640$f34a72c0$@net> References: <51111E04.3000400@rpi.edu> <000301ce0a6e$a66e2640$f34a72c0$@net> 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=2656 Subject: Re: [calsify] VPOLL? 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, 15 Feb 2013 16:06:13 -0000 Hi Tim, --On February 13, 2013 at 11:49:19 PM -0500 Tim Hare wrote: > My specific question (right now): is one VPOLL use case the proverbial > one of scheduling a haircut? 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 dude. 3. Long haired dude can then pick the slot that works best for them and reply. 4. Booking system then sends out regular iTIP request to book. Things to note: 1. This is "reverse" in the sense that the effective "attendee" of the meeting initiates the meeting request. In a regular iTIP workflow it is "organizer", not "attendee", that initiates the process. 2. Most of the above can be accomplished with little interaction with humans on either end. The only things needed from a human are the initial choice of available times (which may be as simple as presenting choices such as "next week", "this month", etc), and the choice of which slot in the VPOLL is best. On the hairdresser side the booking system can be fully automated. 3. All of this protocol exchange is accomplished using standards (or potential standards) and does not require any particular type of calendaring/booking system on either side of the exchange (i.e,. its not tied to CalDAV, or any other calendar systems). 4. This process should be possible using a local area network of some sort so that the "attendee" can actually make their next booking whilst at the hairdresser, doctor's office etc using their mobile device (i.e., a basic local area discovery for the booking system is needed - no need to have to work out calendar user addresses etc). 5. This is just my view of how such a system could work - there are many possible variations. The key is having the standards in place for the data exchange. -- Cyrus Daboo From cyrus@daboo.name Thu Feb 21 09:00: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 0292F21F8501; Thu, 21 Feb 2013 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 1Fw41Q2Q0Wij; Thu, 21 Feb 2013 09:00:08 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 308E621F87D5; Thu, 21 Feb 2013 09:00:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5C67B3DCC0E3; Thu, 21 Feb 2013 12:00:01 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN9fErwSgnLm; Thu, 21 Feb 2013 12:00:00 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id DCEF93DCC0AA; Thu, 21 Feb 2013 11:59:58 -0500 (EST) Date: Thu, 21 Feb 2013 11:59:54 -0500 From: Cyrus Daboo To: Pete Resnick Message-ID: <06C4C4FFECBE39C5BF6300AE@caldav.corp.apple.com> In-Reply-To: <51264270.4050205@qti.qualcomm.com> References: <51264270.4050205@qti.qualcomm.com> 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=921 Cc: vcarddav@ietf.org, calsify@ietf.org, IETF Apps Discuss Subject: Re: [calsify] [apps-discuss] iCalendar and vCard in JSON: WG draft charter 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: Thu, 21 Feb 2013 17:00:13 -0000 Hi Pete, --On February 21, 2013 at 9:51:12 AM -0600 Pete Resnick 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 From ciny.joy@oracle.COM Wed Feb 27 16:16:53 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 8FC9221F8B35; Wed, 27 Feb 2013 16:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.597 X-Spam-Level: X-Spam-Status: No, score=-8.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 vIXvIy7w35zs; Wed, 27 Feb 2013 16:16:47 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAAE21F8438; Wed, 27 Feb 2013 15:54:13 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1RNsBIk006295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Feb 2013 23:54:12 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1RNsBCo020739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 23:54:11 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1RNsASZ001021; Wed, 27 Feb 2013 17:54:11 -0600 Received: from dhcp-whq-twvpn-1-vpnpool-10-159-136-155.vpn.oracle.com (/10.159.136.155) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Feb 2013 15:54:10 -0800 From: Ciny Joy Content-Type: multipart/alternative; boundary=Apple-Mail-968--697523429 Date: Wed, 27 Feb 2013 15:54:09 -0800 Message-Id: <70665AD4-7584-438F-B6A9-FABE167D5227@oracle.COM> To: CardDAV , Calsify Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [calsify] New drafts for review 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: Thu, 28 Feb 2013 00:16:53 -0000 --Apple-Mail-968--697523429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 --Apple-Mail-968--697523429 Content-Type: multipart/mixed; boundary=Apple-Mail-969--697523429 --Apple-Mail-969--697523429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii - Base vCard objectclass property definition - http://tool= s.ietf.org/html/draft-vcard-objectclass-00
- = Definition of the "schedulable" objectclass value used to define any = schedulable entity - http://tool= s.ietf.org/html/draft-vcard-schedulable-00
- = Modified vCard representation of a schedulable resource that makes use = of the schedulable objectclass - http://too= ls.ietf.org/html/draft-cal-resource-vcard-02

Thanks,
Ciny

= --Apple-Mail-969--697523429 Content-Disposition: attachment; filename="[VCARDDAV] Proposal for new VCARD OBJECTCLASS property.eml" Content-Type: message/rfc822; name="[VCARDDAV] Proposal for new VCARD OBJECTCLASS property.eml" Content-Transfer-Encoding: 7bit Received: from acsinet22.oracle.com (/141.146.126.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Nov 2012 22:26:03 -0700 Received: from aserp1020.oracle.com (aserp1020.oracle.com [141.146.126.67]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA45Q3MR006442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Nov 2012 05:26:03 GMT Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by aserp1020.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA45Q2nb000896; Sun, 4 Nov 2012 05:26:02 GMT Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB521F98B6; Sat, 3 Nov 2012 22:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1352006762; bh=3yuGv4AvRfBTmN6atr8214hBe7GOe1Xxk0axd39Fizo=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=MIqeDu68PfEdlR2KFxWKPDOqK6CYnXKA5gwM203g06LccjkJ7SE6eduh3MriurNx2 ie5Cc+f1SiDxAz9UOTJ36moitKf88JpozHAGr20g2WoCyUTQ4Sil9vtfH5diISXBHD Qmv/ajj2O9cbawOozc6/MJnTpyjhRVITvLSFamyI= X-Original-To: vcarddav@ietfa.amsl.com Delivered-To: vcarddav@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7326621F960C; Sat, 3 Nov 2012 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 Ugk8LfrTHtgF; Sat, 3 Nov 2012 22:25:59 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7221F9481; Sat, 3 Nov 2012 22:25:59 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so1600867qao.10 for ; Sat, 03 Nov 2012 22:25:59 -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 :content-type; bh=NtS+ohssWJyvl/VrBWIXAEMMznEQhtgauu6C3xJ2rf0=; b=w5hvAP0xPTJgyCNA8zTbehBEysECNiTjeB0rhl4bHIHdE2SxSRxkbTTXiGXjUmLJR9 OzzY8thoaXaVxHDNnCjZemS2ZB7jTPrLfYpORsRzQAWsZn03BVmEwxO2aN8CfZsDq7T5 DOhehmEwJbK90728RuKd1AogrndXvrP6mzJ4QP09Fxi6A3jnkuQdze6E6c+dHqqu2/Wy 9Sw1BQK5RhpinDTk0PgHHN2BGSHqvx2273FAfcZTPsisBXVNAO19xZV26VE3yEhy0EpW uw0ub8p39o4VdSTs6uM2TvcpepFFTOSgHPAnfL+zWcjjSDp7/SdUdFAPL2is7JLYVFtY lkdw== Received: by 10.49.58.212 with SMTP id t20mr10729521qeq.26.1352006758874; Sat, 03 Nov 2012 22:25:58 -0700 (PDT) Received: from [192.168.1.117] (cpe-74-76-210-192.nycap.res.rr.com. [74.76.210.192]) by mx.google.com with ESMTPS id i9sm2555143qak.3.2012.11.03.22.25.57 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 22:25:58 -0700 (PDT) Message-ID: <5095FC65.2080803@gmail.com> Date: Sun, 04 Nov 2012 01:25:57 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF Calsify , CardDAV Subject: [VCARDDAV] Proposal for new VCARD OBJECTCLASS property X-BeenThere: vcarddav@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF vcarddav wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9049355102935403165==" Sender: vcarddav-bounces@ietf.org Errors-To: vcarddav-bounces@ietf.org X-Flow-Control-Info: class=Default reputation=ipRepBelow100 ip=64.170.98.30 ct-class=R3 ct-vol1=0 ct-vol2=6 ct-vol3=6 ct-risk=10 ct-spam1=0 ct-spam2=1 ct-bulk=81 rcpts=6 size=6417 X-Source-IP: mail.ietf.org [64.170.98.30] X-MM-CT-Classification: not spam X-MM-CT-RefID: str=0001.0A090204.5095FC6B.001F:SCFSTAT18996871,ss=1,re=-4.000,fgs=0 This is a multi-part message in MIME format. --===============9049355102935403165== Content-Type: multipart/alternative; boundary="------------070204090402090402030604" This is a multi-part message in MIME format. --------------070204090402090402030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit During discussions on the new vcard resource draft http://tools.ietf.org/html/draft-cal-resource-vcard-01 it seemed that we had significant overlap with the device specification http://tools.ietf.org/html/draft-salgueiro-vcarddav-kind-device-02 and also applications: RFC6473 We also realized we have a subset of properties which could apply to any schedulable entity, e.g. autoschedule, booking window, calendar user addresss (cua) and so on. We propose a new, multiply occurring property: OBJECTCLASS. A vcard containing one or more occurrences of this property MUST conform to the related specification. So for example we might have OBJECTCLASS: SCHEDULABLE The appearance of this property and value requires that the cua be present but it also allows us to apply appropriate defaults when a property is absent. For example, our resource draft states that the absence of the AUTOSCHEDULE property implies that invitations are automatically accepted. A further advantage is that it seems to facilitate mapping from ldap to vcard. There are many widely used ldap object classes which it would be useful to make visible in vcard. It enables authors of specifications to worry less about areas in which they are not expert. Any entity which is schedulable can be made so simply by adding OBJECTCLASS: SCHEDULABLE to the entity (and any appropriate properties). It also avoids trying to resolve strict hierarchies of 'thing'. A device is a resource but so is a room and both may or may not be schedulable. This proposal does not appear to conflict with the current specifications. It does however appear to offer a way to enhance the usability of vcards and provide consumers of the information with the assurance that it was generated correctly. -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 --------------070204090402090402030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
During discussions on the new vcard resource draft http://tools.ietf.org/html/draft-cal-resource-vcard-01 it seemed that we had significant overlap with the device specification

http://tools.ietf.org/html/draft-salgueiro-vcarddav-kind-device-02

 and also applications:

RFC6473

We also realized we have a subset of properties which could apply to any schedulable entity, e.g. autoschedule, booking window, calendar user addresss (cua) and so on.

We propose a new, multiply occurring property: OBJECTCLASS.

A vcard containing one or more occurrences of this property MUST conform to the related specification. So for example we might have

OBJECTCLASS: SCHEDULABLE

The appearance of this property and value requires that the cua be present but it also allows us to apply appropriate defaults when a property is absent. For example, our resource draft states that the absence of the AUTOSCHEDULE property implies that invitations are automatically accepted.

A further advantage is that it seems to facilitate mapping from ldap to vcard. There are many widely used ldap object classes which it would be useful to make visible in vcard.

It enables authors of specifications to worry less about areas in which they are not expert. Any entity which is schedulable can be made so simply by adding OBJECTCLASS: SCHEDULABLE to the entity (and any appropriate properties).

It also avoids trying to resolve strict hierarchies of 'thing'. A device is a resource but so is a room and both may or may not be schedulable.

This proposal does not appear to conflict with the current specifications. It does however appear to offer a way to enhance the usability of vcards and provide consumers of the information with the assurance that it was generated correctly.


-- 
Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

--------------070204090402090402030604-- --===============9049355102935403165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ VCARDDAV mailing list VCARDDAV@ietf.org https://www.ietf.org/mailman/listinfo/vcarddav --===============9049355102935403165==-- --Apple-Mail-969--697523429 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail-969--697523429-- --Apple-Mail-968--697523429--