Memorandum

To: Oasis-Open LegalXML ECF TC

From: James McMillan, National Center for State Courts

Re: Scheduling standards resources

Per request from the TC, I have prepared the following resource list from our discussion with the experts from the CalConnect, The Calendaring and Scheduling Consortium: http://www.calconnect.org/

Pertinent to our efforts is that this group is participating in the OASIS-Open Web Services group (WS-Calendar) TC https://www.oasis-open.org/apps/org/workgroup/ws-calendar/

And one of the ideas that the expert group suggested is that ECF send a representative to the CalConnect XXXII conference scheduled for San Jose, CA, January 26-30, 2015 (http://www.calconnect.org/calconnect32.shtml ). Also please note that as part of the conference they hold their their CalConnect Interoperability Test Event: http://www.calconnect.org/iop1501.shtml

Standards

The following are a list of scheduling and calendar related standards that the experts recommended that ECF study and consider for guidance for our possible scheduling extension.

 iCalendar (http://en.wikipedia.org/wiki/ICalendar ) is a computer file format which allows Internet users to send meeting requests and tasks to other Internet users, via , or sharing files with an extension of .ics. Recipients of the iCalendar data file (with supporting , such as an or calendar application) can respond to the sender easily or counter- propose another meeting date/time. There is an excellent properties chart shown here for the standard: http://en.wikipedia.org/wiki/ICalendar#mediaviewer/File:ICalendarSpecification.png

 iTip Standard (https://www.ietf.org/rfc/rfc2446.txt )- defines a protocol for exchanging iCalendar objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs); whoever initiates the exchange of data takes on the role of the "Organizer". This standard defines methods such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER (to negotiate a change in the entry), and DECLINE-COUNTER (to decline the counter-proposal). Another companion standard, "iCalendar Message-based Interoperability Protocol (iMIP)" (RFC 2447), defines a standard method for implementing iTIP on standard Internet email-based transports. The "Guide to Internet Calendaring" (RFC 3283) explains how iCalendar interacts with other calendar computer language (current and future).

 iSchedule - This is essentially iTip (iCalendar Transport-Independent Interoperability Protocol) over http and allows multiple calendar systems to transmit and receive scheduling messages. We are trying to work out issues related to identity but within a system ischedule is already usable to link together dispersed systems. While the draft looks expired, we are actively working on it at: http://www.ietf.org/archive/id/draft-desruisseaux-ischedule-05.txt

Page 1 of 3

CalDAV (http://caldav.calconnect.org/ ) as defined in Wikipedia - Calendaring Extensions to WebDAV, or CalDAV (http://en.wikipedia.org/wiki/CalDAV ) is an Internet standard allowing a client to access scheduling information on a remote server. It extends WebDAV (HTTP-based protocol for data manipulation) specification and uses iCalendar format for the data. The access protocol is defined by RFC 4791. It allows multiple client access to the same information thus allowing cooperative planning and information sharing. Many server and client applications support the protocol. Extensions to CalDAV for automated scheduling are also standardized, as RFC 6638.

And as noted by CalConnect expert, Mike Douglass, Senior Systems Programmer at Rensselaer Polytechnic Institute:

“A thought which may occur to you as you read the specs is "where's the scheduling". The CalDAV scheduling spec is separate from the access spec and we actually didn't address scheduling (in the meeting sense) in Cal-WS. CalDAV scheduling is actually easy from the perspective of the client - we refer to it as implicit scheduling and it's mostly handled by the servers. All the client has to do is set up the scheduling object (event/task/poll) store it in the organizers calendar and the server will deal with distributing it to the attendees. The intent has been to bring out an updated CalWS spec with scheduling included.

 VPOLL Consensus Scheduling Component for iCalendar (CalConnect Freebusy Technical Committee - IETF). As defined in the Introduction to the IETF draft (and describing a problem familiar to courts):

“The currently existing approach to agreeing on meeting times using iTip [RFC5546] and/or iMip [RFC6047] have some significant failings. There is no useful bargaining or suggestion mechanism in iTip, only the ability for a potential attendee to accept or refuse or to counter with a time of their own choosing.

Part of the problem is that for many potential attendees, their freebusy is not an accurate representation of their availability. In fact, when trying to schedule conference calls across different organizations, attendees may not be allowed to provide freebusy information or availability as this may reveal something of the organizations internal activities.

A number of studies have shown that large amounts of time are spent trying to come to an agreement - up to and beyond 20 working hours per meeting. Many organizers fall back on other approaches such as phone calls and email to determine a suitable time.

Online services have appeared as a result and these allow participants to vote on a number of alternatives without revealing or using freebusy or availability. When agreement is reached a conventional scheduling message may be sent to the attendees. This approach appears to reach consensus fairly rapidly. Peer pressure may have some bearing on this as all voters are usually able to see the current state of the voting and

Page 2 of 3

may adjust their own meeting schedules to make themselves available for a popular choice.” https://tools.ietf.org/html/draft-york-vpoll-02 https://calconnect.wordpress.com/2013/01/23/vpoll-consensus-scheduling-component-for-/

Scope and Next Steps

So the questions that comes to mind for ECF are:

1. Do courts only want to send one proposed hearing / trial date in a message and then revert to manual processes or, 2. Should the ideas in VPOLL be explored (certainly within a set number of limits/communications. I personally like this because the message could in turn call polling applications that the standard would not need to build. Just the call. 3. I think we need help on this and so I have put in a proposed budget item for the LegalXML SC for $5,000 to get it.

I look forward to our discussion on this.

Page 3 of 3