Subject: CAP: WHAT MISSING TEXT ON VCAR??? (Was: Re: CAP: CAR-MIN vs CAR-FULL-1)

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 01 Feb 2002 11:12:22 -0500

Doug Royer wrote:
> 
> No - CAR-MIN (and its text needs to be added back into CAP),

> ... 

> CAP (again text needs to be re-added).

> ...

> When the text goes (back) into CAP

Doug, AFAIK, everything that was submitted to the list on
VCAR is already in the latest interim version of the draft.

See : http://www.calsch.org/ietf/drafts.html

Can you please acknowledge that?  Or else, send the missing
text ASAP.

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 01 Feb 2002 11:57:57 -0500

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Feb 2002 09:49:44 -0700

> Can you please acknowledge that?  Or else, send the missing

I was looking a verion 06 and not looking at version 06 :-)

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Feb 2002 12:08:53 -0700

> wouldn't make any difference.

So, the CUA would ask for one of the predefined VCARs and
get a hard coded answer. The CS will NEVER need to understand
any VCAR details. It can hard code the answer to the
predefined VCARs in its ROM.

A CS that has only the capability of CAR-MIN, is telling
the CUA - I will ONLY reply to a VQUERY for the predefined
VCARs. Any other VQUERY on a VCAR will result in an error.
So do not put a QUERY in the VQUERY, other than by CARID.

> I don't mean to bug you, but I still don't see the purpose

So the CS can ONLY implement the predefined VCARs and NOT
allow any other. The Palm Pilot "is" a mini-CS and it IS NOT
going to implement CAR-FULL-1.

> parse the returned VCAR with CARID:REQUESTONLY.

The CUA would, but not the CS. The CS can just return
a hard coded (maybe decreed) value if it wants.

If the CUA can not parse CAR-FULL-1, it is not going to ask for them.
If the CUA can not parse ANY VCAR, it is not going to ask for any.

But if the CUA DOES understand VCARs, it can ask a CAR-MIN
CS for any VCAR defined in DEFAULT_VCARS, and get an answer.

> Simply looking at the GRANT property won't be enough as there

The purpose of the predefined VCARs is spelled out in CAP.
NO OTHER results should be returned. If the CUA can not parse
the results - it should not ask for any results.

CAR-MIN is the capability of the CS, not the CUA. The CUA
will never ask for what it can not handle. But the CUA
needs to know what the CS can handle.

> modify my own VCAR (e.g., CARDID:REQUESTONLY)?

If a CS says it is CAR-MIN, then the ONLY VQUERY you can
do on it is by CARID.

	BEGIN:VQUERY
	QUERY:SELECT <list> from <target> WHERE CARID = <known>
	END:VQUERY

And <known> MUST be in DEFAULT_VCARS.

We do not have a CAR-MIN VCAR that tells a CUA if it can
modify any VCAR or not on a CAR-MIN CS. So there is no
way to ask a CAR-MIN CS that question.

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

Decreed means 'hard coded and not changeable by the CUA'.
It does not mean that it is predefined in CAP.

So you could change any NON-decreed VCARs in a CAR-MIN CS.
(Assuming one of the decreed or nondecreed VCARs allows it.)

> whether the CS supports CAR-MIN or CAR-FULL-1?

Yes - If is all it wants to know is the DEFAULT-VCARS.
Which the CS MUST include at least the predefined CARID VCARs.
In this way ANY CUA that understands VCARs can do the
minimum CARID queries.

If a CUA wants to know more - it MUST talk to a CAR-FULL-1 CUA.

If a CUA asks a CAR-MIN CS for more than what is provided
in the DEFAULT-VCARS - the CAR-MIN CS will return an error
because it can not process them.

> It can always query the predefined CARID regardless of the CAR
> support.

Yes.

> to do to return coalesced VCARs.

I'll be happy to sell you a license for my code in a
few months :-)

> specifying "decreed" in the CARID is not an option here.

Why? If a CUA asks for UPDATEPARTSTATUS VCAR and gets back
(assume we go with the decreed parameter):

	...
	CARID;decreed=true:UPDATEPARTSTAUS
	GRANT...
	...

There is NO way to ask a CAR-MIN CS if you can update
your VCARs anyway.