Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt

From: [email-masked]
Date: Tue, 15 Apr 2003 11:23:12 -0400

[Tried to send this before but it seems to evaporate and not get sent. 
Pardon me if its a duplicate. -BK]

Andrea replied on 10/30/2002 10:55:41 AM:
> Uhm... now I'm curious... How exactly do you design forward 
> compatibility in a protocol if you don't assume that "if a party 
> doesn't specify a later revision, we must assume it only supports an 
> earlier, known revision"? Note that I said _the default_.

(I dont see 'default' in your question but Ill insert it accordingly) 
Actually to solve this you do NOT allow for defaulting of some values 
based on another AND still mandate a '1' instance in the ABNF.  That is 
you do not allow, say, COMPONENTS to just default to 
"VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if 
CAP-VERSION:1.0 is and the property MUST be sent anyway.  That approach is 
kind of mixed up.  The current approach is half in one camp, half in 
another and doesnt serve either well.

If we intend CAP-VERSION to be used to detect defaults then it SHOULD be 
acceptable to allow the default to be used in both directions.  That is, a 
CS should be able to send just CAP-VERSION:1.0 if it implements all the 
defaults defined by CAP 1.0.  The CS should only send a non-default value 
if it does not support the defaults.  For example, no RRULE support would 
be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports 
RRULEs then NO RECUR-ACCEPTED need be sent.  Put another way: If 
'defaults' have to be expressly sent then what good are they??

Two options come to mind.  Using CAP-VERSION and default values one 
sidedly is poor design because its both verbose and superfluous as well as 
an accident waiting to happen.   I see 2 possible choices to correct this:

Alternative #1: We should either use CAP-VERSION to _always_ imply 
defaults and only send non-default indicators.  For cases where 
CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA and a CAP 2.0 CS) then there 
needs to be some way to request the full list (defaults included!) from 
either side.  This should only be necessary for the case of the 'older' 
side since 'newer' implementations should have no problem keeping track of 
the 'older' settings since they've already been published so are 
pre-existing and can easily be stored in some internal table.

Alternative #2: We do not rely on CAP-VERISON to do setting 
defaulting/detection; it is merely informational or used to detect if both 
sides are able to properly communicate.  Its used strictly for protocol 
compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a 
CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS).  All 
values that can be returned are returned, including default values.  This 
is much like the current role the CS has in the 09-b draft.  After all, 
CAP-VERSION is described as "Version of CAP" but we are using it as a 
settings default controler instead of as the means by which two different 
versions of a protocol can detect if they are compatible or not.

Im kind of partial to Alternative #2 but there may be other alternatives I 
have not considered.  Im open to other suggestions...

> Coincidentally, that's how HTTP works - if a client doesn't specify an 
> HTTP version, the server assumes it can only do 1.0 (well, apart from 
> kludges).

I hate kludges especially in a protocol.  They become the bane of our 
collective existance and something that hinder rather than help when a 
proper solution is sought. 

In HTTP there is no convenient way for one side to accurately tell what 
abilities the other has w/o doing some 'blind probing" (ie: "Can the 
server return byte ranges for this URL?  Ill ask for it but I may or may 
not get back just what I want...").  This is why we have explicit 
properties to be returned on the GET-CAPABILITY command, even with 
'default' values; no need to guess or infer. 

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