Re: The intent/meaning of EXPAND and its usefullness

There is (was?) a big vendor that always converted any recurring 
instances upon receipt to
an unspecified number of RDATEs. They removed the RRULE and EXRULE 
properties
then stored the object.

There is (was?) another big vendor that always expanded repeating 
instances to
single instances on the way out to an unspecified maximum number of 
instances.

There were some vendors that did NOT support RRULE or EXRULE, they would
only except RDATE.

We had discussions and no big vendor would budge at all, so we just set 
flags.
The RECUR-ACCEPTED, RECUR-LIMIT, and RECUR-EXPAND capability
replies were added so the CUA could be able to ask the CS (and CS ask 
the CUA).

As iTIP has fallback and errors to those same problems that pre-date 
CAP, we did
not feel that CAP should address those iTIP issues, just allow the 
endpoints to determine
that the problem existed prior to transferring data.

The only way to solve this problem is in iTIP-next, mandate some kind of 
minimum
or overlapping sets of rules.

I do not think CAP created this problem, I think it is an iTIP issue 
that CAP
allows you to find.

-- 

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

               We Do Standards - You Need Standards