Subject: Re: Proposed removal of hierarchy from CAP

From: [email-masked]
Date: Thu, 27 Dec 2001 11:57:53 -0500

Doug replied on 12/22/2001 12:43:27 PM:

> How about:
> 
>  We could do away with VCAR inheritance and keep the 
>  calendar hierarchical structure as is. 

2 tidbits here:

1: Hierarchical calendars are currently defined for VCAR inheritance and 
NOT content inheritance (Section 1.3):

The hierarchical calendar feature is not a storage relationship of the calendars within the CS. Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. The 
hierarchical relationship of a calendar is specified in the "PARENT" and 
"CHILDREN" calendar properties.  (Emphasis is mine)

2: This feature was created originally to make some vendor(s) more 
amenable to developing CAP due to how they intended to build it (ie: using 
folders w/inherited ACLs).  Content was NOT included in the 'roll up' 
because not all existing systems have that archictectural concept and 
there are LOTS of issues w/content rollup that we collectively did not 
want to try and bite off for the first pass.  However this has long since 
become moot given the changes in participation in the WG.

Since hierarchical calendars are only for VCARs really, I see removing 
them a worthwhile design simplification given the benefits and the cost of 
doing so.  (Of course I may regret those words in a couple years but hey, 
its the holidays here so Im blissfully numb about it now.)

>  A calendar simply contains ALL of its own VCARs.

A wise choice...

>  Implementations would sill be free to implement the storage
>  of VCARs the same as long as the net result was that it appeared
>  to all calendars as if they contain their own VCARs?

CAP does not mandate HOW you internally build your CS but this VCAR 
hierarchy is a bit much IMHO.  I think that hierarchical VCARs is some 
baggage we need to jetison to make the design simpler and to aleviate some 
of the issues that Steve mentioned.  Removing it makes the CS's job easier 
when doing rights checking and other operations.  Keeping it adds 
complexity that I dont think most users will really use/need.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Dec 2001 11:03:00 -0700

[email-masked] wrote:
> 1: Hierarchical calendars are currently defined for VCAR inheritance
> and NOT content inheritance (Section 1.3):
> 
> The hierarchical calendar feature is not a storage relationship of the
> calendars within the CS.

It is (at least logically).

        CAL-A
          |
    ...-------------------------...
       |                |
    CAL-A.1         CAL-A.2
                        |
                  ---------------
                  |              |
                CAL-A.2.1       CAL-A.2.2

> Instead it is a feature that relates access
> control rights to calendar content between different calendars in the
> CS. The hierarchical relationship of a calendar is specified in the
> "PARENT" and "CHILDREN" calendar properties.  (Emphasis is mine)

No PARENT / CHILDREN have nothing to do with the VCAR model.

> amenable to developing CAP due to how they intended to build it (ie:
> using folders w/inherited ACLs).

No it was not. Calendar hierarchy was proposed (by me) in Dallas.
VCARS (then VACL) were proposed by Frank and I later in Orlando. In
Dallas we deferred ACLs because no one had a proposal and we
agreed that even if ACLs did not make it into CAP, we needed
calendar hierarchy.

>  Content was NOT included in the
> 'roll up' because not all existing systems have that archictectural
> concept and there are LOTS of issues w/content rollup that we
> collectively did not want to try and bite off for the first pass.
>  However this has long since become moot given the changes in
> participation in the WG.

Yes - roll up was deferred at about the Dallas time.
It was deferred because it was too complex at that time
to debate without specific proposals (I do not think
we have ever had any roll up proposed in any detail).

> Since hierarchical calendars are only for VCARs really, 

No they are not. The debate in Dallas had to do with having
hierarchical calendar so people could organize separate 
and unrelated or somewhat related events without cluttering
their published accessible calendar. So that ISPs could give their
customers one top level calendar, and access to sub-calendars for
their social events or for their organizations and control
the content. The debate included a youth baseball league, such
that:

                    CAL:Baseball-Leage-A
                            |
             -------------------------------------......
                 |                          |
	CAL:Team-A schedule            CAL:Team-B schedule     ...

So that organizations (or persons) could have a hierarchy
of calendars that represented their organization. So that
people familiar with that organization could find a schedule
for only the particular part of the target organization.

> I see removing
> them a worthwhile design simplification given the benefits and the
> cost of doing so.  (Of course I may regret those words in a couple
> years but hey, its the holidays here so Im blissfully numb about it
> now.)

I see removing VCAR inheritance as falling into that category.
But I see calendar hierarchy as unrelated to that issue.

> baggage we need to jetison to make the design simpler and to aleviate
> some of the issues that Steve mentioned.  Removing it makes the CS's
> job easier when doing rights checking and other operations.  Keeping
> it adds complexity that I dont think most users will really use/need.

Removing VCAR inheritance - yes.

