Subject: Summmary Of January 31st 2002 CAP Editors Conference Call

From: George Babics <[email-masked]>
Date: Tue, 05 Feb 2002 10:10:58 -0500

The summary of what was discussed during last Thursday's CAP Editors
conference call:

- We need to make sure that CAP supports internationalization.
  We believe it does. However, we need to prove it to the area
  directors. We may need to add "Internationalization" section to CAP.

- We need to resolve the issues with synchronization.
  We may need to add a "synchronization" section to explain how a CUA
  can do it.

- George will move the "Editors Notes" from CAP into the CAL issues
  and to do list.

- It seems that there is consensus on the CURRENT_DATETIME issue. 
  Will we close it and adjust the draft.

- Need to try to close all the issues that we seem to have a consensus
  on. 
  
  Other than for minor typos, anything that changes the ABNF
  or text that describes the ABNF will be posted to the list.
  Otherwise, we will post a summary of the changes done after
  reaching consensus. We need to keep a list of what we changed,
  and notify the WG that 'xxx' changed.
 
- Are there any examples missing from CAP? We need to be careful not to
  add too many examples since the document is already quite large and
  we want people to implement the protocol and not the examples.

- We need to resolve the issue of how to handle local changes to components.
  Doug will post something to the list.

- Need to make sure that the capabilities command returns the capabilities of
  the protocol and not the properties of the CS. Furthermore, the properties
  of the CS should not include capabilities of the protocol.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 13:55:02 -0500

>   of the CS should not include capabilities of the protocol.

As far as I know, the <car> capability doesn't return
capabilities of the protocol.  So it should be removed.

Besides, I am not convinced that we need a CAR property
in addition to DEFAULT-VCARS in the CALSTORE.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 13:00:55 -0700

Bernard Desruisseaux wrote:
> 
> George Babics wrote:
> >
> > - Need to make sure that the capabilities command returns the >
> >   capabilities of the protocol and not the properties of the CS.
> >   Furthermore, the properties of the CS should not include
> >   capabilities of the protocol.
> 

Yes it does, it returns supported protocol level of the
CS with respect to VCARs. If a CS returns <car>CAR-MIN</car>,
then the CUA MUST NOT require the CS to be able to parse
VCARs.

> in addition to DEFAULT-VCARS in the CALSTORE.

I did not propose that CAR be a property.
Did you mean the <car> reply to <get-capabilities>?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 16:19:52 -0500

Doug Royer wrote:
> CS with respect to VCARs.

What are you talking about?  CAR-MIN does NOT change the
CAP protocol.

> If a CS returns <car>CAR-MIN</car>,

This is NOT specified anywhere, and on all the occasions
that I've asked this list for the purpose of CAR-MIN, this
was NEVER mentioned.

Furthermore, this doesn't make sense.  If CU are granted
the right to modify the VCARs with predefined CARIDs, the
CS obviously will need to parse and interpret the VCARs.

Finally, the fact that the CS can parse VCAR or not is not
relevant to the protocol or the CUA for that matter.

> I did not propose that CAR be a property.

True.

> Did you mean the <car> reply to <get-capabilities>?

No.  I meant to say that I was not convinced that we
should add a CAR property to CALSTORE, given that we
should remove the <car> capability.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 15:26:54 -0700

> What are you talking about?  CAR-MIN does NOT change the

Yes - I meant:

It returns the protocol level of VCARs supported  by the  CS.
So it changes what protocol commands and data the CUA
sends to the CS. Which does not change the CAP protocol,
but it changes that connections valid protocol 

> that I've asked this list for the purpose of CAR-MIN, this

The only VCAR that a CS knows about are the CAR-MIN
predefined VCARs and any additional in DEFAULT-VCARS, so I guess
you could send the same ones back down from the CUA.
But I don't see the point.

So that implies that you CAN NOT delete ANY DEFAULT-VARS
from the CUA. (without deleting them from DEFAULT-VCARS first).
And CAR-MIN implies that you can not send down NEW VCARs,
because the only ones that exist are already (somehow) in
DEFAULT-VCARS. So it does not change CAP, but it changes
that connections valid commands (the protocol for that
session) and data to that CS.

> CS obviously will need to parse and interpret the VCARs.

Yes - I overstated my point. A CAR-MIN CS MAY not be able
to parse VCARs - if they are all decreed. And a CAR-MIN CS
MUST NOT accept any new VCARs that are not in DEFAULT-VCARS.
And as they MUST exist in the CS if they are in DEFAULT-VCARS,
then that means you can not create new ANY VCARs on a
CAR-MIN CS - using a CUA. It means that they are defined
but the CS is very limited with respect to VCARs.

> relevant to the protocol or the CUA for that matter.

It limits the VCAR related commands that can be sent from the
CUA to MODIFY and QUERY. (subject to even more VCAR restriction).
And if we add the DECREED property (or parameter), then
for a CS that only has DECREED VCARs - it will NEVER need
to parse a VCAR - that is what I badly meant to say.

At the very least - A CA may not fully need to understand
VCARs - if they are not the ones in DEFAULT-VCARS.

> > I did not propose that CAR be a property.
n> True.
> should remove the <car> capability.

I also do not want to add a CAR property to the CALSTORE.
And we should not remove the <car> capability.