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 pervious 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.