[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an idea as an alternative to stored queries





Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:


Doug replied on 11/28/2003 03:20:58 PM: > Ether the CUA knew what XXX > did or not. Ether you were allowed (by VCAR like any other > component) to modify it, remove it, add one, or not.

You neglect to take into account that a CU may use different CUAs and each may have their own expectation of what XXX does depending on who coded them (or if XXX was changed by a different CUA or other means).


Your declaration of what I take into account is false.

As such, just because CUA-1 'knows' that XXX performs a particular action does not mean it will always be so and unless CUA-1 can retrieve and confirm this by existing means then a change by CUA-2 may different behaviour for the same CU depending on what CUA they are using. For example, your PDA may have one expecation while your desktop CUA may have another. This is not goodness.

So if CUAs are coded to rely on things they cannot retrieve and look at using CAP such as unencodable in CAP actions or queries then this expecation that the CUA 'knows' what XXX does is fundamentally flawed and bad.


If you put XXX into your calendar:
don't tweak it if it will break you or your CUAs.
If you do not want other to be able tweak XXX, put in a VCAR to stop them.


If you did not put XXX into your calendar
    don't tweak it if you do not know what it does.
    If it has a decreed VCAR, you can't tweak it anyway.
    If you do not like it, and you have permission, delete it.

This is NO different than any other component. If you tweak a VEVENT
and add a RRULE, and your other CUA can not handle RRULE's, it is not
the protocols fault and has no moral (bad) implications.

--

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                              |   Cell: (208)520-4044

We Do Standards - You Need Standards


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature