Re: CAP: CAR-MIN vs CAR-FULL-1

[Bernard Desruisseaux <bernard@xxxxxxxxxxx>]

Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > The latest interim version of the draft still does
> > not provide sufficient information about the level
> > of CAR support CAR-MIN and CAR-FULL-1.
> >
> > I would like to propose some text that could be
> > included in the draft, but I'm missing some key
> > information.
> >
> > 1- What is the purpose of CAR-MIN?
> >
> >    a) Make CS vendors' life easier (i.e., not forced
> >       to provide full CAR support)?
> >
> >       It seems that to implement CAR-MIN a vendor will
> >       have to implement CAR-FULL-1 and then add a
> >       restriction on the value of CARID.  Why would a
> >       vendor restrict his implementation to CAR-MIN?
> >       Unless I'm missing something it's not easier to
> >       support CAR-MIN than CAR-FULL-1.
> 
> No. If a CS does not understand 'VCAR' but does hard code
> the predefined CARID's then it is CAR-MIN. The example
> used was a palm pilot. It in effect is a mini-CS, and may
> never implement CAR-FULL-1. Same with an IP cell phone.

But we don't need different level of CAR support for that
purpose.  The CS will need to deny all users the right to
write and modify VCARs in a hard coded decreed VCAR anyway.
The CS could return the capability CAR-FULL-1 and that
wouldn't make any difference.

I don't mean to bug you, but I still don't see the purpose
of CAR-MIN.


> >    b) Make CUA vendors' life easier (i.e., can query
> >       specific predefined VCARs by CARID to figure out
> >       easily if they are granted the right to perform a
> >       command or not)?  Wouldn't this ability be lost
> >       when the CS supports CAR-FULL-1?
> 
> Lost - no.
> 
> A CUA can just ask 'can I  post a METHOD:REQUEST' to this CS.
> And NEVER implement CARs in the CUA.

Well it would still need to implement CAR to be able to
parse the returned VCAR with CARID:REQUESTONLY.  Simply
looking at the GRANT property won't be enough as there
might be some additional restrictions in the definition
of the VCAR to consider as well.


> No it is not lost because the other end of the connection
> may be CAR-MIN only so a CS MUST always understand and
> compute them.
> 
> A CUA that supports CAR-FUL-1 can ask for REQUESTONLY and still
> support CAR-FUL-1.

Yes.

> > 2- What are the limitations implied by CAR-MIN?
> >
> >    a) VAGENDA can only contains VCARs with predefined
> >       CARIDs (e.g., CARID:REQUESTONLY)?
> 
> In a CS - yes - if a CS only supports CAR-MIN, then
> that is all it has and it will not process any VCARs sent it.

Do you mean that CAR-MIN implies that I won't be able to
modify my own VCAR (e.g., CARDID:REQUESTONLY)?

Again, it seems that a decreed VCAR would do the job.


> They could conceivably be decreed and not changeable in the CS.
> (it SHOULD still store them)
> 
> If in a CUA - that is all they will ever ask for and will ignore
> any sent to it (it SHOULD still store them).
> 
> For a CS that supports CAR-FUL-1, when asked for any
> of the CAR-MIN CARID's, it MUST compute the answer and
> provide the results to the CUA.

What you are saying is that the CUA doesn't need to care
whether the CS supports CAR-MIN or CAR-FULL-1?  It can
always query the predefined CARID regardless of the CAR
support.


> >    b) VAGENDA can only contains VCAR with a CARID
> >       value listed in the property DEFAULT_VCARS
> >       of the CALSTORE.
> 
> No - CAR-MIN (and its text needs to be added back into CAP),
> means the pre-defined CAR-MIN VCARs as defined in CAP
> and that *at least* those are in DEFAULT_VCARS.

I'm pretty sure we're on the same page, but just to make sure:

CS MUST implement the VCARs with the predefined CARIDs.
CAP doesn't impose any restriction on the definition of
these VCARs.  It simply suggests definitions for them.
The CARID are predefined.  Not the content of these VCARs.
Correct?

> CAR-MIN in a CS is a MUST. It MAY support CAR-FULL-1
> and those extra VCARs MAY be in DEFAULT_VCARS.

Yes.


> > 3- With CAR-MIN, could a user have multiple VCARs
> >    with the same predefined CARID (e.g., 2 VCARs
> >    with CARID:DEFAULTOWNER)?
> 
> Not in the same scope (calendar).

Okay.

 
> > 4- When a CU is searching for a predefined CARID
> >    (e.g., CARID:REQUESTONLY) is the CS supposed:
> >
> >    a) to look at all the VCARs (including the decreed
> >       VCARs) regardless of their CARID and returned a
> >       coalesced VCARs that contains information pertinent
> >       to the definition of that CARID only?
> 
> Yes - that is one of the primary reasons they were invented.
> 
> >  Does anybody
> >       looked at how this could be implemented?
> 
> The same as COLESED=TRUE and a QUERY were done with those
> restrictions on the query.

I understand how the CUA will request coalesced VCARs.
It's just not clear to me yet, what the CS will need
to do to return coalesced VCARs.

> 
> >    b) to look at all the VCARs with the specified CARID
> >       and return a coalesced VCAR?
> 
> No, when asking for a CAR-MIN VCAR, it means look at everything
> and return the COLESED result that applies as specified in
> CAP (again text needs to be re-added).
> 
> > 5- Are there any restrictions on the rights that can
> >    be granted or denied in VCARs with predefined CARIDs?
> >    For instance, could I grant all users the right to
> >    read all my VEVENTs in the VCAR with CARID:REQUESTONLY?
> 
> When the text goes (back) into CAP, it will be clear that REQUESTONLY
> only applies to the desire to know if you can deposit a METHOD:REQUEST
> into the TARGET calendar.
> 
> > 6- Does CAR-MIN impose restrictions on decreed VCARs?
> 
> No - they can be decreed, they might not be decreed.

How will I know if they are decreed or not?   Clearly,
specifying "decreed" in the CARID is not an option here.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:bernard@xxxxxxxxxxx
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878