Subject: [calsify] VPOLL?

From: "Tim Hare" <[email-masked]>
Date: Wed, 13 Feb 2013 23:49:19 -0500

Is there an informal (or formal) mailing list for work on VPOLL?  Are such discussions on Calsify or Caldeveloper?

My specific question (right now):  is one VPOLL use case the proverbial one of scheduling a haircut?  

Thanks
Tim Hare
Interested Bystander, Non-Inc.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 14 Feb 2013 09:53:23 -0500

Hi Tim,

--On February 13, 2013 at 11:49:19 PM -0500 Tim Hare <[email-masked]> 
wrote:

> Is there an informal (or formal) mailing list for work on VPOLL?  Are
> such discussions on Calsify or Caldeveloper?
>

As you may have noticed we did recently post a draft on VPOLL, so calsify 
seems like an appropriate place to discuss the draft: 
<https://datatracker.ietf.org/doc/draft-york-vpoll/>.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 15 Feb 2013 11:06:07 -0500

Hi Tim,

> one of scheduling a haircut?

To actually address your question: the initial goal of VPOLL is to address 
a simple "polling" model where an "organizer" sends out a set of possible 
meetings (varying in one or more attributes like time, location, title, 
etc), and "voters" get to indicate their preference (on a scale of 0 - 
100), and then the "organizer" picks the "winning" meeting and uses regular 
iTIP behavior to book it.

The hairdresser problem is obviously something we also care about and can 
be done using VPOLL to - with one option being what I refer to as "reverse 
polling". Here is how that would work:

1. Long haired dude decides they need a haircut so they send their 
available time in the form of a VAVAILABILITY or VFREEBUSY component to the 
hairdressers "booking" system.

2. Booking system takes that availability and intersects with the open 
booking slots and generates a VPOLL for those which then get sent to the 
long haired dude.

3. Long haired dude can then pick the slot that works best for them and 
reply.

4. Booking system then sends out regular iTIP request to book.

Things to note:

1. This is "reverse" in the sense that the effective "attendee" of the 
meeting initiates the meeting request. In a regular iTIP workflow it is 
"organizer", not "attendee", that initiates the process.

2. Most of the above can be accomplished with little interaction with 
humans on either end. The only things needed from a human are the initial 
choice of available times (which may be as simple as presenting choices 
such as "next week", "this month", etc), and the choice of which slot in 
the VPOLL is best. On the hairdresser side the booking system can be fully 
automated.

3. All of this protocol exchange is accomplished using standards (or 
potential standards) and does not require any particular type of 
calendaring/booking system on either side of the exchange (i.e,. its not 
tied to CalDAV, or any other calendar systems).

4. This process should be possible using a local area network of some sort 
so that the "attendee" can actually make their next booking whilst at the 
hairdresser, doctor's office etc using their mobile device (i.e., a basic 
local area discovery for the booking system is needed - no need to have to 
work out calendar user addresses etc).

5. This is just my view of how such a system could work - there are many 
possible variations. The key is having the standards in place for the data 
exchange.

-- 
Cyrus Daboo