Re: CAP 13: Bad CAL-QUERY example / description?

Doug Royer wrote:
> 
> 
>>
>> It may be useful for doing a "find me all properties and subcomponents 
>> that exist in this container" but I strongly doubt that its something 
>> done on a regular basis.  It can be useful for debugging or protoyping 
>> purposes but not for normal CU day to day actions.
> 
> 
> It is used every time I load a calendar from an unknown source. One 
> vendor has
> two modes it uses timezones and both with the same PRODID. Not all 
> properties are in all objects
> even when they are the same type.

This looks like, virtual hosting. I start wondering and thinking of
the need for this. This can be done with the VCALSTORE or the
hostpart in the CALID. I think it is dangerous to use for instance a
timezone in order to choose a different set of features. In the
long-term this is not providing inter-operability, but non
inter-operability.

Maybe it could be wise to make a draft for this (or include it).

> 
> The feature is documented. And works. And even if you do not want to use 
> the feature
> it appears from this conversation that you did understand from  CAP  
> what that
> feature does when called. So it does not fall into the bug, broken, 
> typo, or grammer category.
> And I thought that feature changes were off topic and we were into get 
> CAP done mode.
> 


Understanding the draft well, I believe a GET-CAPABILITY could be used 
for this. Although, modifications are needed. It may also be useful, to
indicate which properties are required by the CS for instance.

An example discovered by trying to synchronize a telephone with a
CAP server (telephone <-SYNCML-> syncserver <-CAP-> CAP server).
The telephone does not support the UID property, but implicitly
expresses it be some other means outside the VEVENT. This is sufficient 
for the communication between the telephone and sync server. While
transfering the VEVENT to the CAP server it refused the new VEVENT
due to the missing UID property.
I have no real way of learning this in the sync server. Asking for
a complete list of supported properties is not the same, since it does
not tell me if it is required.
For this example one can say, "but the UID property is required by
the protocol definition". Yes, I agree, but it is applicable for
other properties.



Harrie