VPOLL: Consensus Scheduling Component for iCalendar
draft-york-vpoll-01

Abstract

This specification introduces a new iCalendar component which allows for consensus scheduling, that is voting on a number of alternative meeting or task alternatives.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 05, 2014.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction
2. Conventions and Terms Used in This Document
3. Simple Consensus Scheduling
3.1. The VPOLL Component: An Overview
3.2. The VPOLL Subcomponents: An Overview
3.3. VPOLL responses
3.4. VPOLL updates
3.5. VPOLL Completion
4. iCalendar Extensions
4.1. Updated Property Parameters
4.1.1. Updated Relation Type Value
4.1.2. Updated Status Value
4.2. New Property Parameters
4.2.1. Public-Comment
4.2.2. Response
4.2.3. Stay-Informed
4.3. New Properties
4.3.1. Accept-Response
4.3.2. Poll-Item-Id
4.3.3. Poll-Mode
4.3.4. Poll-properties
4.3.5. Poll-Winner
4.3.6. Voter
4.4. VPOLL Component
5. Poll Modes
5.1. POLL-MODE:BASIC
5.1.1. Property restrictions
5.1.2. Outcome reporting
6. iTip Extensions
6.1. Methods
6.2. Interoperability Models
6.2.1. Delegation
6.2.2. Acting on Behalf of Other Calendar Users
6.2.3. Component Revisions
6.2.4. Message Sequencing
6.3. Application Protocol Elements
6.3.1. Methods for VPOLL Calendar Components
6.3.1.1. PUBLISH
6.3.1.2. REQUEST
6.3.1.2.1. Rescheduling a poll
6.3.1.2.2. Updating or Reconfirmation of a Poll
6.3.1.2.3. Confirmation of a Poll
6.3.1.2.4. Closing a Poll
6.3.1.2.5. Delegating a POll to Another CU
6.3.1.2.6. Changing the Organizer
6.3.1.2.7. Sending on Behalf of the Organizer
6.3.1.2.8. Forwarding to an Uninvited CU
6.3.1.2.9. Updating Voter Status
6.3.1.3. REPLY
6.3.1.4. CANCEL
6.3.1.5. REFRESH
6.3.1.6. POLLSTATUS
7. CalDAV Extensions
7.1. Calendar Collection Properties
7.1.1. CALDAV:supported-vpoll-component-sets
7.1.2. CALDAV:vpoll-max-items
7.1.3. CALDAV:vpoll-max-active
7.1.4. CALDAV:vpoll-max-voters
7.1.5. CalDAV:even-more-properties
7.2. Additional Preconditions for PUT, COPY, and MOVE
7.3. CalDAV:calendar-query Report
7.3.1. Example: Partial Retrieval of VPOLL
7.4. CalDAV time ranges
8. Security Considerations
9. IANA Considerations
9.1. Parameter Registrations
9.2. Property Registrations
9.3. POLL-MODE Registration Template
9.4. POLL-MODE Registrations
10. Acknowledgements
11. Normative References
Appendix A. Open issues
Appendix B. Change log
Authors' Addresses

1. Introduction

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 may adjust their own meeting schedules to make themselves available for a popular choice.

The component and properties defined in this specification provide a standardized structure for this process and allow calendar clients and servers and web based services to interact.

These structures also have uses beyond the relatively simple needs of most meeting organizers. The process of coming to consensus can also be viewed as a bidding process.

2. Conventions and Terms Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Additionally we will use the following terms:

Consensus Scheduling:: The process whereby we come to some agreement on meeting or task alternatives and then book that meeting or task.
Active Vpoll:: A vpoll may have a DTSTART, DTEND and DURATION which may define the start and end of the active voting period.
Voter:: A participant who votes on th ealternatives. A voter need not be an attendee of any of the alternatives presented.

3. Simple Consensus Scheduling

This specification defines components and properties which can be used for simple consensus scheduling but also have the generality to handle more complex cases. To provide an easy (and for many - sufficient) introduction to consensus scheduling and VPOLL we will outline the flow of information for the simple case of voting on a number of meeting alternatives which differ only in time. In addition the voters will all be potential attendees.

This specification not only defines data structures but adds a new iTip method used when consensus has been reached. we will show how a VPOLL object is used to inform voters of the state of a simple vote on some alternatives.

3.1. The VPOLL Component: An Overview

The VPOLL component acts as a wrapper for a number of alternatives to be voted on, together with some properties used to maintain the state of the voting. For our simple example the following VPOLL properties and sub-components are either required or appropriate:

