Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION

From: [email-masked]
Date: Mon, 4 Nov 2002 13:58:39 -0500

Doug wrote on 10/30/2002 11:49:10 AM:
> > Question 1:
> > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what 
are 
> > the default values to be used by the CS when it supports multiple 
> > versions of CAP?  The 1.0?  2.0?  Some mix (assuming they are not 
> > mutually exclusive)?
> 
>   The default value as specified in the draft is "1.0". If an
>   implementation supported several version, then it would not
>   be the default, it would be 1.0;2.0

Poorly phrased on my part.  The defaults for the other properties returned 
(ie: CAR-LEVEL, COMPONENTS, etc) are all for CAP 1.0 so what would a CS 
getting a CAP-VERSION:1.0;2.0 response back from a CUA be able to deduce 
about the non-returned 'default' values??  Would they be the 1.0 default 
values?  Some unknown 2.0 values?  Some mix?

Deduction by overloading the CAP-VERSION is NOT good or sufficient in this 
case.  This is why ALL properties MUST be returned by both sides, even 
'default' values.  They no longer are 'default' values since they are 
expressly specified though...  A new designation would be in order or we 
just omit it and say that all properties must have a value and 'value of 
XYZ means its not supported'.  "Down with defaults!"...

> > Question 2:
> > Just what should a CUA or CS do when they detect a CAP-VERSION value 
> > that is above/below what they can deal with?  For example, my CUA is 
> > CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should 
happen 
> > when they try to work together?  We never expressly codify what should 

> > happen in this case.
> 
>   It says '[It] must include at lest "1.0"..."
> 
>   So do you think it is valid to send only "2.0;2.0"?

Its perfectly valid for a CAP 2.0 CS to send back that if it only speaks 
CAP 2.0 and does not want to deal with any CAP 1.0 issues.  Thats exactly 
why we have minver and maxver.

Still, this answer is less important the #1 above...  If we no longer have 
defaulting of values then this becomes almost moot...

> > Question 3:
> > (Assumption: We finally realize that blind assumption about default 
> > values for unknown clients is bad and correct this in the draft so 
that 
> > both sides MUST support GET-CAPABILITY)
> > What good are defaults if both sides are mandated to send back a 
> > response to GET-CAPABLITY?
> 
>    Your logic is failing :-) There has been no such agreement.

Thats why I made the clear statement of assumption.  We can come back to 
this once we get to that point... :^)

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: Doug Royer <[email-masked]>
Date: Mon, 04 Nov 2002 13:30:54 -0700

[email-masked] wrote:
> Poorly phrased on my part.  The defaults for the other properties 
> returned (ie: CAR-LEVEL, COMPONENTS, etc) are all for CAP 1.0 so what 
> would a CS getting a CAP-VERSION:1.0;2.0 response back from a CUA be 
> able to deduce about the non-returned 'default' values??  Would they be 
> the 1.0 default values?  Some unknown 2.0 values?  Some mix?

Again poorly phrased - If the CUA were to return the values,
then the default are not used - as the values returned would
be used.

The defaults are used when the CUA does not respond
to a GET-CAPABILITY reply.

-- 
-
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:55:45 -0500

> then the default are not used - as the values returned would

Then I'd say its poorly designed. 

There has been no, repeat _NO_ good reason to date as to why the CUA 
should not be mandated to support GET-CAPABILITY in CAP 1.0 and we do away 
with default value.  Perhaps if you can provide one then I could mull over 
why you so firmly love it but until then I just see the potential in any 
future release of CAP to have no end of confusion.

Which is simpler and less error prone:

1: Imply some default values based on a different value (and therefore ALL 
of the implied values MUST be true and valid!!)  OR
2: Expressly declare all supported values and not infer or deduce them.

Bruce