[apps-discuss] iSchedule
Cyrus Daboo <cyrus@daboo.name> Fri, 22 February 2013 16:14 UTC
Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50321F8F58 for <apps-discuss@ietfa.amsl.com>; Fri, 22 Feb 2013 08:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Level:
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 Wp8ZNCVdVewf for <apps-discuss@ietfa.amsl.com>; Fri, 22 Feb 2013 08:14:54 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id B9DB121F8F52 for <apps-discuss@ietf.org>; Fri, 22 Feb 2013 08:14:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 573433DDB450 for <apps-discuss@ietf.org>; Fri, 22 Feb 2013 11:14:54 -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 3yy9v632nHNf for <apps-discuss@ietf.org>; Fri, 22 Feb 2013 11:14:53 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 437F93DDB444 for <apps-discuss@ietf.org>; Fri, 22 Feb 2013 11:14:53 -0500 (EST)
Date: Fri, 22 Feb 2013 11:14:50 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: apps-discuss@ietf.org
Message-ID: <C123A8528DA9269330639A06@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="2270"
Subject: [apps-discuss] iSchedule
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 16:14:55 -0000
Hi, For a while now a group of calendaring implementors (primarily within the Calendaring and Schedule Consortium - CalConnect) have been working on the iSchedule specification: <https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>. This specification aims to define a cross-domain calendaring and scheduling protocol based on existing IETF iCalendar (RFC 5545) and iTIP (RFC 5546) standards, using HTTP as the transport. We already have several experimental implementations of the protocol working interoperably (at the recent CalConnect event earlier this month we had four different implementations being tested). We are now at a point where we want broader IETF review (in particular apps and security areas) with the ultimate goal of developing this specification into a standard. Having consulted with Barry Leiba, we are initially bringing this for discussion within the Apps Area WG - and I would like to request time at the Orlando meeting to discuss the draft. There are two key pieces to this specification: iTIP over HTTP, and domain-level security. The first piece is pretty straight forward. The security piece is more complex. In our own discussions we determined that a domain-level security model was the important use case to tackle (at least at first). Given that, we settled on using DKIM (RFC 6376) - mostly because we did not want to invent anything new and DKIM is a somewhat well understood, deployed, interopable solution. Of course, up until now, DKIM has been used solely for email. However, the original intent of that work was to allow it to be extended to other protocols as the need might arise. To that end, some initial work was done on defining a more generic version: DOSETA - <http://tools.ietf.org/id/draft-crocker-doseta-base-03.txt>, though the current iSchedule spec is couched in terms of DKIM rather than DOSETA right now, mostly because work on DOSETA stalled. That is where we stand right now. We want to see a cross-domain scheduling standard produced by the IETF and believe our initial work on iSchedule is a good starting point. So this is a call to gauge interest in such work with the aim of perhaps having a BoF at the July meeting, or even a working group. -- Cyrus Daboo
- [apps-discuss] iSchedule Cyrus Daboo
- Re: [apps-discuss] iSchedule Eric Burger
- Re: [apps-discuss] iSchedule Claudio Allocchio