[Design] Options for Invitation workflow in 0.7
sheila at osafoundation.org
Tue Jan 24 17:34:39 PST 2006
This seems like a great list of possibilities but much of this is
certainly beyond the scope of 0.7. Jeffrey has put together his
thoughts and outlined a range of interoperability scenarios that we
should be thinking about. We do not yet know which of these (if any)
we will be addressing in our 0.7 implementation of invitations. We
will be meeting this week to explore this further and the results of
those discussions will be posted to the design list.
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
> ** Centralization **
> iTIP provides for one centralized organizer for a meeting. Other
> meeting participants can send on behalf of the organizer (in a
> 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
> I don't want to get too deep into it here, but perhaps
> standards-oriented folks could meet some time and brainstorm issues
> like to get clear on. For this thread, suffice it to say that
> 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
> could be something else)
> B) Landis publishes all his events to a CalDAV server, the CalDAV
> 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
> people to do this. I also don't know if/when Cosmo is likely to
> 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
> seems fine as a first pass.
> SWAG for a wildly ugly first-pass invitation UI implementation: 5
> ** Meeting negotiation thread UI **
> I think it would be really cool to render a conversation around an
> 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
> 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
> ** 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
> 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,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design