Removing calendar hierarchy - no. If you don't want to do it,
simply place an immutable decreed VCAR in your CS that does not
allow child calendars to be created:

		BEGIN:VCAR
		DENY:UPN=*; .... OBJECT=CREATE ... \
                    OBJECT=VAGENDA ...\
                    OBJECT=CHILDREN .... \
		...
		END:VCALEN

Paul (I think) in Montreal proposed immutable decreed VCARS so
that system administrators or implementations could place them
into a calendar or CS to allow for site policy and vertical
market implementations. If you don't want child calendars,
don't allow them. With VCAR inheritance removed, they
really are no more complex that any other calendar, just two
properties more - PARENT and CHILDREN.

I personally never liked VCAR inheritance. I hope it goes away.

---

From: [email-masked] (Steve Mansour)
Date: Thu, 27 Dec 2001 10:27:54 -0800

[email-masked] wrote:

> calendars within the CS. Instead it is a feature that relates access

This is true.  The names of calids do not reflect their hierarchy.  And
CAP has never dictated how storage is to be implemented.  The issues all
revolve around VCAR inheritance.

> using folders w/inherited ACLs).  Content was NOT included in the

hmm... we should include it or exclude it because it's the right
technical decision, not because of anyone's participation.

> it adds complexity that I dont think most users will really use/need.

having calendars be self-contained in terms of access control will
definitely make things simpler.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Dec 2001 12:34:54 -0700

Steve Mansour wrote:
> > The hierarchical calendar feature is not a storage relationship of
> > the calendars within the CS. Instead it is a feature that relates
> > access control rights to calendar content between different
> > calendars in the CS. The hierarchical relationship of a calendar is
> > specified in the "PARENT" and "CHILDREN" calendar properties.
> > (Emphasis is mine)
> 
> This is true.  The names of calids do not reflect their hierarchy.
> And CAP has never dictated how storage is to be implemented.  The
> issues all revolve around VCAR inheritance.

The "MOVE" issues all revolve around VCAR inheritance, not
hierarchical calendars - correct?

However there is NO requirement that calids reflect their hierarchy
(as I recall Steve - you are the one that most insisted on that), but
this is not a requirement - correct?
 As in; "they MAY reflect calendarr
hierarchical relationships"? Correct? As I recall this was also
a Dallas meeting result where some wanted it to be a MUST, and
everyone else said it should be a MAY. At the same time we
agreed that there would NOT be a predefined hierarchical separator.
(Some wanted it to be a '/' and others a '\'). We agreed that
implementations and sites could use any (or no) separator.

We also agreed that a CUA MUST NOT assume that any calid is or is
not a calendar or sub-calendar by looking at the calid - The CUA MUST
look at the PARENT and CHILDREN properties. That is NOT the same
as as saying that a CS, site, or implementation must not have calids
that are hierarchical as viewed by a user:

	baseball-league-calendar/team-a

        baseball-league-calendar/team-b

 Are valid calids, as is:

	fjjjdfjles09u0ufjdsoipuf
   and
	9kmesdsf09dsa9032jfdp

  The last two could in fact be calids in another implementation
  if it did not want to export the hierarchy that exists.

  And the first two are valid calids and a user could understand
  the hierarchy by looking and guessing at the calids for; sites,
  calendars, or implementations, that wished the hierarchy to
  be viewable and understandable to a user (not the CUA).

CS implementations were free to use what ever they wanted
as a calid. Correct?

> > hierarchy is a bit much IMHO.  I think that hierarchical VCARs is
> > some baggage we need to jetison to make the design simpler and to
> > aleviate some of the issues that Steve mentioned.  Removing it makes
> > the CS's job easier when doing rights checking and other
> > operations.  Keeping it adds complexity that I dont think most users
> > will really use/need.
>

---

From: [email-masked] (Steve Mansour)
Date: Thu, 27 Dec 2001 15:01:12 -0800

> hierarchical calendars - correct?

Right.

> this is not a requirement - correct?

I was a proponent of this, yes.  However, I was not one of the ones who
insisted on it.  I believe that was Andre's hot button :-). Nonetheless, I
think it is a wise move to not have the calid reflect the hierarchy or
anything else. It is simply an identifier which should not be overloaded.

> implementations and sites could use any (or no) separator.

there are no separaters - the calid is an opaque unique identifier

> CS implementations were free to use what ever they wanted

yes. All that you have written above jibes with my understanding.

The simplification we seek revolves around access conrol and what it means.

If we specify all access control for a calendar is self-contained (no
inheritance from the calendar hierarchy) then most of the issues just go
away.  Bruce, do you have any issues with keeping hierarchy with the proviso
that we make it clear that access control and hierarchy are disjoint and
unrelated?

How does this affect decreed vcars?

-Steve