[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with CAP not having "users" and hierarchical calendars
> Date: Fri, 09 Apr 1999 16:46:03 -0400
> From: "Paul B. Hill" <pbh@mit.edu>
> ...
>
> Before we go too much further, let's stop and think about how a person
> would interact with a single server system that implements hierarchical
> calendars with opaque CalIDs.
> ...
> ...
> How do I, Paul, tell our example server that I would like to examine Bob's
> calendar to see if he has a scheduled appointment for 2:00pm on Wednesday,
> April 7th, 1999?
>
> At first glance I was tempted to say that I'd have to learn the mapping
> between Bob-the-user and Bob's CalID. I might get this from a
> directory....
>
> As soon as we say we have hierarchical calendars I don't think that these
> mechanisms are an adequate solution, if they ever were. The locating draft
> introduces the concept of a default calendar for a user and mentions that
> the default calendar may include rolled-up information from all the user's
> other calendars. No working group document talks about "roll-up", whether
> or not it is mandatory or optional, or how a user would control the roll-up.
I see roll-up as an implementation option.
Some may not need it or can not use it, others may want or need it.
I could want no roll-up at all in a sub-calendar:
I am maintaining a calendar for my groups football pool and it
contains all of the NFL schedule and my implementation
or administrator does not allow me to create root calendars.
I could want roll-up for named components only:
I will only be attending the 49rs games that are local.
And then maybe only some of them.
Or I might want roll-up in a vendor specific way:
The root calendar is a pool of company cars
and the sub-calendars are calendars for each
physical car. The only time the root calendar is
'busy' is when all cars in that time slice are booked
in all of those sub-calendars.
I also might have NO acceess to read any of those sub-calendars.
(I know that resource groups and resource pools are not in
CAP-1, but no need to break it for CAP-2).
In some cases the CS will not allow the CUA to change the
roll-up rules as they are part of the vertical application
in the CS.
> Should there be a CAP operation that can be used to determine which
> calendars I own?
Yes - ask for all calendars where the OWNER property contains
your authenticated id.
> It's probably too much to ask which calendars I have
> access to. (What does ownership or access mean in this context?)
OWNER-ship is a calendar tag (property) invented by the VCAR work
to help identify a set of users that will often have special rights.
(grant 'all' access to everyone that is tagged as an 'owner').
OWNER currently has no other meaning.
> ...
>
> Let's take another example. Again we have a single server but we have
> either Relative CalIDs that appear legible to many users, or maybe I am
> actually showing Calendar Names instead of CalIDs. For now let's just
> pretend that this distinction is not important.
>
> ... (examples deleted)...
>
> Now George just wants to determine when Alice is available for a meeting.
> Does George have to discover the entire calendar hierarchy and then query
> each calendar to determine if Alice has an appointment in it? Obviously
> this would be very inefficient.
So is BUSY time a query to the CS or query to a calendar on a CS?
If it were a CS query - then how would I ask for a specific calendar only?
What if I want the calendar BUSY time, and not a authenticated id busy time?
(Is this room available - I do not care who else has it at other times).
Perhaps:
If I provide only the CSID and a username, I would
be asking for any BUSY time for the username
for any calendar on the CS.
If I provide a RELCALID and a username, I would be
asking for any BUSY time for the username and only
for that calendar.
If I provide a RELCALID and NO username, I would be
asking for any BUSY time on the calendar.
I don't think that asking for BUSY time for all users
on a CS has any use.
> Let's suppose that I work for a company that does not want me to store
> personal data on the company's computer resources. ...
> ...
> So, why do we have hierarchical calendars?
I did not see that your example eliminated hierarchical calendars.
If my employer did not allow personal information, it does not
mean that I could not have hierarchical calendars containing
work related components. (Work Breakdown Structure - WBS)
> It appears that at least one potential customer is "interested in multiple
> calendars with varying degrees of opaqueness from a free/BUSY point of
> view." "This fits into how we work, where I have different projects that
> I share with others. There's also calendars that I want to inherit from the
> firm (such as interesting business dates, unusual holidays, etc)."
> ...
> The key thing I'm trying to push is that we should make the protocol simple
> and provide flexibility for the server implementation. If we say that CAP
> has to provide (subject to authorization) the busy times of dmadeo when
> asked to, then by hiding the details of whether that's many calendars or
> one, we've simplified the protocol without limiting the implementors.
Agreed.
> A counter argument to the previous statement is that any opaqueness does
> not need to be derived from the calendar hierarchy. Instead it can be
> achieved using VCARs on individual events. However, applying default VCARs
> to an entire hierarchical may result in fewer operational mistakes within
> an organization. Please note that this is not a minor point. For many
> customers this is a major issue.
I could see that you could have access to my BUSY time, and not
have a VCAR to access my DTSTART, DTEND, or DURATION. (If that
is what you are saying).
If I ask for all OPAQUE components and the DTSTART, DTEND, or DURATION,
I now might have a count of components.
With BUSY time, I just know a time slice is opaque.
> Another user appears to use multiple calendars to help keep track of
> overlapping appointments - knowing that he will not attend 'this one' this
> week. I his case he does not want "rollup" to be a mandatory feature. A
> counter argument to the previous statement is that VEVENTs within a
> calendar may overlap and the user should simply modify the attendance on
> the event that will be skipped during a particular week. Should we extend
> iCalendar to include a property for "allow conflicts"?
Yes - I think by default conflicts should be allowed.
And I think that each component or calendar should be allowed
to be marked 'no conflicts' and enforced by the CS.
Another issue with appointments is, as Frank pointed out:
That meeting is 15 minutes away, so I am also busy
15 minutes before and 15 minutes after that appointment.
In which case the CUA better not tweak with the component. The time
block would have to be local to the users calendar and not pushed
back to the ORGANIZER as an update to the component. And it may or
might not be visible as a component in a query, yet be OPAQUE
and show up as BUSY.
Also another reason for hierarchical calendars:
An ISP does not allow users to create root calendars.
They can do whatever they want - under their calendar.
> Some last minute thoughts:
>
> I'm starting to wonder if "sub calendar" is the right notion we should be
> selling. Perhaps a flat namespace with both "default" and "nondefault"
> calendars. A default calendar is associated with a particular "entity:
> person or thing". It contains events as well as instructions for how to
> attach nondefault calendars. The choices are "informational:
> [all,vevents,vtodo,vjournal]", "blocking: [all,vevents,vtodo,vjournal]". A
> nondefault calendar is not associated with an entity.
> ...
So a 'linked' calendar that does roll-up?
> That gives everything a CS would need to determine what my schedule looks
> like. ...
Your schedule - yes.
You would loose the ability to allow users that can not create root
level calendars to have other non-rolled-up calendars.
I see hierarchical calendars and roll-up as separate.
And I see that roll-up as a calendar option listing the CALIDs
of any calendar - sub-calendar or not.
I could live with roll-up not in CAP-1.
> BTW, I know that Steve is wary of the issues that I have raised. At one
> point during our email discussions he replied, "I have been working with a
> lot of ISPs, Portals, and enterprise customers. They all have very
> different ways of managing user information." I hope that after my next
> posting he'll be able to elaborate on this point.
THANK YOU VERY MUCH FOR THIS WORK!!!!
-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM http://playground.sun.com/~dougr
Pager: Doug.Royer@Pager.Eng.Sun.com
801 W. El Camino #131 Work: (650)786-7599
Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL