Re: (unlimited) The intent/meaning of EXPAND and its usefullness

Doug replied on 12/11/2003 03:28:33 PM:
> See RECUR-LIMIT.

That and STORES-EXPANDED (which is interrelated) but I dont think all 
bases are covered yet.

RECUR-LIMIT is defined as:

   Purpose: This property specifies the maximum number of instances the
   endpoint will expand instances into at query or storage time.
[snip, snip]
   Description: For implementations that have the "STORES-EXPANDED"
   value set to TRUE, then this value specifies the maximum number of
   instances that will be stored and fetched. For all implementations
   this is the maximum number of instances that will be returned when
   the "EXPAND" parameter is specified as TRUE and the results contain a
   infinite or large number of recurring instances.

and STORES-EXPANDED is defined as:

   Purpose: This property specifies if the sending endpoint expands
   recurrence rules prior to storing them into the CS.
[Snip, snip]
   Description: If the value is TRUE then the endpoint expands
   recurrence rules and then stores the results into the CS. If this is
   TRUE then the "RECUR-LIMIT" property is significant because an
   infinitely recurring appointment will be stored no more than
   "RECUR-LIMIT" property values into the CS and all other instances
   will be lost.

The unclear/unspecified bits I find are:

1: RECUR-LIMIT says that its a limit for query results or for storage 
time.  However this latter bit is inaccurate if STORES-EXPANDED is FALSE.  
Both STORES-EXPANDED and RECUR-LIMIT need to have prose in them that 
clearly indicates that RECUR-LIMIT is not used as a storage constraint if 
STORES-EXPANDED is FALSE (there is only text now to the effect o 
STORES-EXPANDED:TRUE).

2: There is no indication of how to indicate "no limit", if we want to 
support that.  There is an example of RECUR-LIMIT:0 in the text however 
this violates the ABNF for RECUR-LIMIT which says its a posint1 which is 
defined as:

    posint1     = posintfirst 1*DIGIT

                  ; A number starting with 1 through 9.
                  ;
    posintfirst = %x31-39

so the example on p112 violates the ABNF or is intended to be "I allow 
infinite expansion".  If we do not want to support "No limit" in CAP, we 
need to add some explicit text to that effect.  If we do want to support 
it, we need to say exactly how we indicate that.

3: There is nothing to indicate how the endpoint can tell the requestor "I 
have expanded to my RECUR-LIMIT and there are other instances that  you 
did not get".   This is important for the CUA to know so it can properly 
inform the CU that what they see is NOT all that should be there.  In 
addition, if there is some way to 'resume' the expansion then that should 
be clearly defined.  For example, if the CS says RECUR-LIMIT:10 and 
STORES-EXPANDED:FALSE then if the CUA asks for EXPAND:TRUE on a 30 
instance repeat set there should be some clearly defined way for the CS to 
expand the 1st 10 (RECUR-LIMIT) instances and tell the requestor "Thats 
all ya get but thats not all I have."  The requestor could then refine the 
query so that they get the next 10 instances (11-20) and the response 
"Thats all ya get but not all I have." And so on until they are able to 
extract all of them from the CS w/o having to do the unwinding themselves.

This gets a little messy unless we clearly state that expansions are 
ALWAYS done in chronological order so that the requestor simply tweaks 
their QUERY to include a "AND DTSTART > "last returned instances"" kind of 
clause.  It may be implicit so far but I would expect the CS to return 
expanded results in chronological order but its not written CAP that it 
has to so its possible the results come back in any arbitrary order making 
this resuming of expansion hard to do.

If we do not provide some means for this we run into some usability 
issues.  A CU could store a RRULE;COUNT=364 repeating component into a 
STORES-EXPANDED:FALSE CS whose has RECUR-LIMIT:100 just fine but they 
would be unable to use EXPAND:TRUE to get the results back out and 
possibly even without EXPAND:TRUE set (see #6 below).

4: When a requestor tries to store something that would violate the 
RECUR-LIMIT of the CS, there is no clear describing what the failure 
results/state should be.  That is, is the entire request (for that 
component) rejected entirely?  Is it processed to RECUR-LIMIT and the rest 
ignored/lost? 

5: Does RECUR-LIMIT apply to manually stored instances or it is a limit 
per component no matter how the instances are stored?  That is, if a CS 
says they have RECUR-LIMIT:5 and I try to create a RRULE;COUNT=6 the CS 
would reject it (subject to #4 above).  However, what if the CUA manually 
rolls out the instances themselves (or they get created over time as the 
CU gets added to more and more instances bit by bit!).  Can my CUA create 
6 separate instances of a particular component without running astray of 
RECUR-LIMIT?  Since the CS is not doing the actual expansion Im not 
certain that STORES-EXPANDED or RECUR-LIMIT would be applicable.  After 
all, if I just ACCEPTed an invitation to a 6th instance of the "Super 
Secret Product Ship Party Planning Committee" then I would NOT expect to 
be rejected with some sort of "You tried to store too many instances of 
this repeating component" failure since form my POV I just accepted a 
single instance and not a bajillion repeats. 

6: It is unclear how RECUR-LIMIT is affected by NOT using EXPAND:TRUE. 
That is, is RECUR-LIMIT used to control the number of returned results 
even if the caller did not request EXPAND:TRUE?  For example, if the CS 
has RECUR-LIMIT:5 and a component repeats semi-weekly (W and F) then would 
a query for all of this months entries fail even if I did NOT use 
EXPAND:TRUE?

Bruce
PS: Note to CAP Editor(s): in RECUR-LIMITs Description, "EXPAND" is a 
property, not a parameter.  Also, may I suggest that the Descriptoin be 
split into 2 paragraphs at the point where it talks about the EXPAND 
property (so each related property is in its own paragraph.)
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...