Subject: (long) problems with CAP not having "users" and hierarchical calendars

From: "Paul B. Hill" <[email-masked]>
Date: Fri, 09 Apr 1999 16:46:03 -0400

Hi,

I appologize for the long, dense posting but I think these are issues that
need to be considered within the working group. Please don't quote the
entire message when responding. I think everyone will be happier if you
just extract short section to comment on, and modify the subject line to
indicate the particilar point that is being addressed.

After having an out of band conversation with several of the CAP editors
about what we mean by "user" and the fact that the CAP Requirements
document says that CAP does not define "users", it looks like we need to
further refine the definitions. Thinking this through has an impact on how
we think about hierarchical calendars, group operations, fan-out, and the
opaqueness of CALIDs. Many of the CAP editors and other members of the
working group helped to flesh this out but none of them are responsible for
the contents of this particular message.

One of the key points of this discussion is that we often overload the term
"user". I think we have been falling into the pattern where designers often
think of a how a program "talks" to another when it's the people using the
program that is important.  As Bob Mahoney pointed out to me, "user's bleed
when you stick them with a needle." Usernames,  principal identifiers, or
authentication-ids are used by people to indicate to a system that, "I am
me, now I want to do the following operations."

More specifically, I am not confident that we can easily get to a point
where a CAP user will be able to perform two tasks that all customers will
expect to be able to perform, given the current text of the documents. The
first task is, "I am me, let me modify calendars that I already know
about." The second task is, "I am me, let me invite (or whatever) this
other person without knowing the details of what the real calid is.

This all got started when I came back from one of the interim meetings and
asked myself, "What are the implications of hierarchical calendars when
determining when a user might be available for a meeting?" And, "If I want
to insert a VEVENT into a calendar, for use by another user, into which
hierarchical calendar do I make the insertion?" This is a key point. Just
because I have a soccer calendar doesn't mean that other users should
attempt to place an invitation to a weekly pickup game in the calendar. It
might be my sister's soccer schedule. It's up to me to determine where an
invitation belongs.

In the previous paragraph I mean "user" to imply a person or customer of a
C&S system. I do not mean to imply any equivalency between a person and the
CUA that the person may use. In the original conversation it took several
iterations to make that assumed distinction well understood.

When reading the following paragraph from iCalendar I had always assumed
(and others seemed to as well) that "calendar user" and "user" usually
implied a person, or in some cases a resource such as a conference room.
(This is more accurately termed a "principal" within the security
community.) I never conceptualized these as CUA. Furthermore I always
assumed that this paragraph, and others, implied a relationship between a
user and a calendar. 

When used to request  free/busy time information, the "ATTENDEE" property
specifies the calendar users whose free/busy time is being requested; the
"ORGANIZER" property specifies the calendar user who is requesting the
free/busy time; the "DTSTART" and "DTEND" properties specify the window of
time for which the free/busy time is being requested; the "UID" and
"DTSTAMP" properties are specified to assist in proper sequencing of
multiple free/busy time requests.

On the other hand the CAP Requirements document clearly states that such a
relationship does not exist.

CAP does not define users. CAP does not define any default or implied
relationship between a user and a calendar. Users, via a CUA, authenticate
themselves to a CS to access information. All access is subject to access
control.

Having read this too many times I think that the preceding paragraph
overloads the term "user". Instead we probably want to introduce the terms
"authentication-id" and "principal" and carefully define them. However,
even if we do this, I do not think we have agreement about any default or
implied relationship between a calendar and a "user" (where I mean "user"
to be a person or customer of a C&S system.)

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. 

Sidebar:

By opaque CalIDs I mean that the Relative CalID does not have a well
defined delimiter character that can be used to imply hierarchy to the end
user. And the Relative CalID contains no information that implies a context
to the end user. For example a Relative CalID of "joe" does not imply that
this calendar has anything to do with an end user named Joe. Another way to
think about it is that Joe's Relative CalID may be "joe" but that does not
imply that my Relative CalID is "pbh". For now I am treating the ongoing
discussion about delimiter characters and readability of a Relative CalID
as separate issue that will be resolved by the working group.

Just be sure that we're all on the same page the current definitions that I
am using state:

Calendar Identifier:
Also known as "CalID". A globally unique identifier associated with a
calendar within a CS.