DTSTAMP:: The usual [RFC5545] property.
SEQUENCE:: The usual [RFC5545] property. See below for SEQUENCE behavior.
UID:: The usual [RFC5545] property.
ORGANIZER:: The usual [RFC5545] property. In general this need not be an organizer of any of the alternatives. In this simple outline we assume it is the same.
SUMMARY:: The usual [RFC5545] property. This optional but recommended property provides the a short title to the poll.
DESCRIPTION:: The usual [RFC5545] property. This optional property provides more details.
DTEND:: The usual [RFC5545] property. This optional property provides a poll closing time and date after which the VPOLL is no longer active.
POLL-MODE:: A new property which defines how the votes are used to obtain a result. For our use case it will take the value "BASIC" meaning one event will be chosen from the alternatives.
POLL-PROPERTIES:: A new property which defines which icalendar properties are being voted on. For our use case it will take the value "DTSTART, LOCATION" meaning only those properties are significant for voting. Other properties in the events may differ but are not considered significant for the voting process.
VOTER:: A new property. There is one of these for each voter and it is similar to the [RFC5545] ATTENDEE property. In the VPOLL component it shows who takes part in the voting.
VEVENT:: In our simple use case there will be multiple VEVENT sub-components defining the alternatives. Each will have a different date and or time for the meeting.

       BEGIN:VCALENDAR
       VERSION:2.0
       PRODID:-//Example//Example
       METHOD:REQUEST
       BEGIN:VPOLL
       POLL-MODE:BASIC
       POLL-PROPERTIES:DTSTART,LOCATION
       ORGANIZER:mailto:mike@example.com
       UID:sched01-1234567890
       DTSTAMP:20120101T000000Z
       SUMMARY:What to do this week
       DTEND:20120101T000000Z
       VOTER:mailto:cyrus@exmaple.com
       VOTER:mailto:eric@example.com
       BEGIN:VEVENT.......(with a poll-item-id=1)
       END:VEVENT
       BEGIN:VEVENT.......(with a poll-item-id=2)
       END:VEVENT
       BEGIN:VEVENT.......(with a poll-item-id=3)
       END:VEVENT
       END:VPOLL
       END:VCALENDAR

Putting that together we can construct an example VPOLL with 3 voters and 3 alternative meetings:

As can be seen in the example above, there is an iTip METHOD property with the value REQUEST. The VPOLL object will be distributed to all the voters, either through iMip or through some VPOLL enabled service.

3.2. The VPOLL Subcomponents: An Overview

Within the VPOLL component we have the alternatives to vote on. In many respects these are standard [RFC5545] components. For our simple use case they are all VEVENT components. In addition to the usual [RFC5545] properties some extra properties are used for a VPOLL.

POLL-ITEM-ID:: This provides a unique reference to the sub-component within the VPOLL. It's value SHOULD be a small integer.
VOTER:: The VOTER property within a VPOLL sub-component specifies the state of the vote for that voter. The RESPONSE parameter supplies the current vote in the range 0 to 100. For many purposes this is too fine grained and recommended values are defined for voting preferences of "NO", "MAYBE" and "YES" with an additional "YES but not the preferred outcome". These properties will be added to the sub-components as responses appear.

3.3. VPOLL responses

Upon receipt of a VPOLL REQUEST the voter will reply with a VPOLL component containing their vote. In our simple case it will have the following properties:

DTSTAMP:: The usual [RFC5545] property.
SEQUENCE:: The usual [RFC5545] property. See below for SEQUENCE behavior.
UID:: Same as the request.
ORGANIZER:: Same as the request.
SUMMARY:: Same as the request.
VOTER:: One only - the voter replying.
POLL-ITEM-ID:: One per item being voted on. There does not need to be one for each sub-component but each REPLY will set the voting state for every sub-component.

Note that a voter can send a number of REPLYs for each REQUEST sent by the organizer. Each REPLY completely replaces the voting record for that voter for all components being voted on. In our example, if Eric responds and votes for items 1 and 2 and then responds again with a vote for only item 3, the final outcome is one vote on item 3.

       BEGIN:VCALENDAR
       VERSION:2.0
       PRODID:-//Example//Example
       METHOD: REPLY
       BEGIN:VPOLL
       ORGANIZER:mailto:douglm@example.com
       VOTER:mailto:cyrus@example.com
       UID:sched01-1234567890
       DTSTAMP:20120101T010000Z
       SUMMARY:What to do this week
       POLL-ITEM-ID;RESPONSE=50;PUBLIC-COMMENT=Work on iTIP:1
       POLL-ITEM-ID;RESPONSE=100;COMMENT=Work on WebDAV:2
       POLL-ITEM-ID;RESPONSE=0:3
       END:VPOLL
       END:VCALENDAR

Putting this together we can construct an example REPLY VPOLL from Cyrus:

3.4. VPOLL updates

When the organizer receives a response from one or more voters the current state of the poll is sent to all voters. The new iTip method POLLSTATUS is used. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, ORGANIZER and VOTER.

