Subject: Re: CAP: DEFAULT_VCARS

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Dec 2001 15:49:57 -0500

Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > Doug Royer wrote:
> > >
> > > Bernard Desruisseaux wrote:
> > >
> > > >
> > > > Sorry.  My question should have been:
> > > >
> > > >    Do we need "default VCARs for newly created top level
> > > >    calendars" given that we have VCAR inheritance?
> > > >
> > > > That is, a newly created top level calendar automatically inherits
> > > > the VCARs directly contained under CALSTORE.  The default VCARs
> > > > could simply be all the VCARs directly contained under CALSTORE.
> > > >
> > > > I don't understand why we would need to copy the default VCARs
> > > > in every top level calendar.
> > >
> > > I was getting these confused:
> > >
> > >         11.1 Calendar Store Properties / DEFAULT_VCAR
> > >         11.2 Calendar Properties / DEFAULT_VCAR
> > >
> > > I agree, 11.2 DEFAULT_VCARS is not needed.
> >
> > Why do you think 11.1 DEFAULT_VCARS is needed?
> >
> > The list of DEFAULT_VCARS is simply the list of
> > all the VCARs directly contained under the
> > CALSTORE.
> 
> No, it is a list of the defined CARIDs at the CS level.
> Not all VCARs at the CS level need to be named with a CARID.
> 
> > There is no need to define this one
> > as well.  It can be obtained with a simple VQUERY.
> 
> It lists any predefined VCARS that exist by CARID.
> 
> It allowed small devices to determine which 'predefined' VCARs
> the CS knows, that the small CUA understands. So the small CUA
> can just query for what it wants and does not have to do a full
> VQUERY of what might be a large set of VCARs - then sort them.
> REQUESTONLY is by definition limited to what the authenticated
> entity can do, so the small CUA does not have to care about anything
> other than understanding that what comes back applied to the current
> authenticated entity.

Sorry Doug, but I think I'm missing some basic information here!

Why would a CUA (small or thick) want to get the list of
predefined CARIDs?  What is it going to do with this list?

My understanding is that DEFAULT_VCAR would only be useful
(used?) by the CS to duplicate the predefined VCAR in newly
created VAGENDAs (which I questioned the usefulness given
that we have inheritance).

> 
> A small CUA can say: 'I know the function of CARID:REQUESTONLY', but
> I don't care about the rest of them.

How can a CUA not care about certain VCARs?  Doesn't all VCARs
for which the user's UPN match applies to the user regarless
of their CARID?

How can a CUA claim to "know the function of" a VCAR based on
its CARID?   Can't a user change the definition of the predefined
VCARs at will, that is, to the extent where CARID:DEFAULTOWNER
would not even apply to UPN=OWNER?

If I want to deny you the right to create new event invitations
in my calendar, am I forced to specify that RIGHTS (i.e., DENY)
in the VCAR with CARID:REQUESTONLY?

What is the purpose of predefined CARID?  Is it related to CAR-MIN
versus CAR-FULL-1?

Currently, according to the specification, VCAR support restricted
to CAR-MIN doesn't imply that only the predefined CARID are
supported by the CS.  If on the contrary it implies it, it should
be written in the draft.

> 
> There was a lot of resistance to not having predefined CARID's by
> function VQUERYable by name. So then the debate went to, how
> do I find out which predefined CARIDs does the CS support? The
> answer was to add DEFAULT_VCAR at the CS level. Then we agreed
> that any predefined 'access' MUST BE identifiable by a VCAR.
> Then others asked - 'how can we expand this list in the future?'.
> Then others asked what about any current VCAR with a CARID at the
> CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS
> that had a CARID. In that way any CARID in DEFAULT_VCAR might
> be a predefined CARID, and it no long matters to the CUA, it simply
> gets a list, some of which may be predefined in an RFC.

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: Fri, 21 Dec 2001 13:15:13 -0700

> predefined CARIDs?  What is it going to do with this list?

Know what is suppored.

> that we have inheritance).

And for the CUA to know which (by name) they are.

> for which the user's UPN match applies to the user regarless

If I can't update my REQUESTONLY values - I won't try as
I am a stupid CUA and don't understand (fully) VCARS.

> would not even apply to UPN=OWNER?

Becase CAP defines that REQUESTONLY VCAR retruns ONLY the VCARS
that apply to that need.

> in the VCAR with CARID:REQUESTONLY?

The default is DENY, you don't have to do anyting to deny me.

> What is the purpose of predefined CARID?

See previous post (in fact in the text you quoted from be below).

> Is it related to CAR-MIN versus CAR-FULL-1?
>

It should  - that is why they were added - good catch.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 24 Dec 2001 11:06:25 -0500

