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

From: [email-masked]
Date: Wed, 23 Oct 2002 16:21:44 -0400

Doug replied:
> As to the text below, I think you are correct. The CS MUST send
> the GET-CAPABILITY, and a CUA MAY return not-implemented.
[Snip]
> > However, I was under the impression that what we had agree on was more
> > like (look for the ***):
> > 
> >    A CUA MUST send a "GET-CAPABILITY" command to a CS after the 
initial
> >    connection.  The "GET-CAPABILITY" command MUST BE implemented by 
all
> >    CSs.
> > 
> >    The CS ***MUST*** send a "GET-CAPABILITY" command to any CUA.  The 
"GET-
> >    CAPABILITY" command ***MUST*** be implemented by a CUA.  If the CUA 
does not
> >    support the "GET-CAPABILITY" commmand then the CUA must return a 
not
> >    implemented reply.

I agree w/Andrea on this one. 

Given we are starting out fresh with CAP I think that the implementing 
GET-CAPABILITY is a MUST for both sides.  Im less adament on the CS MUST 
send it but its a very very good idea to.  Even if your CS doesnt support 
ATTACHments (or other heavier stuff), its still a very good idea to always 
do a GET-CAPABILITY before doing any real work.

I cant think of any reason why a CUA would not be reasonably able to 
implement a GET-CAPABILITY handler so why shouldnt this be a MUST also?... 
 After all any 'lightweight' CUA that doesnt do much can very easily code 
up a simple handler that sends back "I only support plain VEVENTs and 
nothing more" in only a few lines of code.  Its probably the 1st routine 
to get coded as folks build their CUA so why not make it MUST??

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: Andrea Campi <[email-masked]>
Date: Wed, 23 Oct 2002 23:32:08 +0200

On Wednesday, October 23, 2002, at 10:21 PM, 
[email-masked] wrote:

> [...]
> implement a GET-CAPABILITY handler so why shouldnt this be a MUST 
> also?...  After all any 'lightweight' CUA that doesnt do much can very 
> easily code up a simple handler that sends back "I only support plain 
> VEVENTs and nothing more" in only a few lines of code.  Its probably 
> the 1st routine to get coded as folks build their CUA so why not make 
> it MUST??

Now wait a minute ;-) In fact I like the wording in the latest document 
(CUA MAY reply not implemented).

I already gave an example for why a CUA would want to have NO handler 
at all: a CGI interface to show a read only view of a specific calendar 
(think user group meeting schedule) could be written in a few hundreds 
lines of code, and would hopefully be quite fast. I agree a 
GET-CAPABILITY handler wouldn't add much; but if it has no need to, why 
force it to have this unneeded fat??

Bye,
	Andrea

---

From: [email-masked]
Date: Mon, 28 Oct 2002 14:45:38 -0500

> force it to have this unneeded fat??

I guess it depends on who the main target(s) for CAP are if this is a 
strong enough example to say that the CUA SHOULD should support a 
GET-CAPABILITY handler or not. 

I for one think that even if you are a servlet/portlet writer that its 
still useful for the CS to know what your script driven CUA can do.  I 
also think that the more predominant use for CAP is the C/S environment 
where a CUA application is used (ala POP3/IMAP).  As such MUST is best 
suited over SHOULD or MAY (MAY is _not_ a good choice!!)

I would prefer to use some hindsight from our iCalendar / iTIP / iMIP work 
and put a firm stake in the CAP spec that says BOTH sides MUST support 
GET-CAPABILITY so that either side can reasonably expect to have info 
about the others capabilities.

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Tue, 29 Oct 2002 10:02:34 +0100

> still useful for the CS to know what your script driven CUA can do.  I 

As long as the default is clearly defined, I think the CS knows what the CUA
can do even if the CUA doesn't implement GET-CAPABILITY - it means the CUA has
no problem with the defaults.

> about the others capabilities.

Anyway, I can see your point of view, and it's not that big an issue for me,
so I'll go with the majority.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Tue, 29 Oct 2002 14:57:02 -0500

> no problem with the defaults.

As long as no new defaults get added (or none change!) then thats true. 

If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a 
loss to accurately tell if the non-supportive CUA really supports some 
defaults or not since it cannot safely guess what version of CAP the CUA 
scriptlet is using.  After all, the CAP-VERSION is part of the 
GET-CAPABILITY and w/o it the CS has no definitive way to know what 
version of CAP the CUA speaks if it wont expreslly say so. 

OR

If we for whatever reason change the default CAP-VERSION value to be 
something different than 1.0 then when your scriplet connects to the newer 
CS the CS will mistakenly assume the non-responding CUA is, say, 2.0 
instead of 1.0 and may make some incorrect decisions.

Anyone else w/opinions either way??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Oct 2002 13:58:34 -0700

[email-masked] wrote:
> scriptlet is using.

