Subject: CAP issues, Sections 1 and 2

From: [email-masked] (Steve Mansour)
Date: Sat, 23 Mar 2002 18:50:20 -0800

Hey All,

Here are some issues I found in reviewing draft 07 sections 1 and 2. Pat
(or a designate) will be keeping track of them and we'll plow through
'em.

Comments

     ABNF for new iCalendar components needs to be presented early
     in the draft, before we use them. We currently make use of
     many components in the draft before they have been defined.

     The diagram that described the mental model for Scheduled
     events versus Booked events on the store was lost, and no
     discussion was present. We need to explain it. Why was it
     removed?

Section 1.3

     "A marked for delete component has its METHOD property set to
     DELETE".  We need to update components to include a METHOD
     property.  METHOD is probably a misnomer for what we're
     doing.  METHOD is an action. We store state and values in
     components.  Something like WORKFLOWSTATE is probably more
     relevant (if not a mouthful).

     We have not stated what properties MUST be maintained for
     DELETEd components.  I think, at a minimum, we need to save
     the UID for everything and the RECURRENCE-ID if it makes
     sense.

     For the definition of Calendar Identifier -- the last sentence
     states "All CaliIDs start with cap:".  Do we really want the
     CalID to indicate the protocol?  Seems like the CSID and
     RelativeCalID would be enough.

Section 2.2

     I cannot figure out how stored queries are going to be useful.
     It seems like some values in every query are going to need to
     be tweeked everytime someone tries to use them.  Most queries
     will include a time range or a specific UID (and
     RECURRENC-ID). The date, time will certainly need to be
     changed for each query over a time range. Same for queries
     that involve a particular UID. These two types of queries seem
     to me to be the ones that a CAP server will need to process
     most of the time. I suppose that since the TARGET can be
     specified outside the query, there will be some queries that
     will not change. But these seem to me to be in th 5 to 10%
     range for all the queries that a CAP server will process.  Are
     stored queries worth it?

Section 2.3

     I recommend we just have a simple transport protocol command
     like <senddata> or <cap> or something like that. The commands
     we list are Application Protocol commands, their names suggest
     more than just a command to move a bundle of data between a
     CUA and a CS.