> And for the CUA to know which (by name) they are.

But the CUA wouldn't have a clue about the semantic of the
predefined CARID that weren't part of the CAP specs.  As
soon the DEFAULT_VCAR would contain a CARID that was not
part of the CAP specs, the CUA wouldn't be able to assume
anything.

> Becase CAP defines that REQUESTONLY VCAR retruns ONLY the VCARS

Do you mean that the CS would need to interpret all the VCARs
and return all the RIGHTS value type that would seem to apply
to REQUESTONLY when the user is searching on CARID:REQUESTONLY?
As far as I know, this is not defined in the CAP draft.

Are users allowed to create, or modify, VCARs with predefined
CARIDs, or does the predefined CARID can only be used with the
search command to get a computed VCAR?

> The default is DENY, you don't have to do anyting to deny me.

That's beside the point.  What if I granted the right to
everybody and I wanted to deny you the right, or for whatever
reason I wanted to explicitly deny you access.  So again,
can't I setup my VCAR the way I want regardless of their CARID?

> See previous post (in fact in the text you quoted from be below).

Your previous post (still quoted below) only gives details
about what has been done to accomodate predefined CARIDs,
it doesn't say why they were introduced, or what is their
purpose for that matter.

> It should  - that is why they were added - good catch.

Then if my CS implementation has the capability CAR-FULL-1
all this CAR-MIN stuff becomes irrelevant.  Right?

Does a CS that advertised additional CARID in DEFAULT_VCAR
needs to show the capability CAR-FULL-1?

Do we want to keep CAR-MIN since they are a dead-end?
Serious CS implementations will most likely implement
CAR-FULL-1 and make logic built in CUA around CAR-MIN
a waste of time, or so it seems given all the information
that I have about VCAR.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Dec 2001 10:09:32 -0700

> part of the CAP specs, the CUA wouldn't be able to assume

A CUA can ask for the predefined (by access, queryable by name)
VCAR's. So, the idea was that any CUA could find out
IF it could do a REQUEST on the calendar. So the contents of
the results of a VQUERY for REQUESTONLY might not be what the
original setup was (for the original REQUESTONLY VCAR). The results
of a VQUERY for a REQUESTONLY is the accumulated results of all of the
VCARs - limited to telling the calling CUA just that information.
By having these, a CUA does not have to parse ALL of the VCARs
just to find out if it can do a METHOD:REQUEST. (same for the
other named VCARS). The same for any predefined VCAR.

> to REQUESTONLY when the user is searching on CARID:REQUESTONLY?

Yes. And the results can be simplified in many cases to this:

	GRANT:UPN=<self>; ....

  or

	DENY:UPN=<self>;....

> As far as I know, this is not defined in the CAP draft.

It may be badly written. The idea was that a CUA can ask
if it can do a named thing without having to understand and
parse all of the VCARs. The list came from the Dallas TX face
to face meeting (results were posted - a few years ago).

> search command to get a computed VCAR?

The results is the same. If a user updates any VCAR (including 
a named VCAR) the net results are a logical AND of the GRANTs.

> can't I setup my VCAR the way I want regardless of their CARID?

Yes. If the following sequence of VCARs were sent:

	BEGIN:VCAR
	CARID:REQUESTONLY
	GRAN:UPN=*;OBJECT=*, ...
	END:VCAR

Then later:

	BEGIN:VCAR
	DENY:UPN=[email-masked];OBJECT=*;....
	END:VCAR

Now my CUA can just VQUERY for REQUESTONLY and get:

	BEGIN:VCAR
	CARID:REQUESTONLY
	DENY:UPN=[email-masked];...
	END:VCAR

> all this CAR-MIN stuff becomes irrelevant.  Right?

No.  You MUST support at least CAR-MIN.

> needs to show the capability CAR-FULL-1?

A CUA MUST support:

	(1) CAR-MIN
   or
	(2) CAR-MIN + CAR-FULL-1

You can have other named (CARID) VCARs. If you advertise
CAR-MIN, then no one will know to ask except the CUAs that
put them in.

If you advertise CAR-FULL-1, then you have to support
everything.

> Do we want to keep CAR-MIN since they are a dead-end?

They are not dead end. They are not static. They are how a CUA
can find it can do common operations on a calendar without having
to VQUERY for all VCARs and then parse and process all of them.

> a waste of time, or so it seems given all the information

I would agree that the CAP draft needs to be updated to correctly
describe CAR-MIN vs CAR-FULL-1.

A serious CS implementation would have to implement both. I see
the CAR-MIN set as a the most common set of requests from a 
foreign (not the owner) CUA with respect to VCARs. The list
of CAR-MIN pre-defined VCARs is also open to debate. More of them? :-)

-Doug