[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