Subject: STORES-EXPANDED

From: Andrea Campi <[email-masked]>
Date: Thu, 16 Jan 2003 01:21:31 +0100

Hi all,

maybe I'm just being dense, but I still don't get the meaning and the intended
use of STORES-EXPANDED and RECUR-EXPAND:

      STORES-EXPANDED
                        1     If TRUE then it expands multiple instances
                              separately when they are stored (RRULEs
                              converted to RDATEs) and when sent. If
                              FALSE then it expands instances dynamically
                              during sending. Default is FALSE.

From the description, it seems as either way, "it" (the CS probably)
must expand multiple "instances" - either when storing them or when sending
them. But what if "it" is the CUA? Or, what if the CS doesn't want to expand?

Also, queryprop lacks expand.

I think we need to clarify the whole concept. Is this table right?

if EXPAND=FALSE then the CS sends recurrences as-is - but
	if the CS has STORES-EXPANDED=TRUE - the server sends expanded
recurrences, since it already expanded them
if EXPAND=TRUE:
	if the CS has RECUR-EXPAND=TRUE - what? give an error?
	if the CS has STORES-EXPANDED=TRUE - the server sends expanded
recurrences, it already expanded them
	if the CS has STORES-EXPANDED=FALSE - the server expands
recurrences and sends them

Somehow this all sounds complicated and not terribly useful...

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: Doug Royer <[email-masked]>
Date: Thu, 16 Jan 2003 09:52:10 -0700

> Also, queryprop lacks expand.

Not all of the vendors had the same model. Rather then decide
on who would have to change (and they said they would not),
we ignored the differences and decided to appease everyone
by documenting the differences.

One major vendor stores the object AFTER expanding the instances.
If you give them an RRULE with 10 instances, they store 10 objects.
EACH with the RRULE removed and replaced with an RDATE. And they
also silently truncated the number of instances to an unspecified
number. So we added the RECUR-LIMIT so the CUA would know if
they had a limit.

Similar with the CUA's.

The reality is that not all CUA's are going to be able to
expand instances and not all CS's are going to expand instances.
Not all CUAs can handle recurrence rules (I do not know
of any CS's that can not).

The capability properties are so that each endpoint can
tell what the other end can and can not do.

 > Also, queryprop lacks expand.

Added -thanks.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Andrea Campi <[email-masked]>
Date: Fri, 17 Jan 2003 11:23:09 +0100

> by documenting the differences.
[...]
> tell what the other end can and can not do.

That's all fine and good, but then I think we need to change:

      STORES-EXPANDED

to:

      STORES-EXPANDED
                        1     If TRUE then it expands multiple instances
                              separately when they are stored (RRULEs
                              converted to RDATEs) and when sent. If
                              FALSE then it stores instances as they are.
			      Default is FALSE.

Also, reading this:

      RECUR-EXPAND      1     Whether or not it supports the expansion
                              of recurrence rules. TRUE (default) or FALSE.

If a CS has

	STORES-EXPANDED:FALSE
	RECUR-EXPAND:TRUE

am I right in assuming it means that it will only expand recurrences
if explicitely asked to, via the EXPAND parameter?

Also, in both cases, we might need to clarify whether `it' refers
to a CS only, or how would that apply to a CUA. While for instance
RECUR-ACCEPTED is meaningful for a CUA as well, I don't see how
STORES-EXPANDED would apply (a CUA doesn't really store, and the
CS wouldn't care anyway). So I'd change STORES-EXPANDED and RECUR-EXPAND
to read `the CS' instead of `it', and note they only apply to CS.

Bye,
	Andrea

---

From: [email-masked]
Date: Wed, 22 Jan 2003 16:10:44 -0500

Andrea responded on 01/17/2003 05:23:09 AM:
>                                                 I don't see how
> CS wouldn't care anyway). 

The information is also necessary if building CS <-> CS synchronization or 
replication.  Thats NOT in CAP 1.0 (too hard) but its not a CUA / CS thing 
but more of a Sender / Receiver thing.  In that frame of reference it 
should make more sense.

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...

---

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 10:31:32 +0100

> but more of a Sender / Receiver thing.  In that frame of reference it 

Good point, but I was simply point out that the language vagueness
(the use of 'it' in the description) wasn't helping understand the
exact meaning of STORES-EXPANDED. More to the point, my proposal
would still be good in your scenario:

      STORES-EXPANDED
                        1     If TRUE then the CS expands multiple instances
                              separately when they are stored (RRULEs
                              converted to RDATEs) and when sent. If
                              FALSE then it stores instances as the are.
                              Default is FALSE.

I will admit this is very minor, but could help understand the
intended use of STORES-EXPANDED.

Bye,
	Andrea

---

From: [email-masked]
Date: Fri, 24 Jan 2003 13:12:42 -0500

>                         1     If TRUE then the CS expands multiple 
instances

Sorry I wasnt clearer in my response.  The use of CS in the explaination 
is misleading as it implys a CUA<->CS scenario.  I was weakly suggesting 
that there is a CS<->CS scenario that will eventually be involved.  As 
such any direct uses of terms like "CS" in the description should be 
avoided.  The term "Recipient" or whatever the response sending side 
should be called is more appropriate.  That way a CUA can send it to a CS 
as well...

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Mon, 27 Jan 2003 14:08:11 +0100

> such any direct uses of terms like "CS" in the description should be 

What about `a CS' - so it is valid even if both parties are CS. Or
what about making it explicitly a CS only property.

> should be called is more appropriate.  That way a CUA can send it to a CS 

That's exactly my question: what would it mean in that case? As far
as I can tell, this property really means: when the party receives
a component with recurrences, does it expand them immediately,
store them and send them out expanded?
If so, is there any case in which a CUA will behave like that
(internal processing for its own purpose doesn't count obviously)?

Bye,
	Andrea

---

From: [email-masked]
Date: Wed, 29 Jan 2003 13:23:39 -0500

> what about making it explicitly a CS only property.

Since GET-CAPABILITY is (or will be) required to be supported by both 
sides of the CAP session, its not correct to use "the CS" in the text.  It 
could be 2 CS's doing sync/replication (or a CS doing the dreaded CAP 
Fanout where the CS acts as a CUA).  As such BOTH sides are actually CS's; 
one side is not always going to be an actual CUA.  Hence my suggestion to 
change "the CS" to "the sender" in the description.  This should apply to 
ALL properties returned by the GET-CAPABILITY command.

> That's exactly my question: what would it mean in that case? 

For a CUA<-CS connection this property may not be that useful.  Its more 
useful in the CUA->CS case or the CS<->CS case (where sync/replication 
come into play).  Is there any reason that the CS would need to know if 
the CUA stores data a particular way if the CS isnt going to ask the CUA 
for data?  In CAP 1.0, probably not.  When we get into CUA<->CS 
sync/replication (not CS<->CS) then the answer is yes (but thats at least 
a rev of CAP away)...

My point is simply that we should not use terms like "the CS" in 
describing properties so that we implictly make the property CUA<-CS since 
we will eventually have to deal with a CS<->CS scenario where there is no 
CUA or for CUA->CS when we look at sync/replication.  Our current prose is 
heavily focused on a CUA<->CS model and it may become ambiguous when we 
extend CAP.

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Thu, 30 Jan 2003 10:23:09 +0100

> ALL properties returned by the GET-CAPABILITY command.

Well, a CS is still a CS even if both parties are CS's ;-) In addition, in
a CS<->CS synx situation we might have no way of knowing which one is the
sender, if they are doing bidirectional replication they might be both
senders and receivers at the same time.

> come into play).  Is there any reason that the CS would need to know if 

My point really.

> sync/replication (not CS<->CS) then the answer is yes (but thats at least 

I'm not sure I follow you wrt CUA<->CS sync/replication; do you
mean something like a CUA which downloads one or more VAGENDAS, allows
you to work disconnected, then syncs back to the CS when you
reconnect? If so, yes I think I see your point.

Bye,
	Andrea

---

From: [email-masked]
Date: Thu, 30 Jan 2003 15:18:51 -0500

Andrea replied on 01/30/2003 04:23:09 AM:
> Well, a CS is still a CS even if both parties are CS's ;-) 

So both sides should return STORES-EXPANDED properties in their 
GET-CAPABILITYs response packet then... :^b

>                                                            In addition, 
in
> senders and receivers at the same time.

When I referred to sender/reciever I was referring to the role in the 
sense of the GET-CAPABILITY command.  That is, CS1 is the sender when it 
sends the GET-CAPABILITY to CS2 (which is the receiver then).  When CS2 
turns around and sends a GET-CAPABILITY command then its the 'sender' and 
CS1 is the 'receiver'.  In both cases a STORES-EXPANDED property should be 
sent.

> > come into play).  Is there any reason that the CS would need to know 
if 

I did not say it was useless.  There is such a concept as "server push" 
where the CS initiates the connection/action to the CUA (using our terms 
instead of Client/Server really).  Examples could be a company who 
wants/needs to push updates down to the desktop such as company wide 
events, site specific events, work assignments from centralized call 
systems (ie: assigning TODOs from a central site in a timely manner), etc.

Since the CS is going to push data to the CUA it may need to know the CUAs 
capabilities so it can properly poll back later for status changes, etc. 
("What is the status of VTODO with UID:Customer1.Job32?", "We have more 
details about the assigned task to push down to the CUA so we need to know 
to send it." etc).

Pardon me now while I go and code this up for IBM... %^}

> reconnect? If so, yes I think I see your point.

So you can see where a CUA could send that info then to the CS.  Thus it 
is not just a "the CS" property...   All properties returned by 
GET-CAPABILITY should be generically described and not tied to "the CS" or 
"the CUA".  Thats all Ive been trying to get across...

Bruce