Not true, the default for the capability "CAP-VERSION" is "1.0".
If the CUA supports something newer - then it better know how
to respont to GET-CAPABILITY else in CAP 1.newer, we would have
to invent something like GET-CAPABILITY2 (yuck).

>  After all, the CAP-VERSION is part of the 

We do expreslly say so - if the CUA does not support a GET-CAPABIBILITY
reply - the CS assumes the defaults - CAP 1.0.

> something different than 1.0 then when your scriplet connects to the 
> newer CS the CS will mistakenly assume the non-responding CUA is, say, 
> 2.0 instead of 1.0 and may make some incorrect decisions.

How - the default is "1.0" not "whatever",

> Bruce Kahn                                INet: [email-masked]

-- 
-
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: Andrea Campi <[email-masked]>
Date: Wed, 30 Oct 2002 09:31:51 +0100

Hi Bruce,

> version of CAP the CUA speaks if it wont expreslly say so. 

As Doug said, the default would be 1.0 forever, so there would be
no ambiguity even with a future CAP revision.

That said, I agree with you that, as soon as a new revision is out,
a CUA would be stuck with a choice of either staying at CAp-VERSION
1.0, or implementing GET-CAPABILITY.
This alone is a reason for me to retire my idea, and thanks for making
me see the light ;-)

Bye,
	Andrea

---

From: [email-masked]
Date: Wed, 30 Oct 2002 10:28:41 -0500

> no ambiguity even with a future CAP revision.

Wow!  A key decision making value that NEVER changes in any version of the 
protocol.  That sounds very useful...

> This alone is a reason for me to retire my idea, and thanks for making

Oh, were it so easy to make others see the light...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
For those who are humor-challenged, my responses above were (and still 
are) sarcasm and tongue-in-cheek respectively

---

From: [email-masked]
Date: Wed, 30 Oct 2002 10:52:23 -0500

> to invent something like GET-CAPABILITY2 (yuck).

The default for _this_release_ of CAP is "1.0" but it may change for some 
unforseen reason in the future when a new version of CAP is released.

Its not a change in the CUA that Im worried about; its a change in the CS 
instead.  If we rev CAP to a newer CAP-VERSION and some vendor actually 
implemented it then the CUA could detect this by the CAP-VERSION:2.0 value 
that it gets back (because all CS's MUST support GET-CAPABILITY).  However 
the newer, spiffier CS has NO way to properly detect what CAP version the 
CUA is running since the CUA wont say.  The current spec is that the CS 
"MUST assume the CUA supports the default values" in CAP-VERSION:1.0 and 
that ALL 1.0 defaults apply to the CUA when taking any actions later on.  
This is great if both sides are both 1.0, not so great if they are not. 

It is not possible/safe to make assumptions about defaults when there is 
the potential that the defaults may be different, say between "1.0" and 
"2.0".  We are not omniscient (at least Im not, just ask my wife) so there 
is the potential that we may change them for some very valid reasons in 
the future.  This could lead to inteorp failure and a very nasty headache 
for CAP 2.0 designers.

One possiblity is that we just 'fix' CAP-VERSION at "1.0" forever (ala 
MIME-Version).  Nice concept if you have an extensible framework to build 
on but we do not.  Also, in MIME there is no assumption about default 
values for any header or types, etc.  We have defaulting of values in CAP. 
 That is another reason why we cannot just fix CAP-VERSION; if we did then 
what purpose does CAP-VERSION really serve?

The only way to solve this issue is to make the CUAs ALWAYS respond to 
GET-CAPABILITY.  Otherwise the CA must _always_ assume CAP-VERSION 1.0 in 
all future instances of the protocol and any newer CUAs MUST expressly 
send back a CAP-VERSION:2.0.  This negates the original intent to make it 
'faster' by not having to code a GET-CAPABILITY handler originally.

> reply - the CS assumes the defaults - CAP 1.0.

So for any future version of CAP this will always hold true?  If thats the 
case then any 2.0 CUA MUST support GET-CAPABILITY or be treated by the CS 
as a 1.0 CUA instead of a newer 2.0 CUA.  This is the negation of the 
original desire to make the CUA faster by not coding a GET-CAPABILITY 
handler up.

Wouln't it just be simpler to say that a CUA MUST respond to the 
GET-CAPABILITY command and have NO defaulting and mistaken assumptions 
made?

> How - the default is "1.0" not "whatever",

So you're saying that for this and all future versions of CAP the default 
will (MUST) always be "Assume 1.0 if the CUA does not respond to 
GET-CAPAIBLITY."  Correct?

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Wed, 30 Oct 2002 16:55:41 +0100

On Wednesday, October 30, 2002, at 04:28 PM, 
[email-masked] wrote:

> Wow!  A key decision making value that NEVER changes in any version of 
> the protocol.  That sounds very useful...

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

Bye,
	Andrea