Relative Calendar Identifier:
Also known as "Relative CalUID". A identifier for an individual calendar in
a calendar store. It is unique within a calendar store. It is recommended
to be globally unique. [Careful, some could interpret this to mean that it
is not just a username but it could be an LDAP distinguished name. Others
interpret this to mean that it is not a name but is more likely an
algorithmically derived GUID.] A Relative CalID consists of the portion of
the "scheme part" of a Qualified CalID following the Calendar Store
Identifier. This is the same as the "URL path" of the "Common Internet
Scheme Syntax" portion of a URL, as defined by [RFC1738].

As an initial example let's assume the our server has the following
Relative CalIDs:

17075
17075%20101
17075%20121
14612
14612%20101
14612%2011799

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. I
might get this from Bob's business card, his vCard, a phone conversation,
or maybe he sent it to me via email. Others have pointed out that this is
solved by the currently expired working group document,
draft-calsch-locating-01.txt. Unfortunately, I do not think this draft has
been well reviewed or discussed by the working group. 

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.

Sidebar:

Roll-up or rollup is a consolidated view of multiple calendars. Another way
to think about roll-up is to think of it as document view of multiple
calendars.
But roll-up is more than just what calendars are "mine". There are many
cases where I'd want a sub-calendar which should not be used to determine
free/busy times. One example might be a calendar which represents the
office hours for members of a particular product team. It would be
reasonable for them to double book, or multiple book, that time. 

During the working group meeting in Minneapolis there was a brief
discussion about hierarchical calendars, although the term sub-calendars
was used. "Does a parent calendar inherit the contents of its
sub-calendars?" The current answer is no; it was pointed out that this may
complicate the CUAs, because they have to descend down through the tree.
(The CUA can request data from multiple calendars at once; but it
apparently has to descend the tree to know which calendars to request.)

Should there be a CAP operation that can be used to determine which
calendars I own? It's probably too much to ask which calendars I have
access to. (What does ownership or access mean in this context?)

Given our current definition of hierarchical, or sub-calendars, I am pretty
happy that parent calendars do not inherit the contents of their
sub-calendars. But this flexibility comes at a cost of complexity. At the
moment the definition states:

 Hierarchical Calendars - 
A CS feature where calendars may contain sub-calendars. The top-most
calendar in a hierarchy of calendars is called the root calendar. There may
be multiple root calendars in a single CS. Within a hierarchy of calendars,
all sub-calendars have a calendar with a parent topographical relationship.
In addition, sub-calendars may have sub-calendars (child topographical
relationship). In addition, the sub-calendar may have one or more calendars
with a sibling topographical relationship.

But I have not located any text that talks about any implied relationship
between the structure of a hierarchy and the data contained within the
calendars. I like this. It means this implementation can be very flexible
but it has some implications that everyone should consider.

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.

Here is our example hierarchy:

alice
alice/doctor-appointments
alice/soccer
alice/sales-meetings
bob
bob/soccer
bob/appointments

Given the proper access rights, isn't it true that Alice (the user) could
decide that alice/soccer was unnecessary because he is on the same team as
Bob (the user) so instead she just views bob/soccer to determine when they
will have a soccer game? Alice finds this convenient because Bob is the
team manager and should have accurate information. Also Alice is a fanatic
about system performance and might assume that the system will be more
efficient if the soccer information doesn't have to be written in multiple
locations.

It appears that this would be legal within the context of all of the
current working group documents. And with access control it could be very
practical. However, if the working group changes its current consensus and
decides that a parent calendar inherits the contents of it children then
this usage should either be prohibited, or we should expect to derive few
benefits from this "roll-up" feature.

This flexibility also makes it very difficult for Alice to determine which
CalID should be used when scheduling a meeting with Bob. Even the locating
draft does not try to address the semantics of a list of CalID's that may
be associated with a user.  Nor does the draft provide for a mechanism to
update this information. Going back to the example above, if Alice starts
using  bob/soccer to track her soccer games how is that communicated to
anyone else, when they want to determine busy time in Alice's schedule?

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.

