[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CAP: DEFAULT_VCARS
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:bernard@xxxxxxxxxxx
Research & Development Tel. : +1 514 733-8500 x4213
Steltor Fax : +1 514 733-8878