[Design] Options for Invitation workflow in 0.7

[Lisa Dusseault]

Some of my thoughts on this too, attempting to propose a rather  
minimalist yet interop-oriented approach; our scope for invitations  
and free-busy can (should) be rather narrow for 0.7.

Note that I'm consciously proposing a system and a workflow that is  
not "complete".  It would provide the ability for an organizer to  
send an invitation that would be reasonably well received by any  
email client, not just Chandler.  It would provide the ability for an  
attendee to indicate their attendance, yes/no.  But I suspect we  
won't quickly get to the point of successfully handling other steps  
-- perhaps reschedules are a little fuzzy, the ability of a recipient  
to do a major update and automatically Notify others (see Mimi's  
concept of an explicit conscious Notification) would be interop- 
impaired, if even possible...   Anyway, I'm proposing some first  
steps and not addressing all steps.

To keep the scope for free-busy sharing narrow:  I don't think it's  
very important in 0.7 to do free-busy sharing in three different  
ways.  We could do just one approach with enough follow-through such  
that somebody could use it.  Later releases we can expand the # of  
approaches once we discover whether, for example, uploading volume is  
a problem.  We can also tweak the GUI in later releases as we add  
additional transports/locations for getting the information.

To keep the scope narrow for invitations, we can just do iMIP  
REQUEST, and possibly only do iMIP REQUEST for invite/reschedule, and  
not handle REQUEST response to REFRESH messages, and may or may not  
handle REQUEST as used to add a previously uninvited attendee.  Note  
that the REQUEST would have the URL, where available, of the shared  
event on a public server.
     - We might then try having attendees who can attend to update  
the event on the shared server, if they have write permission (this  
would be part of the normal workflow for accepting an invitation,  
with Chandler doing detection under the covers)
     - The next step, after doing some REQUEST support work and  
possibly the live server attendance update, would be to do REPLY (if  
write permission on a shared event is impossible), unless we run out  
of time.  (Again this would be part of the normal workflow for  
accepting an invitation, the fallback approach chosen under the  
covers when sharing can't be used)

I don't believe that a focus on interoperability makes the job harder  
for 0.7.  On the free-busy sharing side, having the CalDAV server  
calculate free-busy based on a shared calendar saves Chandler from  
having to write and test the functionality to generate free-busy  
rollups.  It also saves us from having to develop an alternate  
transport or alternate URL and how to advertise that.   On the  
invitations side, since we already parse iCalendar, receiving  
invitations in iCalendar (iMIP) saves us from having to write a new  
invitation parser.  (An internal format might be just as good but not  
provide interop)   That said, even though interoperability is a goal,  
let's not do a bunch of work to handle variations in 3rd party  
software support.  Bugs are OK, in fact we probably don't want to do  
much QA of (for example) Outlook, lotus, etc receiving iMIP messages  
-- not until we have more of the steps in place.

Thus I'm not sure I agree that if we're doing interop, everything's a  
little harder in the short run.  That depends on how *well* we do  
interop, and how *much* of it.  :)

Lisa

On Jan 23, 2006, at 7:58 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?
>
> ** 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?
> - 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?
> - 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?
>
> 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.
>
> 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...
>
> ** 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
> - 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>