Re: IRIP version 4 (Part 1a)

[Bruce_Kahn@xxxxxxxx]

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