Re: [apps-discuss] iSchedule

Eric Burger <eburger@standardstrack.com> Sat, 23 February 2013 13:10 UTC

Return-Path: <eburger@standardstrack.com>
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 B394121F8FAC for <apps-discuss@ietfa.amsl.com>; Sat, 23 Feb 2013 05:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.216
X-Spam-Level:
X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 puGq3OGjcVwy for <apps-discuss@ietfa.amsl.com>; Sat, 23 Feb 2013 05:10:09 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13321F8FAA for <apps-discuss@ietf.org>; Sat, 23 Feb 2013 05:10:09 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:50498 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1U9Ere-0006yq-8i; Sat, 23 Feb 2013 05:10:06 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <C123A8528DA9269330639A06@caldav.corp.apple.com>
Date: Sat, 23 Feb 2013 08:10:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <814AF276-FB5F-4553-95ED-DA011412D477@standardstrack.com>
References: <C123A8528DA9269330639A06@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: apps-discuss@ietf.org
Subject: Re: [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: Sat, 23 Feb 2013 13:10:10 -0000

Cross post to the security directorate?

On Feb 22, 2013, at 11:14 AM, Cyrus Daboo <cyrus@daboo.name> wrote:

> 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 mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss