Subject: Re: Proposed removal of hierarchy from CAP

From: [email-masked]
Date: Fri, 28 Dec 2001 11:15:03 -0500

Doug wrote on 12/27/2001 06:40:58 PM:
> Wrong - Frank, Steve and I talked Lisa and Tony into hierarchical
> calendars in Dallas prior to that they were fighting them.

The history lesson debate is becoming a distraction from our apparent 
partial agreement.  Ill just leave it with this final bit.  I wasnt in 
Dallas so I cannot talk about who said what there but my full text indexed 
archive of this WG and my mail file bear out that Lisa was a proponent of 
hierarhical calendars for ACL reasons (for previously mentioned underlying 
shared folder implementation reasons).  Those really interested can search 
the available archives for any future reading.

> I don't know who added the definition of hierarchical calendars
> being a product of VCARs to CAP - but it must have been
> that editors views or understanding. That text should have
> never been in CAP.

The current text on hierarchical calendars was put there expressly to preclude content roll up 
(or roll down as some have suggested!).  Thats why its there.  (Frank can 
confirm this if hes still lurking.) It may or may not have predated the 
decision to make CalID opaque and thus non-hierarchical inherently.

> > I cannot clearly pinpoint the time when we chose to drop the concept
> > of content roll up but I vaguely recall it happening at some meeting
> > where lots of vigorous debate and hand waiving occurred.
> 
> It was prior to cap requirements being *accepted*. It may have been
> mentioned, but there was never any specific proposal.

It was not mentioned (or my full text index of the WG archives back to 
1996 is busted big time).

> > > ...
> > >
> > > 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).
> > 
> > Ok, Ill buy the Dallas time frame.
> > 
> > In any case, the current design for roll up is strictly for VCARs and
> > it is causing some CAP complexities that I think can be resolved by
> > simply removing the current hierarchy as Steve has mentioned.
> >  Benefits of removing seem to outweigh the problems they cause.
> >  That's my sentiments and I'm sticking to 'em...
> 
> There is NO current design for roll up - none at all that
> was dropped years ago. I am not sure I understand your point.

Bad phrasing on my part.  I was not intending "content" roll up but rather 
VCAR roll up (in order to generate an effective rights list for a given 
CU, the CS has to 'roll up' all the VCARs from the given CALID and 
'higher' into a composite list to be used for access checking. 

The point is that hierarhical VCARs is a CS maintenance pain to say the 
least and makes CAP life (and usage) harder rather than easier.  Removing 
this from CAP simplifies our design and removes the issues that Steve 
originally posted.

> If you meant drop VCAR inheritance - Steve did not propose that,
> he proposed that all child calendars go away. (Did I misunderstand
> him?)

I think that Id go as far as saying that since we have no hierarchical roll up (or down) of content and by removing the concept of hierarchical calendars for VCARs only then we no longer really need to 
have hierarchical calendars.  The term becomes a misnomer and is misleading. 

I could see some proposal to have 'linkages' between calendars but that 
text is yet to be written.  Ill continue this concept in the other part of 
this thread.

> > I can buy that concept but it does not cover all kinds of
> > 'relationships' between all calendars.  The use of a
> > "League/Division/Team" kind of hierarchy example is logical for that
> > kind of organization but it does not work for the "Husband/Wife" or
> > "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar
> > is the "parent" really.
> 
> I agree. It does not cover all kinds of relationships. I do not
> think they were ever designed to cover all kinds of relationships.

See thoughts on this in the other part of this thread (going out after 
this). 

> > However I still think that removing hierarchy for VCARs is a very
> > worthwhile change.
> 
> I agree. But Steve's proposal was to remove the ability to have
> child ALL calendars. Steve did NOT propose removing VCAR inheritance
> directly. He said by removing hierarchical calendars -[Snip, snip]
>                                                And of course, VCAR
> inheritance would go away as a side effect as there would be
> no child calendars to inherit anything.

Its not a side effect if you remove the concept (as currently defined) of Hierarchical Calendars; its a design simplification.  (Hierarchy only 
exists now for VCARs, NOT for any other reason like organizing or cross 
linking calendars)

> I would agree that it is how VCARs are defined. And I would
> again propose (and I think maybe we are violently agreeing),
> that VCAR inheritance goes away.

Id say its Violent Partial Agreement.  (I dont think we agree 100% on 
keeping the concept of hierarchical or 'linked' calendars).  Now all we need is John Strack to jump in and we can have more violent 
partial agreement... ;^)

> > Also, your use of hierarchy is contrary to the definition of
> > hierarchical calendar (see the original definition I cited) so perhaps
> > you should propose some change text to include this design (above and
> > beyond "access rights")
> 
> That's what we are debating?
> Removing this from 1.3 / Hierarchical Calendars and
> tweaking the words:
> 
> Remove:
>      ... Instead it is a
>       feature that relates access control rights to calendar content
>       between different calendars in the CS. 

Not quite.  Id say the proposal on the table is to remove all concept of "hierarchical calendars" entirely.  By just removing that line you open the 
door to someone making some improper assumptions about content roll up (or 
down).  That would be a step backwards, not forwards...

> > Sounds like all we need to do is redefine Hierarchical Calendars to
> > remove access rights inheritance and to describe linkages a bit better
> > then. 
> 
> Yes - I agree.

Agreement is a great thing.  Ill try to touch base w/Doug OOB and see if 
we can work up some kind of text to redefine his concept of hierarchical calendars (or my 'linked' calendars) and propose it to the 
WG.  This will remove any mental baggage associated w/the term "hierarchical calendar" so we dont rehash this again in another 10-12 
months.

> > I'm not sure that only adding PARENT/CHILD is the right choice.
> 
> It is already there - nothing to add?

The point being that its insufficient for all the kinds of 
linkages/relationships that two CalIDs can have. My calendar is not a 
PARENT to or a CHILD of my wifes but they are 'related'.  "Hierarchical calendars" w/in a CS may be a cute 1st start but it doesnt 
allow for your League/Division/Team hiearchy of "separate but related" 
calendars (which is really what they are despite the tree layout used).

> > (How would I link to my peer calendars in my team or to the CAP
> > Editors calendars using PARENT/CHILD only?)
> 
> No one has proposed any other linkage (other than CHILD/PARENT)
>  - do you have a proposal :-)

Lets talk and maybe I/we can propose one.

> I had proposed years ago (in no detail) that a child calendar coul
> be a pseudo link to another calendar in order to propose exactly
> what you wanted. 

Hmm, a full text scan of all postings for "child" and "Doug" (or other 
permutations) reveal no postings in my archive.  Not sure if I never got 
'em or if they were in OOB emails.  Still, its another good reason for us 
to talk...

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: Fri, 28 Dec 2001 14:05:05 -0700

[email-masked] wrote:

> The current text on hierarchical calendars was put there expressly to
> preclude content roll up (or roll down as some have suggested!).
>  Thats why its there.  (Frank can confirm this if hes still lurking.)
> It may or may not have predated the decision to make CalID opaque and
> thus non-hierarchical inherently.

Okay - it failed :-) 
An implementation can still do that and be compliant.

I don't recall the WG saying no to content roll up. Just no
to doing in in CAP 1.0.

> Bad phrasing on my part.  I was not intending "content" roll up but
> rather VCAR roll up (in order to generate an effective rights list for
> a given CU, the CS has to 'roll up' all the VCARs from the given CALID
> and 'higher' into a composite list to be used for access checking.
> 
> The point is that hierarhical VCARs is a CS maintenance pain to say
> the least and makes CAP life (and usage) harder rather than easier.
>  Removing this from CAP simplifies our design and removes the issues
> that Steve originally posted.

:-) !!!

> Its not a side effect if you remove the concept (as currently defined)
> of Hierarchical Calendars; its a design simplification.

Same difference?

> 
> Not quite.  Id say the proposal on the table is to remove all concept
> of "hierarchical calendars" entirely.  By just removing that line you
> open the door to someone making some improper assumptions about
> content roll up (or down).  That would be a step backwards, not
> forwards...

Okay now I am confused. Do you want:

	Inherited vcars?		I say NO.

	Child calendars?		I say YES.

And if an implementation wanted to do content roll up, how 
would that break you? I could do content roll up now and you
would never know - would you? You just do a VQUERY on a calendar,
and no point in time do you ask; "Is some of this really from a child
calendar that I don't have access to?" - Nope..

> PARENT to or a CHILD of my wifes but they are 'related'.
>  "Hierarchical calendars" w/in a CS may be a cute 1st start but it
> doesnt allow for your League/Division/Team hiearchy of "separate but
> related" calendars (which is really what they are despite the tree
> layout used).

Yes - does this need to be part of CAP now? Or can we start
with child / parent in CAP 1.0 and work from there? Then do a more
complete relationship draft later by advertising a new capability?

> permutations) reveal no postings in my archive.  Not sure if I never
> got 'em or if they were in OOB emails.  Still, its another good reason
> for us to talk...

My idea (part of fanout and roll up at the time) was that CS's
could talk to each other in a transparent way by brokering the
authentication for the CUA. (NOT storing the credentials) In that
way it did not matter where or which CS contained the TARGET calendar.
It only required the CUA to set up a link at some previous time. Such
that when I ask to see Doug/Football the football calendar could in
fact be the NFL schedule, which may have child calendars. As part
of this was roll-up I could transparently drop components
in using a copy-on-write mode so that I would cache interested
components
and set alarms, notes and such on them without them being written
to the ultimate source (CS) of the appointment. Then it further 
could optionally show up on the parent calendar as busy time (busy
time roll up) or the appointment could show up (roll up).
This feature required both fanout and roll up. It also had the
concept of 'trusted hosts' where if the CS's trusted each other (as
determined by the system administrators), the CS could say in effect
"trust me, this is [email-masked] and here is his CAP command".
This trust model was for scaleability. Trusted hosts were mostly
for mega-sites so they could have multiple CS working in tandem.
(much like the oscar.<big-isp> sites).  It was not shot down
as much as several editors said "I never heard of that, so
it's off topic" - I am sensitive to any calsch idea having the right
to be posted here.

Don't forget that a few years ago the area directors wanted to
close down calsch. There was a lot of out of band email at that
time (one of the reasons that they wanted to close it down). The
the drafts changed without any debate on the list. Lets not make
that same mistake.

The roll up debate may have been part of the Kiss-Cap mailing
list (now gone).

One of the problems with the current WG process is that it seems
to be designed to update existing protocols and for fairly simple
(pages of paper) protocols. It is very difficult to propose an
entirely new protocol ideas on the WG lists without it being declared
off topic (or distracting the WG). And if you do it out of band - more
of a interested parties list - the ietf screams about doing things
off of the list.

So to the WG and the IETF (and I am sure Bruce agrees), any result
that we would like to propose would be sent to this list as any
other co-though-up idea.

-Doug