Re: CAP: Definition of CAR-MIN

[Bernard Desruisseaux <bernard@xxxxxxxxxxx>]

Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > Then, it's my turn to ask:
> >
> >   Explain how a CUA can know if a CS can only handle
> >   the CAP predefined VCARs?
> 
>         (1) The CS advertises CAR-MIN which tells the CUA that
>             the CS can not parse VCARs.

This is not true.  Else, why would CU waste their valuable
time modifying the VCARs with predefined CARID?


>         (2) The CUA looks at 'DEFAULT-VCARS' to determine what
>             VCARs the CS knows, which is going to be at least
>             the predefined CAP VCARs.

DEFAULT-VCARS is not meant to advertize the VCARs the
CS knows, but the VCAR that MUST be copied in newly
created VAGENDA.  That's different.


>         (3) The predefined VCARs can only be queried by CARID.

a) Again, this was never mentioned on the list.

b) This is of no help.  The question was: "how a CUA can know
   if a CS can only handle the CAP predefined VCARs?"

c) Why shouldn't I be able to query the predefined
   VCARs by other properties?  There is no such
   restriction for other components, and there
   are no reasons to handle VCAR differently.


> > > > If the CS wants/needs to support more than the four (4)
> > > > VCARs with predefined CARIDs it simply has to advertize
> > > > itself as a CAR-FULL-1 CS.
> > >
> > > No. Not if the CS can't parse VCARS.
> >
> > Irrelevant.  A CAR-FULL-1 CS could hard code all
> > its VCARs and tag them as "decreed", as long as
> > one of the VCAR denies all users to write, modify
> > and delete VCARs.
> 
> Any CS that can not PARSE VCARs better advertise CAR-MIN.

Why?

> And it better place the VCARs that it knows in DEFAULT-VCARS.

Not necessarily (see above).

> And it better reply to the predefined VCARs by CARID when queried.

Yes.  But not only "by CARID".

> 
> If a CS can PARSE VCARs it can advertise CAR-FULL-1, and
> it is still free to mark them read only (decreed).

Yes, it CAN (i.e., this is not a MUST).

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