One editor counter comments that "if you want to send an email and make
sure that I get it on all my MUAs, you have to know ALL the email addresses
that I use. Right? This isn't a different matter here." I actually think it
is a very different matter. The average end user doesn't care if the other
end user gets the message on all their MUAs. The average end user expects
that the other users will actually check all of their email accounts and
respond or act in a timely manner. In the case of using a C&S system I
think there is a different expectation. Customers have the expectation that
if they examine the calendar to determine there are no conflicts there is
pretty good chance that the other party might be available. Customers will
be upset if they are later told, "No I can't make it, you forgot to check
my calendar that I use to track my group meetings." There will be an
expectation on the requestor's part that the CUA will be able to perform
the operation with ease and reliability. The typical customer will reject a
product that requires the user to maintain an arbitrary list of CalIDs via
a separate mechanism just to interact with one other user.

Let's suppose that I work for a company that does not want me to store
personal data on the company's computer resources. But, also suppose that I
have the mythical 9 to 5 job. Sometimes I work at night or on the weekends.
Sometimes I'm on call but not actually working at night unless there is a
problem that requires my attention. And during 9 to 5, my hours are still
pretty flexible. I may be out of the office taking care of some personal
chores. In this case I may have multiple calendars in multiple domains. I
have my work calendar within ms.com and a personal calendar at
mindspring.com. If you are at ms.com and you view my calendar I have
configured things so that you see both my work related appointments and my
personal appointments, subject to access control. But my personal
appointments reside at mindspring.com. This should mean that you will not
try to schedule me for a server migration the same night that I am
attending my daughter's school play. My appointment with a certain doctor
who's a well known AIDS researcher also shows up as blocked out time, but
since the details reside at mindspring.com, even the ms.com system
administrators won't be able to examine the details. On the other hand
suppose you are not one of my co-workers, but you are a friend. You access
my calendar via mindspring.com. In this case I have configured things so
that M-F 7am to 6pm blocked off.

So, why do we have hierarchical calendars?

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 same customer goes on to say, "If I somehow query a server for the busy
time of a particular user, I think the server is responsible for verifying
that I'm allowed to see that and if so, then providing a single unified
view of the busy time.  Wherever it's looking at a single calendar, or
multiple calendars (potentially on other servers via iRIP or CAP). []
That's what my expectation would be."

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. I am
worried though that I'm missing something that will bite us.

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.

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

Others have talked about using hierarchical calendars to model aspect of an
organization. For example a large company may have many building with
meetings rooms scattered around their facilities. The customer could then
create hierarchy where each building is a parent and meeting rooms within
the building are children of the calendar that represent the building. At
first glance, other than knowing which building a given resource is in,
this doesn't get you much. But, if we apply calendar properties and manage
inheritance within the hierarchy this might be very useful to many
customers. Counter to this idea the working group has had an extended
discussion about delimiter characters within a CalID, because people do not
want the CalID to expose any information about the hierarchy that the
customer site has created, especially when the CalIDs map to user's calendars.

Perhaps the strongest argument that I have heard for hierarchical calendars
is from vendors that have a very different view of how calendar data should
be maintained. In at least one case a vendor has a model where users
subscribe to calendars and the calendar contains events which may be of
interest to the subscriber. In this case the vendor is not really using
hierarchical calendars but is instead creating a web or net of calendars.
In many cases I am seeing vendors with more traditional models, that
evolved from the PIM world, migrating to this subscription concept for at
least some tasks, such as informing users of holidays. Even though I'm on a
NY server, I want London holidays.  Even though I sit in a NY office,
because I work overnight, holidays don't mean anything to me.  The only way
to do holidays and other inherited dates right is through subscriptions.

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,cap://cal.ms.com/dmadeo would contain the following
Info:vjournal   cap://cal.ms.com/ 848c8f7  (Firm Holidays)
Block:all          cap://cal.ms.com/8484783  (NY Holidays)
Block:all          cap://cal.ms.com/8334743  (Personal Items)
Block:all          cap://cal.ms.com/3848483  (Work Items)
Info:all             cap://cal.ms.com/3389393  (My organizational group)
Info:all             cap://cal.ms.com/9433433  (Brown Bag lunch schedule)

That gives everything a CS would need to determine what my schedule looks
like.  The only addition is that (and unfortunately this isn't in
iCalendar) for any given meeting, I might need to say "block this brown bag
lunch, I'll be there".

I hope that early next week I'll post a short, concise, write up on the
terms: user, username, principal, and authentication-id.

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.

Paul