[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "ietf-calendar@xxxxxxx" <ietf-calendar@xxxxxxx>
Subject: Re: CAP: CAR-MIN vs CAR-FULL-1
From: Doug Royer <Doug@xxxxxxxxx>
Date: Fri, 01 Feb 2002 12:08:53 -0700
List-archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-id: <ietf-calendar.imc.org>
List-unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Organization: INET-Consulting <http://INET-Consulting.com>
References: <> <> <>
Reply-to: ietf-calendar@xxxxxxx
Sender: owner-ietf-calendar@xxxxxxxxxxxx

Bernard Desruisseaux wrote:
> 
> 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.

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
> of CAR-MIN.

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.

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

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
> might be some additional restrictions in the definition
> of the VCAR to consider as well.

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.

> > > 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)?

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

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

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.

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

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

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

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.

begin:vcard 
n:Royer;Doug
tel;pager:pager@xxxxxxxxx
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:INET-Consulting LLC <http://INET-Consulting.com
adr:;;;;;;
version:2.1
email;internet:Doug@xxxxxxxxx
title:Chief Executive Manager
x-mozilla-cpt:;64
fn:Doug Royer
end:vcard

References:
- CAP: CAR-MIN vs CAR-FULL-1
  - From: Bernard Desruisseaux
- Re: CAP: CAR-MIN vs CAR-FULL-1
  - From: Doug Royer
- Re: CAP: CAR-MIN vs CAR-FULL-1
  - From: Bernard Desruisseaux

Prev by Date: Re: Editors notes in CAP
Next by Date: Re: Initial connection to CAP server?
Previous by thread: Re: CAP: CAR-MIN vs CAR-FULL-1
Next by thread: Initial connection to CAP server?
Index(es):
- Date
- Thread