Re: IRIP version 4 (Part 1) - ICALDATA

[Bruce_Kahn@xxxxxxxx]

Doug replied (in part):
>> Is this intended to allow a CUA to attach to the CS over iRIP and
>> "retrieve" a calendar entry?
>
>Retrieve a reply that was delayed.

Please clarify this in the text then.

>> Ok, just how does the sender indicate their desired time limit?  I dont
see
>> anything to do this on first pass.  Also, will the receiver have the
option
>> to override or disobey this based on the receivers admins options??
>
>Unless I miss your point, 'ICALDATA:<timeout>' ?
>If its the same timeout that goes with ICALDATA, no - they would
>not be compliant.

(Further down in the draft is the info I didnt see on first pass about time
limits but...)  So, a sender has the option to be a 'hog' and the receiver
must obey that?!?  (ie: ICALDATA:100000)  I sure hope that you just misread
my question.  The receiver's admin MUST have the ability to set and enforce
their own limits that take prescedence over those of the sender.  Otherwise
I could cripple any CS by simply doing some operation that eats ALL of the
resources and lets no one else do anything...  Bad design!

I dont have my iRIP draft handy but I thought on second pass I saw some
error code about "excessive resource" or "excessive load".  This could be
applied as an error code where necessary...

>> ... just how will
>> the receiver tell the sender just how much or who was done and who was
not?
>> Is the response along the lines of "Still working to save this out to 3
>> more users" or just "Not done yet, do you want me to continue?"...
>
>I don't understand the above question.

Ok, the sender indicates the RECIPIENTs and then does an ICALDATA.  The
receiver does NOT complete the work in the time specified.  The sender must
either issue a CONTINUE or an ABORT.  It would make the senders decision
easier if it could be told "Completed 7 of 10 RECIPIENTs", etc.  That way
it can tell if the receiver is making any progress.  For example, the next
time into the Idle state returns "Completed 7 of 10 RECIPIENTs" would
indicate either a problem w/#8 and that the sender may want to ABORT
instead of CONTINUE again.

A more complex train of thought would be for the receiver to indicate (on
entering Idle) which addresses it completed and which it didnt (or to
return them w/o waiting for the rest of the data to be bundled up).  Since
we talked about tagging and returning data as it is ready and not bundling
it all (in Minneapolis) this may be a moot issue.

Just be sure you address how the receiver should behave when it is sending
data back and the ICALDATA timer expires (ie: there is lots of data to be
sent and it is still being sent after the 10 second timer expires).
Should the reciever quit sending data back or should it keep streaming it
to the sender until its done?  When this case happens, when should the
senders CONTINUE 15 begin; the time it is received or after the last data
has been sent??  (Multithreaded CSs make this an issue you need to
address!)

>> Is there any way for the sender to find out which RECIPIENTs were
completed
>> and which were not??  For example, I send to 10 RECIPIENTs but for some
>> reason the server can only complete 6 of them.  It would be really
really
>> nice to know who completed successfully and who didnt so I dont have to
>> redo the entire operation and double book something (or so I could
DEQUEUE
>> the entry from those successful ones until it works for all 10!!!)
>
>There is a response for each RECIPIENT.

True but its only sent on the response.  (Prior to Minneapolis) the
response data was bundled so the sender could not see this UNTIL the work
was done or ABORTed.  After the fact is not helpful in deciding whether or
not to CONTINUE...  I look forward to seeing the revised draft on reponse
tagging of streamed data that clears this up.

Bruce