In addition, for our use case, it will contain skeleton VEVENT sub-components with the POLL-ITEM-ID and VOTER properties. Clients receiving this poll status SHOULD merge it in to their own copy to give the full current status

       BEGIN:VCALENDAR
       VERSION:2.0
       PRODID:-//Example//Example
       METHOD: POLLSTATUS
       BEGIN:VPOLL
       ORGANIZER:mailto:douglm@example.com
       VOTER:mailto:cyrus@example.com
       VOTER:mailto:eric@example.com
       UID:sched01-1234567890
       DTSTAMP:20120101T020000Z
       SEQUENCE:0
       SUMMARY:What to do this week
       BEGIN:VEVENT
       POLL-ITEM-ID: 1
       VOTER;RESPONSE=50;COMMENT=Work on iTIP:
        mailto:cyrus@exmaple.com
       VOTER;RESPONSE=100:mailto:eric@example.com
       END:VEVENT
       BEGIN:VEVENT
       POLL-ITEM-ID: 2
       VOTER;RESPONSE=100;COMMENT=Work on WebDAV:
        mailto:cyrus@exmaple.com
       VOTER;RESPONSE=100:mailto:eric@example.com
       END:VEVENT
       BEGIN:VEVENT
       POLL-ITEM-ID: 3
       VOTER;RESPONSE=0:mailto:cyrus@example.com
       VOTER;RESPONSE=0:mailto:eric@example.com
       END:VEVENT
       END:VPOLL
       END:VCALENDAR

An example:

3.5. VPOLL Completion

After a number of REPLY messages have been received the poll will be considered complete. If there is a DTEND on the poll the system may automatically close the poll, or the organizer may, at any time, consider the poll complete. A VPOLL can be completed (and effectively closed for voting) by sending an iTip REQUEST message with the VPOLL STATUS property set to COMPLETED.

The poll winner is confirmed by sending a final iTip REQUEST message with the VPOLL STATUS property set to CONFIRMED. In this case the VPOLL component contains all the events being voted on along with a POLL-WINNER property to identify the winning event.

       BEGIN:VCALENDAR
       VERSION:2.0
       PRODID:-//Example//Example
       METHOD: REQUEST
       BEGIN:VPOLL
       ORGANIZER:mailto:douglm@example.com
       UID:sched01-1234567890
       DTSTAMP:20120101T030000Z
       COMPLETED:20120101T030000Z
       SEQUENCE:0
       SUMMARY:What to do this week
       STATUS:CONFIRMED
       POLL-WINNER:3
       BEGIN:VEVENT.......(with a poll-item-id=1)
       END:VEVENT
       BEGIN:VEVENT.......(with a poll-item-id=2)
       END:VEVENT
       BEGIN:VEVENT.......(with a poll-item-id=3)
       END:VEVENT
       END:VPOLL
       END:VCALENDAR

The VPOLL confirmation example:

4. iCalendar Extensions

4.1. Updated Property Parameters

4.1.1. Updated Relation Type Value

Relationship parameter type values are defined in section 3.2.15. of [RFC5545]. This specification updates that type to include the new relationship value POLL to provide a link to the VPOLL component in which the current component appears.

This property parameter is redefined by the following notation:

            reltypeparam       /= "RELTYPE" "=" "POLL"
                  ; Property value is a VPOLL uid

Format Definition:
Description:: This parameter can be specified on a property that references another related calendar component. The new parameter value indicates gthat the associated proeprty references a VPOLL component which contains the current component.

4.1.2. Updated Status Value

Status property values are defined in section 3.8.1.11. of [RFC5545]. This specification updates that type to valid VPOLL status values.

This property parameter is redefined by the following notation:

            statvalue /= statvalue-poll
                    ; Status values for "VPOLL".
            statvalue-poll = "IN-PROCESS"
                           / "COMPLETED"  ; Poll has closed,
                                          ; nothing has been chosen yet
                           / "CONFIRMED"  ; Poll has closed and
                                          ;winning items confirmed
                           / "CANCELLED"

Format Definition:

4.2. New Property Parameters

4.2.1. Public-Comment

This parameter is defined by the following notation:

   public-comment-param = "PUBLIC-COMMENT=" DQUOTE text DQUOTE

Parameter name:: PUBLIC-COMMENT
Purpose:: To allow voters to provide a public comment in their response.
Format Definition:
Description:: This parameter can be specified on the POLL-ITEM-ID property to allow a voter to add some commentary visible to all voters.

4.2.2. Response

This parameter is defined by the following notation:

    responseparam = "RESPONSE=" integer
          ; integer value 0..100

Parameter name:

RESPONSE

Purpose:

To specify a response vote.

Format Definition:

Description:

This parameter can be specified on the POLL-ITEM-ID property to provide the value of the voters response. This parameter allows for fine grained responses which are appropriate to some applications. For the case of individuals voting for a choice of events, client applications SHOULD conform to the following convention:

0 - 39 A "NO vote".
40 - 79 A "MAYBE" vote
80 - 89 A "YES - but not preferred vote"
90-100 A "YES" vote.

Clients MUST preserve the responseparam value when there is no change from the user even if they have a UI with fixed states (e.g. yes/no/maybe).

4.2.3. Stay-Informed

This parameter is defined by the following notation:

    stayinformedparam = "STAY-INFORMED" "=" boolean

Parameter name:: STAY-INFORMED
Purpose:: To specify the voter also wants to be added as an ATTENDEE when the poll is confirmed.
Format Definition:
Description:: This parameter MAY be specified on VOTER and, if the value is TRUE, indicates the voter wishes to be added to the final choice as a non participant.

4.3. New Properties

4.3.1. Accept-Response