Section 2.4.2

     This is a big change proposal. Currently the access control
     model is to deny access to anything unless it is explicitly
     granted. Paul Hill has proposed that we change this model to
     grant access to everything unless specifically denied. Paul
     will follow this up with a more detailed poposal, but the gist
     of it is as follows:

        * It will be quicker to process.  With the current model,
          you have to process all the grants and all the denies to
          see whether or not you're left with access to something.
          With the newly proposed model, once you find a VCAR that
          denies access to something, you can stop processing and
          reject access.
        * More storage efficient (I'll let Paul field this one)
        * Usability - Paul can speak to this point better, but the
          idea is that in a model where you have to explicitly
          grant access to things, new VCARs will need to be added
          to grant access to them.
        * Mimicks other systems, for example the Windows 2000 file
          system.
        * may obviate the need for DECREED VCARs (even more).

Section 2.4.2.2

     Why do we need CAR-MIN ?  Is it to support things like CRISP?
     We need to discuss why we need it.

     Are the predefined VCARs in this section meant to be the
     definition of CAR-MIN.  If so, we should explicitly state it.

     For the VCAR with CARID UPDATEPARTSTATUS, I do not understand
     the SCOPE section and the next few lines. If the example is
     correct, then we need and explanation. If it is not correct,
     we need to fix it.

     We may need to rewrite these VCARs if the big change in 2.4.2
     is made.

Section 2.4.2.3

     Can someone explain why we need DECREED VCARs?  Unless there
     is something that we really can't do with VCARs  we should
     just remove this section and the notion of DECREED VCARs.
     Implementations will already have to do an administrative tool
     to put DECREED VCARs on the store. Why not just have them
     write regular old VCARs and secure these VCARs so that no one
     can change them?

     If, for some reason, we need to keep DECREED VCARs then there
     are some misleading things between the second and fourth
     paragraphs. The fourth paragraph states that "The DENY
     property disallows anyone from being able to delete or modify
     this VCAR". But the second paragraph states that users cannot
     modify or override DECREED VCARs.

Section 2.4.3

     I recommend we change the last sentence of the 3rd paragraph
     to read:

          A UPN with a non-null Username and null Realm, such
          as "bob@", could be a security risk and MUST be
          treated as anonymous.

Section 2.5

     Roles are defined in iTIP. We have not added anything. Let's
     remove this section.

Section 2.6

     The capurl syntax provided allows for the following:

          cap:/abcd1234
          cap:

     These just look like a mistakes. I recommend:

          capurl   = scheme ":" "//" csid [ "/" ] [relcalid]

          Examples:

               cap://cal.example.com/             # this
               is a CS
               cap://cal.example.com/asdf12345    # this
               is a VAGENDA (a calendar)

     If we leave in the note about relative calids I think we'll
     have everything covered.

---

From: [email-masked] (Steve Mansour)
Date: Sun, 24 Mar 2002 10:27:19 -0800

slight correction...

>      These just look like a mistakes. I recommend:
     capurl   = scheme ":" "//" csid [[ "/" ] relcalid]

-Steve

---

From: Doug Royer <[email-masked]>
Date: Sun, 24 Mar 2002 13:16:22 -0700

Steve Mansour wrote:

>     property.  METHOD is probably a misnomer for what we're doing. 
>     METHOD is an action. We store state and values in components. 
>     Something like WORKFLOWSTATE is probably more relevant (if not a
>     mouthful).

How about CURRENTSTATE ?

>     We have not stated what properties MUST be maintained for DELETEd
>     components.  I think, at a minimum, we need to save the UID for
>     everything and the RECURRENCE-ID if it makes sense.

I had thought all of the component would be saved until it was
removed. They are cleaned up later out of band to CAP. I don't recall
there ever being a discussion about marked for delete meaning, 'part
of them is removed'.

>     I cannot figure out how stored queries are going to be useful.

	The TARGET is outside the stored QUERY, so just change
	the TARGET value and...

	...
	QUERYNAME:Get all non-booked entries.
	SELECT * FROM VEVENT WHERE METHOD != BOOKED
	SELECT * FROM VTODO WHERE METHOD != BOOKED
	...

	Similar for booked entries.
	Similar for all VCARs that effect me.
	Similar for all OWNED calendars.
	...

>     ...  Are stored queries
>     worth it?

Yes for PDA's and other small devices that just get by
query name.

Also, I don't see any reason that a specific implementation can't have 
non-standard queries for 'get me today's stuff'.

> Section 2.3
> 
>     I recommend we just have a simple transport protocol command like
>     <senddata> or <cap> or something like that. The commands we list are
>     Application Protocol commands, their names suggest more than just a
>     command to move a bundle of data between a CUA and a CS.

I am still in favor of removing all XML from the CAP protocol
and placing everything in VCALENDAR objects.

> Section 2.4.2
> 
>     This is a big change proposal. Currently the access control model is
>     to deny access to anything unless it is explicitly granted. Paul
>     Hill has proposed that we change this model to grant access to
>     everything unless specifically denied. Paul will follow this up with
>     a more detailed poposal, but the gist of it is as follows:

>         * It will be quicker to process.  With the current model, you
>           have to process all the grants and all the denies to see
>           whether or not you're left with access to something.

Or your CS can cache the net result as they are modified. Most CUA's
are not going to change VCARs frequently. And you can 'hide' the cache
or pointer to it in your stored object.

Plus, for EVERY property and parameter I would have to deny
you permission? Else it is public to everyone? Including the right
to change them out from under me? Does not sound secure to me.

> 	    With the
>           newly proposed model, once you find a VCAR that denies access
>           to something, you can stop processing and reject access.

We had been told in the past that that was not a good security model.

>         * Usability - Paul can speak to this point better, but the idea
>           is that in a model where you have to explicitly grant access
>           to things, new VCARs will need to be added to grant access to
>           them.

Why? I grant you the right to see everything marked PUBLIC. Now I
can add as many PUBLIC entries as I want and never change or add
any VCAR.

>         * Mimicks other systems, for example the Windows 2000 file system.

Windows is one of the worst OS when it comes to security. I don't
see this as persuasive.

>         * may obviate the need for DECREED VCARs (even more).

No, DECREED VCARs are administrative VCARs that can not be overridden
by the UPN/CUA. How would it eliminate any administrative VCARs? One of
the requirement from the LA meeting was that the admin gets to
override permissions - thus decreed to a CUA/UPN.

I would agree that the property named DECREED can go away. But
not the concept of 'you can't change it'.

> Section 2.4.2.2
> 
>     Why do we need CAR-MIN ?  Is it to support things like CRISP? We
>     need to discuss why we need it.

The reason is that they include ONLY the pre-defined VCARS for devices
like PDA's that will never be a full service CS. They will only
use predefined VCARs and will never parse QUERY.

>     Are the predefined VCARs in this section meant to be the definition
>     of CAR-MIN.  If so, we should explicitly state it.

It used to say that they were the minimum set required and
in CAP 1.0, it was 'the' set currently defined, and that they
could be extended.

>     For the VCAR with CARID UPDATEPARTSTATUS, I do not understand the
>     SCOPE section and the next few lines. If the example is correct,
>     then we need and explanation. If it is not correct, we need to fix it.
>

It looks correct. It creates non-owner VCAR. And
that VCAR allows them to ONLY update their participation
status in the target calendar (and it grants nothing else).

>     We may need to rewrite these VCARs if the big change in 2.4.2 is made.
> 
> Section 2.4.2.3
> 
>     Can someone explain why we need DECREED VCARs?  Unless there is
>     something that we really can't do with VCARs  we should just remove
>     this section and the notion of DECREED VCARs.  Implementations will
>     already have to do an administrative tool to put DECREED VCARs on
>     the store. Why not just have them write regular old VCARs and secure
>     these VCARs so that no one can change them?

There are predefined VCARs for minimum CS's like PDA's.

And YES there is no reason that a DECREED VCAR can't be
represented by standard VCARs. And they can be dynamic.
For non-owners, anything they can not change is DECREED
to them, so I'll merge their results and just give them
a dynamic VCAR who's CARID will be DECREED and they will
never know that another UPN has access.

I agree that I also don't see the need for a separate property. When
as part of any dynamic (or static) VCAR, they can be denied
permission in that same VCAR to modify it.

So I think we agree that the property 'DECREED' goes away. But
not the idea of admin hard coded VCARS - that used to be what
we called DECREED.

>     If, for some reason, we need to keep DECREED VCARs then there are
>     some misleading things between the second and fourth paragraphs. The
>     fourth paragraph states that "The DENY property disallows anyone
>     from being able to delete or modify this VCAR". But the second
>     paragraph states that users cannot modify or override DECREED VCARs.

I don't see a conflict between those two statements. By definition
DECREED VCARs can not be changed by the CUA.

True. But an administration process out side of CAP can change
and modify them. I agree - there is NO need for a DECREED
property. Just tag the VCAR itself as non-alterable when it
is sent to the CUA.

> Section 2.4.3
> 
>     I recommend we change the last sentence of the 3rd paragraph to read:
> 
>         A UPN with a non-null Username and null Realm, such as "bob@",
>         could be a security risk and MUST be treated as anonymous.

I don't like them ether, but if they can authenticate. So should we not
allow them to then be subject to VCAR restrictions and not call them
anonymous? Perhaps 'bob@' has more restrictions that anonymous once
the VCARs are applied.

> Section 2.5
> 
>     Roles are defined in iTIP. We have not added anything. Let's remove
>     this section.

I agree.

>         capurl   = scheme ":" "//" csid [[ "/" ] relcalid]

And where 'scheme' is 'cap' - yes I agree.

>     If we leave in the note about relative calids I think we'll have
>     everything covered.
> 

Yes.