No BoF was held for this; it has been discussed in appsawg.
iSchedule Working Group (isched) Problem Statement: Calendar scheduling is the process by which organizers and attendees plan events or assign tasks. More specifically, it encompasses the exchange of requests/invitations and responses between organizers and attendees of scheduled events, tasks, or journal entries. The iCalendar (RFC 5545) and iTIP (RFC 5546) specifications form the basis of a data format for representing and exchanging such scheduling messages, independent of the transport protocol. CalDAV Scheduling (RFC 6638) defines a binding from iTIP to HTTP (draft-ietf-httpbis) via WebDAV (RFC 4918). CalDAV Scheduling is a client/server protocol where the server is responsible for sending scheduling messages and processing incoming scheduling messages. This protocol is only useful for scheduling between users of the same server. The iMIP (RFC 6047) protocol, which is a binding of iTIP to email-based transports, currently allows scheduling between users of different/separate calendaring and scheduling systems. Unfortunately, due to the nature of email, iMIP suffers from a few short-comings, notably: - Requests and replies are prone to delays, especially free/busy time queries (which typically are expected to complete in "real-time") - Requires integration of a user's calendar and email clients and/or requires an iMIP gateway to the calendar server(s) - iMIP has interoperability problems; in particular many iMIP clients are sensitive to the exact MIME structure of the email message they receive, sometimes ignoring any calendar data if the structure is not what is expected - The delivery status of scheduling messages may not always be available - Email has inherent security/privacy problems, with spam being a major concern Objectives: The iSchedule working group is chartered to develop a new HTTP-based binding of iTIP to overcome the deficiencies present in iMIP. Key requirements of this new protocol are: - Must be independent of any calendar system in use at the endpoints (i.e., the new protocol can act as a gateway between any standard or proprietary calendar system) - Includes a mechanism whereby the sender of a scheduling request can claim responsibility for sending the message as well as verifying the authenticity of the organizer of the request - Must be secure to circumvent problems inherent in email, such as spam. The working group will use existing technologies as much as possible (HTTP, iCalendar, iTIP etc) for the core transport features, and will attempt to use existing security technologies to satisfy the security requirements. The working group will focus on ease of deployment, with the barriers to adoption made as low as possible without compromising the security and integrity of the process. It is expected that this protocol will be used by very high volume/high traffic calendar service providers, so scalability will be addressed. Whilst several models for a security could be considered, to speed deployment and use of the new protocol, the working group will first develop a "domain-level" authorization scheme that will allow co-operating calendar service providers to accurately determine the source and authenticity of scheduling messages. To that end, iSchedule will leverage the proven DKIM Signature (RFC 6376) technology. However, because DKIM itself is designed for signing email, it has features and requirements that do not fit well with or apply to HTTP payloads. As a result, an effort has begun to extract and generalize the core technology from DKIM so that it may be reused and extended by other protocols such as iSchedule. This new mechanism is being named DomainKeys Security Tagging (DOSETA). Use of DOSETA should not prevent additional security models being used in the future as needed. The working group will use draft-desruisseaux-ischedule as the initial starting point for this work. That specification was originated by the Calendaring and Scheduling Consortium (CalConnect) and there are already several experimental, interoperable implementations in existence. Milestones: Jun 2013 - Accept iSchedule and DOSETA documents as Working Group items. Aug 2013 - Start Working Group Last Call on DOSETA document. Sep 2013 - Start Working Group Last Call on iSchedule document. Oct 2013 - Submit DOSETA and iSchedule documents to IESG.