[Design] Options for Invitation workflow in 0.7

[Mimi Yin]

Thank you Jeffrey for the thorough write up: See more in-line :o)

On Jan 23, 2006, at 7:57 PM, Jeffrey Harris wrote:

> Hi Folks,
>
> Here are lots of thoughts about invitations.
>
> ** Interop **
>
> One overarching question I have is how committed we are to doing
> interoperable invitations in 0.7 and beyond.  It's not clear to me how
> well Outlook and Lotus Notes implement iTIP, the IETF standard for
> invitations (you'll also hear me mention iMIP, iTIP over email).  My
> sense is Microsoft does it badly, Lotus does it well.
>
> If we're aiming for interop, everything's a little harder in the short
> term, but in the long run it's probably easier because the  
> standards are
> already written, and of course we get a bigger payoff if we can
> interoperate.  Basically, I think we should strive to comply with  
> iTIP.
>
> ** Centralization **
>
> iTIP provides for one centralized organizer for a meeting.  Other
> meeting participants can send on behalf of the organizer (in a  
> friendly,
> the organizer's sick, way), but the organizer's inbox can become a
> bottleneck if they're offline.
>
> Does Chandler want to copy this model for invitations?  Or do we  
> want to
>  provide for workflows where participants negotiate amongst themselves
> without requiring central organizer interaction?

In the past, we've said no. See proposal on Negotiation and  
Scheduling: http://lists.osafoundation.org/pipermail/design/2005- 
December/003687.html

Ideally, we'd want event invitations to work consistently with more  
generic notions of "item sharing" where the "owner" of the item can  
set ACLs specifying who has read and read/write privileges. It would  
be unfortunate if invitations worked as an exception.

However, while we've discussed this many times, we've never gotten  
beyond acknowledging this goal and then acknowledging that this is  
not how iTIP works and that reconciling to the two would be hard.


>
> ** CalDAV and iTIP **
>
> Unfortunately, CalDAV sharing and iTIP interactions confuse the  
> heck out
> of me.  A small taste:
> - If I subscribe to an event you're organizing and put it on my
> calendar, does that mean I've added myself as a meeting attendee?
No, you're just "monitoring" the event. You can add yourself by  
editing the attendee list, thereby signing yourself up for "capital- 
N" notifications (aka email updates).

> - What if you invite me (via iMIP, the email transport for iTIP
> messages) to a meeting you're sharing with me?  How does my acceptance
> or lack thereof interact with sharing?

Ideally, the invitation and shared event figure out that they're the  
same item.

> - What if you invite me to a few instances of a recurring meeting, but
> not the whole thing, and I'm subscribed to the whole recurring  
> meeting?

Nope. Or you could be subscribed to the entire reccurring meeting,  
but only on the attendee list for the ones you're invited to.

>
> I don't want to get too deep into it here, but perhaps
> standards-oriented folks could meet some time and brainstorm issues  
> we'd
> like to get clear on.  For this thread, suffice it to say that  
> smoothing
> out the bumps in iTIP and CalDAV seems thorny to me, but still  
> worth doing.
>
> SWAG to get a very buggy, probably makes sharing unhappy but works for
> common cases iMIP implementation with no UI: 5 days
>
> ** iMIP Security **
>
> Do we want to try to detect spoofing in iMIP traffic?  I think the
> answer is probably no, at least for 0.7, that would be a royal pain in
> the ass, but I want to raise the issue.  Anyone can spoof an email
> scheduling, accepting, or cancelling a meeting.  This won't matter if
> your calendar is private (script kiddies won't know what event UID to
> use), but for public calendars, this could be a pain.
>
> ** Free/busy publishing **
>
> There are three major ways of interacting with free/busy I'm aware of.
>
> A) Shaniqua publishes her free busy to an HTTP server (could be  
> CalDAV,
> could be something else)
> B) Landis publishes all his events to a CalDAV server, the CalDAV  
> server
> dynamically calculates free/busy
> C) Delin responds to an iTIP request for free/busy information
>
> It would be very appealing to implement B) in a Scooby/Chandler/Cosmo
> world where users might not be using Chandler all the time.
> Unfortunately, this requires that users publish their whole  
> calendars to
> a CalDAV server.  This is likely to be significantly slower than
> publishing a single VFREEBUSY file, so I don't know that we should  
> force
> people to do this.  I also don't know if/when Cosmo is likely to  
> support
> this.
>
> I think we definitely want to support A) and C), SWAG: 5 days.
>
> ** UI **
>
> I think a good workflow and UI for creating, reviewing, and accepting
> invititations is non-trivial, but we can hack together something ugly
> but usable pretty easily, I expect.
>
> I'm a fan of associating free/busy with contacts, not treating it  
> like a
> sidebar collection, but this requires more contact workflow  
> clarity.  So
> the proposal of treating free/busy just like subscribing to a  
> collection
> seems fine as a first pass.
>
> SWAG for a wildly ugly first-pass invitation UI implementation: 5  
> days.
>
> ** Meeting negotiation thread UI **
>
> I think it would be really cool to render a conversation around an  
> event
> in some clever way.  I don't know exactly how this would look,  
> hence how
> much effort it would take, but I think it's such a good idea we
> shouldn't forget about it. :)
>
> ** Stamping and Invitations **
>
> Mimi mentioned the idea of unstamping event-ness to reject a meeting
> invitation.  I think this won't play well with sharing.  It's very
> possible that you might invite me to a meeting I already have in my
> repository because I'm subscribed to your calendar, unstamping the  
> item
> for you would be bad.

Hmmm, I only remember this vaguely. I think we can extend event  
status for rejecting meetings?

>
> If I stamp-as-email, address, then send to invite people to an event,
> how does inviting more people later work?  I edit the existing  
> email and
> hit send again?  That's really different than what I'm used to, but I
> guess that could work.  I suppose uninviting people could work the  
> same
> way...
>

Think of it as Edit and Update?

> ** Probably out-of-scope for 0.7  **
> (but I'll mention them briefly, anyway)
>
> - Delegation (Esther organizes and/or schedules a meeting for Mitch).
> This is part of iTIP, SWAG: 5 days
> - Countering a meeting invitation with an alternate time (and  
> accepting
> or declining counters).  Part of iTIP.    The message body for this is
> easy, getting the UI right might be hard.  SWAG: 10 days

Well ideally, this would all be worked out in the item conversation,  
rather than all going back to the meeting organizer.

> - Cancelling meetings.  Again, part of iTIP, easy, good UI isn't
> necessary, although of course it would be nice to highlight
> cancellations somehow, which might take more effort.  SWAG: 1 day
> - Jabber transport for invitations (I really want to play with this,
> maybe in my self-directed time), SWAG: Large
> - "home time" free/busy vs. "work time".  For instance, if I go on
> vacation for a week, I want family and friends to see a different
> free/busy than coworkers.  I think figuring out how to do this would
> probably be hard.
>
> If you've gotten this far, that means you actually read the whole
> message.  Congratulations, and thanks. :)
>
> Have a nice night,
> Jeffrey