Subject: Re: IRIP version 4 (Part 1a)

From: [email-masked]
Date: Mon, 15 Mar 1999 12:58:28 GMT

After getting some rest I woke w/a bad feeling I had overlooked something
last night.  I did.

Under 3.1.7 ICALDATA the format of the command is:
S: ICALDATA[:latencyTime]
R: 2.0.1
S: <MIME encapsulated ITIP Message>
S: .
R: <MIME encapsulated ITIP Message>
R: .
R: <reply code>

The examples, etc show just 1 MIME iTIP message coming back and state
(under 6.1.x in a few places) "Then it builds a reply".  This impies that
data gets queued up for the sender and then returned when complete.
However there may be cases where only a partial reply is available (for fan
out cases, etc).  This raises a few questions in my mind:

1: Is the iRIP server expected to buffer up all responses into 1
potentially massive reply?

2: Is there no option/thought that the iRIP server return what data it can
when it gets it so the sender can use it immediately?

3: If a sent iTIP message does not complete in time and the sender issues
an ABORT then what happens to that data the server has queued up for
returning?

4: Is there no way for the server to indicate in the Idle state that it has
at least a partial result that the sender may want to get instead of having
it just tossed out?

I can see some performance problems w/#1 and #2 off the bat.  If I were to
do a FreeBusy search on the CalSched WG to try and schedule the next WG
meeting, it could take some time.  If this involves a lot of data then my
servers gonna have to be very beefy and have lots of temp space or memory.
For a quad processor box w/4Gb RAM this may be ok but for the single
processor units w/128M it may not be.

There are also user friendliness issues like providing the data as soon as
possible so the user thinks something is going oin rather than just having
the "Wait" icon up w/no change in the UI, etc.

For #3 & #4, Id like to see some way to indicate that some partial data is
available and give the sender the option to retrieve it either before
ABORTing or before CONTINUING (so they can process it while the iRIP server
goes and gets more data before the next timeout).  Even if we KISS, there
should be some way for the receiver to indicate partial data and return it
to the sender for use.  Otherwise I can see someone tying up the IETF C&S
servers w/constant requerrying that may never complete and they just keep
getting back the same intermediate results instead of "polling" for it
while waiting and processing what it can get.

Bruce

---

From: [email-masked] (Steve Mansour)
Date: Tue, 23 Mar 1999 08:48:00 -0800

> potentially massive reply?

It is expected to give a reply code for every recipient specified. As mentioned
earlier the ICAL object portion of a reply is optional. In some cases, it will
not be possible to build a reply from all calendars to which a message was
delivered. So a reply code like 2.0.7 (QUEUED - the message has been queued for
delivery) could be returned.

> when it gets it so the sender can use it immediately?

yes. That's why you may get a 2.0.7 reply from one RECIPIENT's calendar and an
ical object plus a 2.0 reply from another RECIPIENT's calendar.

> an ABORT then what happens to that data the server has queued up for

It is not specified. This is bad. Any suggestions?

> at least a partial result that the sender may want to get instead of having

We currently don't have such a reply code, but we could certainly add one.
Seems reasonable to give the sender a clue that the server is at least making
progress.