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

From: [email-masked]
Date: Mon, 4 Nov 2002 13:16:19 -0500

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 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 doesn't 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 talking to 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.  It is 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).  In 
addition, _all_ values returned, including 'default' values which kind of 
makes them non-default but...  This is much like the current role the CS 
has in the 09-b draft.  After all, the way CAP-VERSION is described its 
the "Version of CAP" and has no direct relation to the other values 
returned (or defaulted) in the response.  Those are CS specific 
settings/limits and NOT necessarily particular to the "version of CAP" 
that the CS _speaks_.

I think that #2 is the better path to take since it keeps CAP-VERSION for 
how it is described and it prevents any possible version confusion later 
on.  Im open to other alternatives though...

> 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.  They are the bane of of our collective existance as once 
out there they become a kind of lore and standard by which we have to deal 
with when trying to properly correct something.

Also, each side has to guess at what the other can or cannot do by 
providing 'at will' headers in an attempt to get some course of action to 
happen or not (ie: "Can the server server handle byte range requests?  Let 
me blindly try and see what they send back...").  We overcome this probing 
by having a GET-CAPABILITY response that clearly describes what the 
responding side can do.  We just dont do it in a clean way for going 
forward.

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: [email-masked]
Date: Mon, 4 Nov 2002 13:27:53 -0500

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

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

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

> HTTP version, the server assumes it can only do 1.0 (well, apart from 

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

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Nov 2002 11:55:55 -0700

[email-masked] wrote:

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

FYI - the current model does NOT do that.

The current model says that if the CUA does not send a GET-CAPABILITY
reply - then it the protocol IS CAP-1.0 and the CS must use the defaults
as defined in the spec. There is no point at which they are mixed.

> 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: ...
> 
> Alternative #2: ...

Again CAP-VERSION does not 'SET THE DEFAULTS'. So your premise
to both options lead me to think that they do not apply.

If the CUA sends a GET-CAPABILTY reply, then use those settings.
If the CUA does not send a GET-CAPABILITY reply, the protocol is CAP-1.0
and the CS MUST use the CAP-1.0 defaults.

> I think that #2 is the better path to take since it keeps CAP-VERSION 
> for how it is described and it prevents any possible version confusion 
> later on.  Im open to other alternatives though...
> 
> I hate kludges.  They are the bane of of our collective existance as 
> once out there they become a kind of lore and standard by which we have 
> to deal with when trying to properly correct something.
> 
> providing 'at will' headers in an attempt to get some course of action 
> to happen or not (ie: "Can the server server handle byte range requests? 
>  Let me blindly try and see what they send back...").  We overcome this 
> probing by having a GET-CAPABILITY response that clearly describes what 
> the responding side can do.  We just dont do it in a clean way for going 
> forward.

No 'guessing' required -  it's CAP 1.0 unless specifically specified.

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

---

From: [email-masked]
Date: Tue, 5 Nov 2002 13:48:38 -0500

> as defined in the spec. There is no point at which they are mixed.

I strongly think that we should mandate both CS and CUA MUST implement 
GET-CAPABILITY in CAP 1.0 AND that we do not use any defaults since all 
properties are '1' except experimental ones.

Otherwise CAP 1.0 is NOT just used to detect what version of the protocol 
one side speaks but it also implys default values for several properties. 
Since this can NEVER change in any future rev of CAP I think we should do 
it the right way now.  Is there any good reason not to??

> to both options lead me to think that they do not apply.

Wrong.  CAP 1.0 clearly specifys default values for each property 
including CAP-VERSION.  This effectively "sets the defaults".

So far only Doug seems to think we should keep on using defaults which can 
cause us grief later on.  I just wish I could understand why...

> and the CS MUST use the CAP-1.0 defaults.

So when CAP 2.0 is released there can be no implicit assumption of what 
the CUA is can there since the CS has no way to differentiate 1.0 from 
2.0.  As such all CUAs will have to implement GET-CAPABILITY then or risk 
being restricted to 1.0 functionality levels. 

 Why not do it right from the start and mandate it now??  Doing this right 
now would mean that we no longer have any defaults and life is much better 
for everyone....

> No 'guessing' required -  it's CAP 1.0 unless specifically specified.

A cleaner option: GET-CAPABILITY is required by all sides in CAP 1.0 and 
there wont have to be any guessing or assumptions made or defaults 
implied.

Bruce