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
