RE: The need for a protocol

[Joe Hage <jhage@xxxxxxxxxxxxxxxxxxxx>]

Mark et All,

I agree with the need to have a direct-connect and a store-and-forward   
solution. In real life, many users will be in off-line mode and   
intermittently connected. We at Starfish have solved the e-mail group   
shceduling solution via messaging. Internet Sidekick has this capability.

DISCLAIMER: This is not a sollicitation for adopting a Starfish   
proprietary solution. If it is of interest to the IETF WG, we can make   
our message formats available to the WG for consideration.

The problem is complex and I'd like to offer a top level description of   
what Internet Sidekick's messaging-based calendaring is all about. It   
supports 2 message types from the initiator's side: FYI and RSVP.

FYI: This is For Your Information Only which applies to things like a   
company-wide meeting, a broadcast of some event. No reply is needed.   
Recipients can accept or decline this event to add it automatically to   
their calendar. Accept/Decline actions do not trigger a message back to   
the Initiator to avoid e-mail clutter.

RSVP: Repondez S'il Vous Plait is for Reply Requested. The recipient will   
take action on this event. Acceptable actions are:   
Accept/Decline/Delegate/Reschedule Request. Delegate is for Redirecting   
the invitation to another person. Reschedule Request allows recipient to   
request 3 alternate times and the option to attach a 30-day Free Time   
Report.

The messages that flow back and forth are tagged with HTML like tags.   
This makes it possible to MIME the message or vCalendar it or iCalendar   
it. Each event has a unique ID.

The uniqueness of this solution is that it enables anyone to schedule any   
event with anyone in any time zone. Even users who might have a primitive   
e-mail client can be invited and respond with ACCEPT/DECLINE.

In addition to all the above, Internet Sidekick supports e-mail based   
scheduling of resources as well as people. The only pre-requisite for   
users is to have a POP3 account or an MS Exchange account with an SMTP   
gateway to the Internet.

Thanks,

Joe Hage
Director, Sidekick Product Group
Starfish Software
http://www.starfishsoftware.com

 ----------
From:  Mark Horton[SMTP:mark@lucent.com]
Sent:  Wednesday, December 11, 1996 6:27 PM
To:  Paul E. Hoffman; IETF calsch WG
Subject:  Re: The need for a protocol

On Dec 11, 12:40pm, Paul E. Hoffman wrote:
> Subject: Re: The need for a protocol
> At 12:01 PM -0800 12/11/96, Steve Hanna wrote:
> >I'm certain that we will end up with a TCP-based calendaring
> >interoperability protocol (and probably an email-based transmission
> >mechanism, too).
>
> Steve, I know that you're more oriented towards direct-connect, but   
your
> parenthetical remark has to be addressed. It is not "probably": it is
> definitely. Both protocols are needed to serve the requirements of most
> users.
>
> Without a mail protocol, do you really want to tell your users, "Gee,   
there
> are routing problems on the Internet right now, you can't request that
> meeting"? Or, "it seems like the recipient's host is down right now, so   
I'm
> going to ignore your request and force you to submit it again by hand
> later"? Or even "your ISP has screwed up a bit, so no one can queue up
> requests for meetings with you"?
>
> Store-and-forward messaging has many features that   
must-have-direct-connect
> doesn't, and vice versa. The user requirements for calendaring and
> scheduling are not "either/or": they are "both/and".

>-- End of excerpt from Paul E. Hoffman

I'm not opposed to the existence of the mail-based protocol, but I have
to admit I don't have a good feeling when I read the complexity of the
operations.  A typical meeting has a *lot* of messages going back and   
forth
in the examples, some of which don't seem to do anything except confirm
closure.

The entire mail-based protocol reads like it was designed for interactive
clients and servers to use to directly talk to each other.  It reminds me
of TCP with all the 3-way handshakes going on.  It would make a great   
model
to base the interactive protocol on.

What bothers me is that, on every message, a human has to read mail and
actively hand the attachment to the calendar program.  The chances of a
packet being dropped (due to inattention on the part of the user) are   
very
high.  I don't see much discussion about what to do about timeouts.

I think it's extremely likely that event requests will be mailed as
attachments
and routinely dropped into calendars.  Also updates when things change.
But the other operations look pretty fancy to depend on those error-prone
humans to accomplish.

Is there an expectation that there is a mail-enabled address like
calendar@server.company.com to which these things are e-mailed, so
that no human is in the loop?  If so, that goes a lot further than
a MIME type.

If not, I get nervous about the complexity of the protocol.  I'd sure
like to see some examples that cover simpler cases, like:
 A schedules a meeting and sends it to B and C, B and C put
 it in their calendars.

 A schedules a meeting with B and C.  B comes up with a counter-offer
 to A.  (The counteroffer might be e-mailed by B's calendar app, or
 by B's e-mail user agent, or by the living breathing B as a plain
 text letter.  Interesting issue there.)  A reschedules and sends
 another version to B and C.  B and C put it on their calendars.

 (Note that C never replied, lots of real people won't.  Or maybe C
 is running a (gasp) incompatible package!)

The final "ack" on the existing examples seems unnecessary and perhaps
we should consider deleting it.

Don't get me wrong.  I am happy that all this power is in the MIME type.
I hope the interactive protococl has exactly the same operations that
map one-to-one with the e-mail operations.  But let's envision some
realistic use: if we do this by e-mail, lots of packets will drop due to
uncooperative people, let's view that lightweight version as a likely
scenario, perhaps even the default.

 Mark