Subject: Re: CAP ABNF and external references

From: [email-masked]
Date: Tue, 21 Jan 2003 14:16:52 -0500

Doug responded on 12/06/2002 07:08:33 PM:
> > Sorry but that text does NOT cover partial results. 
> 
> Please explain 'partial results' and where it is in the draft.

Really?!?  Ok, mathematically stated its:

        partial results = NOT (all the results)

In English its described as 'If you dont get _ALL_ the results then you 
only got _PARTIAL_ results."  (For those nitpickers here I view "NO 
results = ALL results" since there set of results to results is empty.) 

Its not a term you put in the draft (09-submitted or before), its one _I_ 
used in this thread when discussing the issue of Bounded Latency and the 
text cited below.

Previously I responded to you with:

> >      If a CS can both start sending the reply to a command and 
guarantee
> >      that all of the results can be sent from a command (short of
> >      something like network or power falure), prior to the "LATENCY"
> >      timeout value, then the "LETENCY" time has not expired.
> 
> Sorry but that text does NOT cover partial results.  It clearly says
> "guarantee that _all_ of the results" (my emphasis) and that is 
> definitely NOT partial results!  Perhaps you are thinking that "all 
> results" simply indicate that its a partial result and that another try 
is necessary??..  (Please say no... Please!) 

Your (double quoted above) text does NOT address the case where the CS 
cannot "guarantee that all of the results" can be sent in time.  The CS 
may or may not be able to tell if it can send all 10M in 5 seconds or not 
(I have lots of calendar entries!) even though it was able to find all 10M 
in the blink of an eye.

Taking a step back to try and clarify this, I see 2 distinct cases that 
seem to be blurred into 1 in the draft.  Case 1 is that the CS cannot 
fulfill the request in the alloted time (too much data to sort thru, 
exceeds CS policy contstraints, etc).  Case 2 is that the CS can fulfill 
the request in the alloted time but it cannot push the results back fast 
enough (ie: Cant shove a 10M ATTACHment and related entry thru a 500K 
Cable Modem in 10 seconds).

For Case 1 failure should be presented as "The system needs more time to 
find the results you want".  For Case 2 failure should be presented as 
"The system is pushing back the data as fast as it can but it will not 
complete by the time you want." 

I view Case 1 as the real bounded latency issue.  I think Case 2 is 
getting lumped in incorrectly (by the cited text "guarantee that all of 
the results...").  I do not think that Case 2 is grounds for failing the 
request. 

If the CS is in the process of pushing back the data and the latency time 
is exceeded then WHAT should happen?  The CUA has received some of the 
results from the CS (my "partial results" you asked about) but not all of 
them.  Should the command be terminated and if so, by whom?  If not, what 
means does the requesting side have for cancelling the stream?

If the command is to ABORT then just how should we expect the CUA to "pick 
up where it left off" with the command?  Or should it just retry the 
entire command again but with larger LATENCY values?  SHOULD/MUST the CS 
send back a failure response of some kind to indicate 'I am unable to 
fully process your request in time, please try a large LATENCY.' or 'Data 
processing is complete but I cannot return all the data in the requested 
LATENCY time.'.

The behaviour for when the CS _cannot_ guarantee that all the results "can 
be sent...prior to the LATENCY timeout value" is just not clearly defined 
and it really needs to be.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...