Re: The need for a protocol

["Mark Horton" <mark@xxxxxxxxxx>]

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