TechTalks Transcript
Calendaring Systems: What We Know and What We Don't Know
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Paul Hill [PH] |
 Robert Mahoney [RM] |
May 11, 2000
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for spring of the year 2000 and to this session on "Calendaring Systems: What We Know and What We Don't Know." You are here because it's time to discuss the core technologies for your future campus.
This is Judith Boettcher, your CREN host for today. I'd like now to welcome the technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known web and all-around information technology expert. Howard?
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of CREN webcasts. As technology anchor, I'll engage our guest experts in a lively technical dialogue that will answer the questions you'd like answered, and ask those very important follow-up questions. You can ask our guest experts your own questions by sending e-mail to expert@cren.net any time during this webcast. If we don't get to your questions during the webcast, we'll provide answers in the webcast archive.
Around 2100 BC, a group of Druids (or possibly Romans) built what may have been the earliest calendar: Stonehenge II. It was made from 80 bluestone pillars weighing about four tons each. (This may also have been the world's heaviest calendar!) By 300 BC, the sundial had been invented, allowing anyone to have a personal, portable clock that told fairly good time -- while the sun was shining! Water clocks were soon invented to tell time at night and on cloudy days.
Virtually no timekeeping progress was made for 1600 years, until early in the fourteenth century when the first mechanical clocks began to appear in the towers of several large Italian cities. In 1714, England's Parliament offered a reward of 20,000 pounds to anyone who could devise a way to measure a longitude accurately from a ship. In 1761, John Harrison -- after 40 years of effort -- built a clock good enough to win the prize. His clock, accurate to within a fifth of a second per day, enabled a ship to successfully navigate from London to the West Indies and back. Knowing where you were and what time it was was so important in the eighteenth century that the quest to build an accurate clock was as cutting-edge science as today's space exploration and human genome project rolled into one.
Keeping track of where you are at any given time is still very important. On a vacation, for example, knowing what day it is might be enough to tell you where you are. Rules such as "if it is Tuesday, this must be Belgium" are often sufficient to keep track of one's location. But tracking office meetings, tasks, rooms and equipment requires something more sophisticated.
Computers have always had fairly accurate clocks and automatically keep track of what day it is, handling even the intricacies of leap years and the change to the year 2000. Building on the availability of the standard information, there are now many calendaring programs to track people, arrange meetings, schedule facilities and keep track of our "to-do" lists. While personal calendars are very useful, much of the real power of calendars is in their ability to be shared by groups, departments and even entire universities.
Calendars, however, are very personal things. When I buy a paper calendar each year, I agonize over which one to buy. Does it have the right holidays on it? Is it the right size? Is there enough room to write stuff on it? Do I want pictures of sailboats or national parks, and do I like the fonts and colors? My computer calendar is also very personal, so sharing it with anybody is problematic. I really don't want the whole university to see that I'm sneaking home early on Tuesday to go sailing, but I do want everybody to know that I'm busy then so they don't sign me up for a meeting. I also want university stuff to be in bold blue letters and my personal stuff to be in red italics, and I want to be very sure that no one can change my calendar or see my personal things. Of course, I also want my calendar with me and available all the time.
It must have been a set of requirements such as those that made Stonehenge weight over 320 tons. The very personal nature of calendars clashes with the great utility of sharing a common calendar. Resolving this dichotomy is a technical, administrative and marketing problem. It requires that there be comprehensive calendaring standards that are widely accepted and that industrial strength access controls -- authentication and authorization -- are in place. At the same time, a calendaring system must be versatile enough to accommodate a wide range of personal quirks of most of its users.
The right software might not be actually quite ready yet, and we might not be quite ready to solve the administrative and marketing problems, but our users have besieged our gates, demanding we get them some calendaring solution! Every day we wait, a few more of them adopt some non-standard software that only works on the Brand X pocket organizers. How do we navigate through these treacherous waters? Can we really get our users to give up their paper calendars, DayTimers and to-do lists on PostIt notes and accept a common central calendar? And can we do this in less than the 40 years it took John Harrison to build his clock that allowed sailors to avoid unexpected rocky shores? We'll explore these questions and more in today's webcast of TechTalk.
Judith?
JB: Well, thanks so much, Howard, for that little quick summary of where we are with clocks. You know, one thing you didn't mention was how clocks are ever going to accommodate net time, yet we probably won't do that in today's session!
Let me go ahead and introduce our two guest experts for today, Paul Hill and Bob Mahoney, and they are both with MIT's Information Systems Group and the Calendaring and Scheduling -- notice how it's called Discovery Project is just one of the many technical teams that they are part of. Paul is the co-editor of the IETF Calendaring and Scheduling Access Protocol at MIT and a senior analyst in MIT's Information Systems Group. And Bob is the co-chair of the IETF Calendaring and Scheduling Working Group and a senior network engineer at MIT's Network Operations Group where he's been since 1993. And Bob also manages the MIT's Network Security Team, which is important because we find that with calendaring, security gets to be an important issue as well.
So Bob and Paul, thanks so much for joining us here on TechTalk today.
PH: Thanks.
HS: Okay, Bob, and why don't we start by just talking about what a calendar really is, and maybe what a schedule is and is there any difference? What are we really talking about today?
PH: Bob, do you want to take that?
RB: Sure. Calendars basically are (at least in the computer-generated world we're thinking about here) a collection of the dates and times that we all agree on. It's what date Wednesday is, how many days are in April and the like.
The schedule is your personal -- the times within that calendar that matter to you: when you have soccer games, when you have hooky from work sailing days and the like. And the challenge is to make many people's schedules coexist in some sort of calendar product.
HS: Does that imply that when we're talking about a calendar, are we talking about personal calendars or are we talking about group calendars? What kind of thing are we talking about?
PH: Well, I would say both, and also, I'd like to modify Bob's answer just a tiny bit. Often when the vendors are talking about the difference between a calendar and a schedule, often the calendar is actually the data store and the calendar holds a copy of the person's schedule and also holds their agendas, their to-do lists, their reminders, their information about how alarms should be triggered and things like that. So what those words mean really depends on who you're talking to and also what market segment you're talking to.
RM: Quite a bit of time went into the crafting of the IETF documents before we could actually agree on what these words meant, so --
HS: Could you just remind folks who don't know what IETF means, what IETF is?
PH: The Internet Engineering Task Force.
HS: And the kind of things they do are --
PH: We attempt to craft Internet standards so that we can have protocols speak with each other so that we all have a common definition of how we're going to do some sort of network task, and then anyone can implement a product that uses that from the documents that the various working groups craft.
HS: Okay, we'll certainly get to some calendaring standards in a bit, but before we do that, is there a difference between the kind of calendars somebody's going to see on a desktop machine vs. what they might see on a palmtop machine? Or are those things kind of the same?
PH: Well, more and more, I'd say people want them to appear the same. Yeah, the representation, the actual screen display might be different because of the form factors, but today, more and more people are looking for the synchronized view so that no matter which device they're using at any given time, they'll see the same information.
HS: When we talk about synchronization, the calendar that lives on a desktop machine is likely to be connected to the network almost all the time, if not all the time.
PH: Yes, probably.
HS: But something that lives on the palmtop, at least today, probably spends most of the time unconnected to the network.
PH: Yeah.
HS: Isn't that a real problem?
PH: Yeah, and people work on synchronization protocols. So far, those have not been really talked about in the IETF context. They tend to be vendor-specific today.
But when you're talking about group scheduling, people are talking about storing the data or the system of record on a central server and then getting views of that data when needed. And so when people are using hand held devices, they're going to be disconnected through part of the usage, but when they have a chance, they go in and they synchronize. They get a view of what's on the server and then they do operations on their calendar when they're disconnected and then you come back, and if you've, you know, turned down meetings or deleted them or moved them, that information will be re-propagated up to the server. And other people might have invited you to meetings in the meantime, and those will be propagated down to the hand held device again.
HS: Would there be some stuff that I might just keep on my local machine, that I would never put on the server? I mean, some personal stuff like the fact that I'm sailing some afternoon?
PH: You might.
HS: Do I really want that on the server.
RM: I mean, certainly there's a whole class of personal activities that we have privacy concerns about, and so some folks may well go ahead and not put that up on the server if given the opportunity. We see some people also use fairly bare-bones, what we call PIM's, Personal Information Managers, for their own private schedules and then they have their official calendar at work, it's really just work-related events.
HS: Yet it seems like you want to see those things merged some how, that people like to look at their calendar and see, you know, whether I'm busy Tuesday afternoon.
PH: Right. I mean, people, you really need to put your personal information into the centralized store, but you don't want to open up that view. So that if someone tries to schedule you for a meeting on Tuesday afternoon, they don't necessarily see that you're sailing, but they see that you're occupied. And so access control becomes one of the prime concerns. This is also the same thing, you don't want people out in the community anywhere on the Internet seeing when you're going to go on vacation for a week because --
HS: They'll attack your house.
PH: Yes, that type of threat is legitimate. Now, there are other companies out there that might have a company policy that says "we don't want any personal information on our calendar server," but that's something really to be resolved inside a company.
RM: And beyond just the question of private events, there's also, you may well choose to not go to any meetings or not allow yourself to be scheduled, you know, maybe in the early morning hours or the late evening hours. And people trying to schedule you may well just find that all that time is committed from the perspective of your calendar. And there's various wrinkles where it might be left open so that your boss can force and meeting and the like.
HS: Yeah, but company policies aside, isn't there also a matter of trust? If I were interviewing for a job, would I trust to put that on the central server?
RM: You might not, and if you were involved in negotiations to have your company merge with another company, you also might not trust some of that information. There's quite a number of scenarios.
PH: But you might put in a fake reason.
HS: Can we talk about the parts of a calendaring system? It sounds like we at least have some kind of database system that lives, either on a server or locally or it sounds like perhaps both. We have some database that lives on a server and lives locally. What are the other parts of a calendaring system?
JB: I think that's a good question, for you had mentioned some before. You had mentioned the to-do lists as well as a calendar and a number of other things. Is there a list, a comprehensive list of elements?
RM: I would say no, there's no comprehensive list.
I mean, if you look back ten years ago on the desktop market for calendars, they tended to be just personal information managers, and they tended to be like a flat file or one or two files kept on the local hard disk. And then people started putting those flat files out on network file systems and people could kind of traverse the directories to gather up information.
And then people finally realized, gee, let's put it in a centralized database and really make this work well. Of course, mainframe users like on the PROF system always had the centralized database to do something like that, but in a distributed, disconnected or partially disconnected world, it tends to be a real tough problem. So people are now talking about calendar servers, calendar user agents -- kind of the equivalent of the mail user agent.
HS: You want to say more about what a calendar user agent is? What kind of thing would it do?
PH: All right, that's really the application that the user is interacting with, and then that application is responsible for helping out, connecting to the server -- maybe multiple servers, depending on what the particular vendor's architecture is like. It's really what transports the data over the network.
HS: Right now, you're talking about calendaring systems kind of as separate applications, kind of separate clients that live on your desktop or live on your PDA or whatever. But I have sort of two other areas. I assume that there's web-based clients.
RM: Um-hum.
HS: Are there also embedded clients? That is, other applications that just do some calendaring inside them?
RM: Yeah, Microsoft Outlook is an example of that, where it's an e-mail agent and it's a calendar agent, all at the same time. You know, it slices, it dices, it tries to be everything for everyone.
You could also, you know, when you're talking about web clients, you know, at the time that you're using that web browser to access the calendar information, at that point, it is your Calendar User Agent. It's your CUA, that's the way we view it architecturally.
HS: Okay, the fact that you can do this thing on the web and the fact that everybody has a web browser out there, why wouldn't everybody just use a web client for calendaring? I mean, then you'd have platform independence, operating system independence. Why would you ever have a client that wasn't a web client?
RM: Well, it's a good reason, it's a good answer for desktop machines that don't move. For roaming machines, like laptops, it's a little problematic because it doesn't really have a local data store. It doesn't have a concept of what your schedule is that you're going to be able to look at disconnected on an airplane, for instance. So it's a little less fully functional.
HS: But if you have a disconnected calendaring client, an independent disconnected calendar client, it looks at some database somewhere. Right?
RM: Well, it'll have an internal connection.
HS: So it's stored in your laptop. You're sitting on an airplane, you're not connected to anything -- although on some airplanes now, you can be connected -- but let's say you're not connected to anything. So there's some database in your laptop, right, that has all the calendaring events?
RM: Typically, it'll have its own sort of snapshot of when it last was connected to the server and kind of, as of a certain date, this was accurate.
HS: Right, but this stuff will be stored in some database.
RM: On your machine, usually in some proprietary in the client's --
PH: Ultimately, you can think about it as being a multi-master distributed database that is only partially connected.
HS: Whatever that meant!
PH: Sorry! But yes, you are working with different databases. You're talking about multiple databases scattered around and people can be making operations on the different databases when they can't communicate at a different time, and then you reconnect them with the network later on and then they synchronize between each other.
JB: Maybe this would be a good time to talk a little bit about the IETF and the standards that they are working on to kind of take a look at the different pieces of the calendaring system. Does that make sense? And then we can talk about what's underlying the actual calendar.
HS: Sure. Can I sneak one question in here, just before we touch on that?
JB: Sure.
HS: Okay, and that is -- because we're very close, I think, to an answer to it.
JB: Okay.
HS: If the stand-alone client accesses this database on your laptop, sitting on your airplane, why couldn't you just have your web client access that database? I mean, access it locally?
JB: Today, the web is -- well, the underlying protocol for web access is a stateless protocol. And people do things like cookies to manage state, but you're generally not caching a database locally when you're using the web. You're always going out and talking to a central server somewhere.
Now, people actually are looking at things like caching data locally and disconnecting from the net and still having access to web pages. But in this case, you're really talking about a back end database. If you're dealing with a site that has 50,000 users, you're not going to want to cache that entire database locally, both from bandwidth, performance, local storage and also security aspects.
HS: Okay. And it sounds like -- and in fact, now thinking about it, it sounds like you'd also need a web server on your laptop. Be a little annoying.
RM: Yeah, there's ways to get around that, but generally, yes.
HS: Okay. Now I feel more content. We can go off and talk about the IETF and talk about some of the calendaring standards. Now, we've talked about a couple parts of calendars. We talked about the database, for example, so there must be some IETF standard for calendar databases. Can we talk about that?
RM: Well, I guess not as yet, kind of. We have a description for the language that we're going to use to describe calendar events, meetings in the future or reminders and the like, that's called iCalendar. And Paul, why don't you give a quick overview of what we're --
PH: Yeah, I mean, for one thing, the IETF would not try to standardize on a database. They deal with protocols mostly and occasionally with API's. And iCalendar is really a data representation.
HS: So it's a data format.
PH: Yes. A lot of this work predates XML having a big mindset so that this is really a mime object format, and it could be -- generally, people are not storing the raw iCalendar format in databases but they're tending to take information from a UI, format that into the iCalendar object and then transport it over to the network using a variety of methods to do that.
HS: Why wouldn't you store it in iCal format? Is iCal format so strange?
PH: No. Different vendors can just pick what they believe is the most efficient data storage. They may want to make it very small and make that a feature of the database. As long as when they -- we exchange this information, we do it through the iCalendar description, we're pretty safe.
RM: Yeah, the other thing is that people had products that predated this data format and so in many cases, the easiest way for them to bring it to market is to continue with their native storage format and really only be going into the iCalendar format during the transportation of the information.
HS: So did they actually write some kind of bit of software that sits in front of a database that knows how to turn this thing into iCalendar format?
PH: Yeah. It's pretty much the traditional parser.
HS: So without their parser, you couldn't read their database and figure out what's in it.
RM: Probably not.
PH: It depends. I mean, most of the vendors have a proprietary database in the back end.
HS: Could you give us an example of what kinds of things iCal addresses and what kind of things does it define? Does it define just ten or 15 things or hundreds or things?
PH: Somewhere in between! And it's also extensible.
HS: But what -- I mean, I assume it says "this is the way you store a time," because times are hard to store. You've got to figure out whether it's local times or do you store GMT plus an offset. So I assume it does that kind of thing.
PH: Yeah, and it says which time zones you're using. It can even say what type of -- well, they call it a calendar, like are you storing in Julian calendar or are you working with Chinese years? All of that. But of course, today, everyone is actually using Julian calendar for all representation.
You talk about meeting times, starting and ending times, locations.
HS: When it talks about meetings, does it talk about who's attending them?
PH: That's another property that you can fill in. You can also say who the meeting creator was, who the owner is. You can give enough information to say that the meeting is really not geographically specific, it's a telephone conference call. I'm trying to think, some of the other things you can have.
HS: What about those repeated meetings, because repeated meetings are always a problem.
JB: Yeah!
RM: There was a lot of interesting -- I came at the IETF work from an operations perspective because we had some operational things we wanted to solve at MIT and I was kind of horrified and astonished, how hard actually figuring out what time it is and what time zone you're in and particularly the currents rules have been another really exciting thing. There's rather a bit of computer science that has needed to be worked out to make this stuff all work.
HS: You said this is not quite a standard yet. Where is this?
RM: The iCalendar draft is a draft standard. There's other documents that we're working on, like the client-server protocol that uses iCalendar and it's certainly possible that work for that draft will end up making changes in iCalendar. And iCalendar isn't really -- there's a couple more steps before it's actually a written-in-stone, finished standard.
HS: Does anybody need to be concerned about iCalendar who's not actually writing software to implement calendars?
RM: Probably not.
HS: Why does the whole world have to be concerned about this?
RM: Maybe thankfully, they don't. Paul, do you --
PH: Although, when you're buying products, if you don't want to be locked into a specific vendor's application forever, you might want to choose to buy a product that supports iCalendar, or you might want to be in a situation where you can interoperate with people who are using a different product. So iCalendar is kind of the lingua franca that you need to be supporting.
HS: But it's not a standard yet, so is anybody using it? I mean, if they're using it, they're using sort of bits and pieces of it, then.
RM: The way the IETF process works. There's frequently kind of work that's in progress and it reaches a point where we think it's pretty good and the working group has sort of passed on it and the IETF as a whole has sort of passed on it and we sort of use that as a working draft we believe is going in the right direction and is reasonably well finished.
But there may be other work that depends on it or extends it that might actually -- you know, we can certainly bump into other wrinkles down the road and might want to adjust things.
PH: You also need multiple implementations that work together in order to advance the draft beyond a certain state.
RM: Because part of these, we're describing a way to do this particular work, almost like a recipe in a cookbook. And we need to have different vendors prove that we wrote a halfway decent recipe that they can actually make workable products out of.
HS: Could you talk briefly about some of the other standards that are there beside this one that talks about the data format?
PH: Bob?
RM: Okay, I'll -- we have a standard called iMIP.
HS: That's not IMAP, for those who are listening.
RM: iMIP. It's usually written small-I capital MIP, and that's the store and forward.
HS: You guys are MIT and this is named MIP.
PH: Yes.
RM: Well, that's the no-choice, probably. But that's the standard, that defines how we move these iCalendar objects around in the store and forward world, pretty much e-mail.
HS: So people are e-mailing calendars? Why are people e-mailing calendars around?
RM: Well, there's certainly any number of products out there that, if I want to schedule a meeting with you, what the program really does is it sends you an e-mail message saying "Bob wants to schedule a meeting at 2:00 on Wednesday." And particularly if it's a product that does e-mail and calendaring, it may well just know what to do with that iCalendar blob that came along with it and put this on your calendar.
HS: There's some assumption that iMIP knows anything about iCal?
RM: Yes. The objects that we're moving around in all the different ways we're going to move this information around, the data is described in an iCalendar format. There's like a BEGIN and an END, and in between is all the description of who's organizing the meeting, what time zone is it in, how long will the meeting be. And so it's pretty much -- the iCalendar description is independent of how we might actually get that information capsule around.
PH: One thing to clarify. The iMIP protocol, people are not e-mailing calendars around. They are e-mailing iCalendar objects which would then get put into the recipient's calendar.
JB: So then they have to be totally plug-in-able or common, be able to be received by the calendar at the other end, then?
PH: Well, sometimes it's a manual process. I may well want to schedule a meeting with someone who doesn't use any calendar product. And all they may ever see is an e-mail message that describes when and where I'd like to meet and they may have to add that to whatever they use, even if it's a paper calendar.
JB: All right, so it can be just a small digital object that can live by itself and be manifested by itself, then.
PH: It's a MIME object so it's going to appear as an attachment in your e-mail. Your e-mail client may be one that automatically recognizes that particular type of MIME object and it may or may not automatically propagate that into your calendar.
JB: Okay. So given that we're in the process of looking -- the IETF working group is in the middle of working on these various protocols and getting comments back and all. Is it fair to say that this is--you know, we've been trying, actually, to talk to you folks about this for a long time and you said it just was too early. Is it still--you know, it sounds like we're on a very early stage here of these calendaring products and wondering whether there are any good solutions that people can have right now in this area.
RM: Well, we are a little early. I mean, one of the things that I think Paul and I both learned from our little discovery project from MIT's perspective is that we'd really hoped that the marketplace was more mature than it had been. We thought we'd be done in 30 days and that was coming on three years ago.
HS: Just the opposite of web time!
RM: Right!
PH: Yeah, that's right. That's a good point, right.
RM: A lot of what -- I mean, there's always been a lot of small work group calendaring programs out there for a number of years now and they've usually worked pretty well. Now people really want to exchange information over the Internet and they want to be able to connect to different -- I don't want to have to have the same client that you have. I want to be able to talk to your server and schedule meetings with you. And this is all a little bit more complicated. There's been a lot of difficulties in getting as far as we've gotten. There's a lot of just plain, hard problems that needed to be done.
JB: We do have a couple of questions. Howard, did you want to take one?
HS: Yeah, we have a question from Rice University, I can't tell who it came from really. But at any rate, it's really quite an interesting point that's being made, whoever made it. They said, "At my university, the big split in calendaring is between personal calendars and public calendars. The former are used to schedule appointments, etc., the latter are used to publicize events within the university and to the world at large. People seem to have trouble understanding the tools which do one won't easily do the other. I'm hoping you'll tell us that's not true."
PH: Well, we're getting there. If you have an event publishing system, you know, you go -- let's say you go to a web page and you can look at all these events. People are beginning to develop things where those might be represented as iCalendar objects. And let's say that you're using Exchange as your personal information manager for your calendar. You may be able to go to a page that displays all these public events and then just drag the event on to your calendar and Exchange and now it appears in your personal calendar.
So we are getting there. I mean, people are doing this with a variety of products. Corporate Time accepts some drag and drop. I think the latest version of Meeting Maker and Lotus Notes do this as well, so you are seeing this happening.
HS: We have another question here. Again, I'm trying to see where it's from, but it's difficult for me to tell. It's from a place called SCAD.edu. Do you have any idea where that is, Judith?
JB: No, I don't. Maybe we can ask the person to write in and tell us, and also at the same time, we will ask other folks -- it's a good time to ask more questions, so they can go ahead and send them in while you're looking out for this next one.
HS: Wherever SCAD.edu is, the question is, "I need to find a program that will allow me to develop a calendar in both a traditional calendar format" -- whatever that is -- "as well in a text-heavy list format." Whatever that is! "The program must have the capabilities to be a full calendar as well as be divided into categories according to the individual user's needs. Also, I need it to be accessed through our website."
JB: Is that a tough problem?
PH: Yeah, I mean, I've seen some event publishing systems that do things like that.
MIT was very interested in something like that and we did not find a product to buy. We ended up with some students who wrote a system for the school newspaper and we've actually -- we're in the process of taking that over and making it really an official product for the university. I believe University of Virginia also wrote some of their own code to do something similar to that.
For commercial products, yes, there probably are some out there. In fact, I know that there are, but it really depends on what your existing infrastructure is. You know, if you look at something like Lotus Notes Domino, if you already have that infrastructure, that might be an appropriate solution. On the other hand, if your infrastructure was based on Exchange, then that might be a better solution.
So you really need to think about what your e-mail infrastructure is, what your web publishing infrastructure is, what your authentication models are, how you manage access control at your site. All of those factors play into what products you can choose.
RM: And even beyond all the technical questions, there's the user acceptance problem. Just like Howard might spend some time trying to pick between two different calendars with the artwork, even though all the numbers are the same, the users are frequently looking for very specific features or particular layouts that they find work for them. It's a very personal sort of purchase.
JB: What kinds of features do you find that people are interested in that you hadn't thought about before or that you hadn't anticipated?
PH: Well, I think one thing we didn't anticipate was that people are very sure about what they want!
HS: You met a fervor that --
JB: A fervor!
HS: I think people have a lot of fervor about anything they own. You're saying you see a lot of -- it's especially true of calendars?
PH: Right. Well, I mean, I don't know that it's especially true, but certainly people care about "can I make my personal sailing hooky days to come up in blue text as opposed to�"
HS: To match the water. Around here, that would have to be brown to match the water!
PH: --my work meetings. So I mean, there might be a lot of small personalizations. Can I change the font? Can I change how I'm notified when a meeting's coming up has certainly been -- and that actually things like that do have architectural --
HS: But don't all the calendaring systems -- I've seen quite a few. Not quite a few, I mean a half a dozen. You've probably seen more. But they all let me change the font to pretty much whatever I want and change the color of events and do that kind of thing.
PH: No, they don't, and if they do, they may not do it in the way the person you're trying to sell on this new product really cares about it. I mean, it may be that it just doesn't have brown. But at least not all the different calendaring programs that we've seen, certainly, allow the same level of user customization.
RM: And they all have a different set of features. And given any five set of users, they will have five different little minor features that are of key importance to them.
JB: So this is an area where trying to get consensus on a product that really is used across a large group of people, it sounds like this is a tough problem.
PH: Um-hum.
HS: Is that one of the reasons that IETF is doing iCal so that -- I mean, is the hope that someday people that have three different calendaring systems or ten different calendaring systems and still they could all share the same data?
RM: That's the goal.
HS: So I could have whatever quirky colors I want and it wouldn't matter.
RM: Um-hum.
HS: If the university is thinking about choosing a calendaring system, it sounds like a difficult job, but what kind of things should they be considering?
PH: Bob, you start!
RM: All right.
HS: We're trying to get folks who are listening some kind of checklist. Here's the things to go out and look for.
RM: All right, I think that's going to really be site specific. I mean, at MIT, security is a prime concern.
HS: But where wouldn't it be? I mean, security seems pretty important.
RM: One would think, and there are some people that just decide that usability or user community acceptance is much more important than security and they'll sacrifice the security. In the long run, they'll run into some problems, but it may be the right solution for them today. I think --
HS: I would imagine there's certainly people here, I'm sure people at any university, where there's a lot of folks that just won't use the calendaring system. They believe that people could see their personal stuff.
RM: And there are also people who will choose to use an insecure product just because they've become more comfortable with it, despite all of our --
HS: Could you tell us a couple of the key security issues with a calendaring system?
RM: Well, in your case of wanting to go sailing, do you have the opportunity to hide that information, because it may as well be -- it may be a doctor's appointment, it may be a meeting with a lawyer or maybe a job interview, so you might have varying -- and the organization itself may have varying levels of concern about what data can leak out.
We also care about whether the authentication data, whether your password and such travels over the network in clear text or whether it's encrypted, whether the data stream that's moving these objects around is encrypted. Certainly there are a lot of -- even the networks that are behind firewalls, it's possible to have disgruntled employees or any sort of person already within the network that might be listening to traffic not intended for them and that can be a concern.
JB: At --
HS: Go ahead, Judith.
JB: I was just going to remind folks that another way to send in a question is through the expert@cren.net and they can send in the next question to our experts. And with that, I'll come back to you, Howard. Go ahead. If you can remember what you were saying!
HS: No, that's fine.
RM: We're still working on the requirements?
HS: Yeah, this is real easy. I just say, keep working on those requirements!
RM: Another one would be scalability. I mean, if you're talking about an educational site, you're talking about, you know, a population of anywhere from 3,000 to 150,000.
HS: What things are going to determine whether a calendaring system you're going to look at is going to be scalable?
RM: The type of database. Can the load be split across servers? What happens when you have a server that has reached capacity and you now need to split the user accounts across multiple servers. If people have group meetings, do suddenly a bunch of people become dis-invited because you've done that?
HS: Ah, a personal management tool!
RM: Yes. What type of information do the clients, the end users have to know? Do they have to be told manually that suddenly the name of their server has changed? Or can this be done automatically through DNS or through an LDAP lookup?
HS: You mentioned something about the databases affecting scalability. What kind of things are we looking at in terms of databases to make these things more scalable?
RM: Well, if somebody's implemented their database as a couple of flat text files manipulated by PERL code, that's probably not going to work very well for 100,000 users that are doing group scheduling. And you'd probably rather have an industrial strength database at the back end. A lot of the vendors have proprietary databases.
Microsoft, for example, uses their Jet database, which is what Exchange is built on and what Access is built on. Meeting Maker has a database that was developed by On Technology, let's see, back in late 80's, early 90's. It's an object oriented database. Corporate Time has a database that was based on, I believe it's a sister company that was founded around the same time.
HS: But so again, how do you know? I'm looking at some system and they say, we have a nice database back here.
PH: A lot of times, you're not actually privy to the details of how their database was implemented. It's a proprietary database that the company is keeping close to their vest. For a lot of these situations, you've got to try to do some modeling or do some testing. I mean, sometimes you don't know until you try.
HS: Or call somebody who's using it.
RM: And reference sites.
HS: Yeah. Are there issues about what hardware is supported? Do all these things support the common operating systems?
RM: No.
HS: Okay!
RM: I mean, there's certainly -- for MIT, for instance, we spoke with the operations people and we know what kind of servers they currently run for this sort of up time demands and the sort of load we see, and so we were to some extent guided by what are we comfortable with running and what do we think can handle this sort of load. But we've seen products that run on all kinds of different operating systems.
HS: So if you just pick one at random, it's not going to run on Windows and Macs and Linux?
RM: Well, the servers, that really depends. I mean, you need to ask the vendor and match that up with your operational requirements. If you're a site that has all of your existing servers running on a Mac, then you probably want a product where the calendar server can run on a Mac. If all you allow people to do is run servers on Unix workstations, or big Unix servers, then you're going to be looking for a product that runs on a Unix server. You may be a site that has an NT based infrastructure. In that case, you're going to be looking for products that run on NT. And you know, you have a wide variety of vendors to choose from and you really need to look at each one on a case-by-case basis.
HS: When we talked earlier, you mentioned that there were some Buckley amendment and FIRPA issues with calendars. Could you --
RM: Potentially.
HS: Mention a couple of those?
RM: Okay. People are looking at web portals --
HS: And they should be!
RM: Yes.
HS: It's a good thing to look at.
RM: And they want to build calendaring systems into those portals, and so you have sites that are talking about with the classroom, having the user, the students having their course schedule there and you even eventually have faculty putting course notes and agendas and problem sets and maybe things like that, publishing that possibly through the agenda feature in the calendaring and scheduling system.
Now, different lawyers may interpret that as being some of the students' data that has to be protected. You may also get into a situation where, well, say it's a writing class and a faculty member wants to take one of the students' writing assignments and share it with other members of the class and ask them to write a critique or maybe to do revisions. If the professor ends up making that available as course notes published out through the to-do list or the agenda feature or something like that in the calendaring system, then that probably pretty clearly falls under FIRPA requirements.
HS: We have a question from Andrew Lawrence at the University of California at Irvine, where I'm sure it's beautiful right now. And Andrew has two questions here. His first is, "Currently commercial client server calendar solutions targeted at LAN or enterprise customers are extremely proprietary, requiring not only the vendor's client software but their server architecture as well. Do any of the burgeoning standards address this, anything which would allow a vendor to mix/match of clients and servers like the POP or IMAP protocols?" We'll just do these questions one at a time.
RM: Well, that is sort of the goal. Certainly, many -- all the vendors are going to add some features to their clients or servers that they believe differentiate them and provide extra value, but we're hoping to have a set of standards written so that I can point a compliant client at a compliant server and I can exchange at least the basic scheduling information and do recurrence and all of those things. So we're hoping to get into the same situation that IMAP and POP are.
PH: Yeah, the area that's not being addressed tends to be the administrative interface. How do you create new calendar users? How do you clean up the database, things like that. But as far as getting the clients out there that the users want to use, yes, that is the entire goal of creating an open standard.
HS: I think actually I'll read Andrew's second question, but I think you just answered it.
PH: We will find out, right?
HS: If you haven't, please do. But I think I heard the answer. Andrew says, "It's often the case in a university that there are many small department calendar systems which work fine and are liked by the users. However, the systems don't talk to each other and are often from many vendors. Is there anything which might facilitate the ability to have servers talk to each other, exchanging data and appointment requests as necessary?"
RM: As the vendors adopt the open standards, yes. Looking at the actual realities of the market over the past several years, you'll probably go and find that a number of the companies that sold the products into those departments no longer exist today. So eventually, some of those people are going to have to migrate to new products.
PH: I mean, there's certainly people on campus that are using calendar programs from companies that have long since gone out of business because they have some feature that they've been comfortable with and have been relying on all this time, so it's -- adoption can be a very difficult part of a deployment scheme.
HS: Yeah, I know people who still have stuff on their Newtons and just won't give them up and they'll keep trying with their Newtons until -- unfortunately, silicon chips are really robust!
PH: The heartbroken Newton user is a well-known phenomenon.
I have a couple questions that we haven't gotten to, and while we're waiting and inviting folks to send in a quick final question. We just briefly mentioned synchronization earlier about all of this information and the fact that oftentimes we are using desktops or laptops that are connected to the net. What about the synchronization on the hand helds and the pilots as we start moving from appliances and maybe want to not necessarily always go through the PC's. What's the outlook there for synchronization at different levels.
RM: I guess my quick answer would be if a vendor doesn't have a plan on how to do that today, then they probably won't be in business in a couple years.
PH: Right. The people, much like the heartbroken Newton users, the palm users and all the other PDA users come to really rely on those devices and they're just not going to accept a calendar that won't at some stage down the road interact with that device.
JB: So that we really will have to have synchronization programs that go directly from the hand helds to the web, then.
PH: Well, that they may go through --
HS: It sounds like synchronization is a two-way street here, is that --
RM: Yes, but those devices might synchronize through another device that the user owns. For example, the user may be expected to have a desktop computer with a cradle or maybe an IR port. And so the user would actually sync through that rather than having the PDA have a full featured network connection.
JB: That would make things more complicated. I couldn't go off on a trip and just take my PDA with me.
PH: Well, there are some devices that let you do that. There are people who have modems connected to their PDA's and the like, and I'm sure that there's going to be no shortage of new people adopting these technologies and they're going to want to continue to push the envelope as to where those are useful to them. So I wouldn't be -- I'd be astonished if that wasn't addressed soon.
JB: So that probably will be coming, but we just don't know when.
RM: Well, there's products like that today. There are people doing reflectors to cell phones so that you can actually use your cell phone to get all of your calendar information. It's really, go buy the product that has the features that you need.
JB: Okay, Howard, what do you have on your list that we haven't talked about yet?
HS: In trying to get this thing to an end, since we're past the time that we end anyway. One of the things you said when we talked last time was that you said no calendar system today has industrial strength authentication, and I just wondered, what's the state of calendar software right now? How close are we to having stuff that's really as good as we need to do large group calendaring or university-wide calendaring?
RM: That varies a lot. Actually, if you look, the next version of Exchange will be integrated into Windows 2000 and you can do, you know, Kerberos version 5 authentication. That's pretty neat.
But most universities are not standardizing their e-mail system on Exchange because traditionally it hasn't scaled very well and it also tends to be susceptible to things like, you know, Love Bug. So Microsoft in some ways might be kind of bleeding on the edge for the authentication issue.
We've been pushing on a number of vendors over the years. Meeting Maker has been talking about adding a Kerberos port. I don't know what the status of that project is lately. Corporate Time has been working with CMU. They apparently have a version of their server in beta that's port [inaudible] by Kerberos. And we're told that they'll soon have the clients available for beta testing as well. I don't know when they expect to release that product commercially.
PH: I think we have recently gotten to the stage where all of the vendors sort of agree that they need to address security, and while some of them are taking different paths to get there, it's no longer an issue that they need to get there.
HS: Has MIT adopted a university wide calendaring system?
RM: No.
PH: Not as yet.
HS: What's it going to take for you to do that?
RM: Something we like? And we're very picky.
PH: We are!
HS: No, I'm asking the question because if you haven't adopted one, other folks who are thinking about this -- I mean, if you can tell us what it would take to get you to adopt one -- other than to find one you like --
PH: We're getting close. I mean, we're --
HS: Other folks might -- there'll be hope that they could -- I mean, the fact that you haven't adopted one because you are so picky, because there are special requirements at MIT that a lot of other universities don't have? I mean, do you have too many students? Are they too clever?
RM: I don't know that our requirements are special. We are kind of stringent about them. We really, really do care about security, and until very recently --
HS: Is that the hangup, security?
PH: No, not just that.
RM: It's also scalability.
PH: We have a very limited number of people to come in at 2:00 in the morning and fix a system, so we like things that will run for months at a time without much care and feeding. On our administrative requirements, we don't want a point and click interface. We want to be able to do things as batch jobs because we'll do, you know, lots of automation with scripts and codes.
HS: That's to say you want to be able to -- the whole class of 2005 when they come in.
RM: Right.
PH: Yeah, and we want it to take five minutes instead of, you know, three weeks and then sending a person to therapy for repetitive strain injury. Those are the types of concerns that we have.
HS: You said you're close.
PH: I think we're getting closer. I mean, we're --
HS: Have you actually seen a product?
PH: We are always looking at products. That's all we seem to do these days.
RM: We have -- we just completed one pilot without about, what was it, around 100 users. We're going to scale that up as a phase 2 pilot with I guess around 300 users, maybe 350. So all of IS plus a couple of other people.
HS: And that's going to be a university wide -- this is going to be all students, faculty and staff or just --
RM: That would be what we would call a centrally supported system�
HS: Is that your goal?
PH: That's our ultimate goal. We don't know how quickly we're going to get there. We don't know if the product that we are going to pilot at this slightly larger scale will be the one that we'll choose. We're considering it. We're looking at it. We have a large number of people using Meeting Maker in departments today. Today, we're really not ready to commit to that product as a campus wide solution.
RM: There's a lot of -- and also, I mean, we have probably one of every type of calendar here, so -- and people who are using it.
HS: And I'm sure that almost anybody, I think, is probably nodding their head, too, and saying, "We have one of everything, too."
PH: Yeah, converting those folks can be a real issue and certainly, just from an organizational dynamics standpoint to when you're ready to do that, boy, you better be ready to do it well and you better be ready to not lose the data that people have spent five years typing into their current systems.
HS: Yeah, so that's a really important issue, too. People would expect that you'll be able to take all the stuff that they have tucked away in their calendar and move it over to the new system.
PH: And particularly since we're all -- I mean, everything out there that's deployed is proprietary, we don't have the full standard suite running on anybody's system yet, so some of that is going to be very hard if not impossible to convert out. So there's going to be some compromises when it comes to D-day.
HS: So in the remaining negative time that we have --
JB: I was waiting to get a word in here, Howard!
HS: Could you tell us, what should universities do? It sounds like a really difficult problem. Paul?
PH: That's right! Keep on looking, testing, talking to the vendors, you know. Make up your set of requirements is the first thing. I think you also need to look at your business plan. Are you actually going to support students as well as faculty and staff? If that's a requirement, you need to figure out, how much are you willing to pay to do that and then go off and find the vendors that can work with you.
RM: Talk to other schools, talk to other large sites, learn from their mistakes.
JB: And also, it seems like most schools move forward by doing small pilots and working with a smaller group of people with these. Is that fair to say?
RM: Well, it's always easier to start small and grow, rather than just leaping in and expecting to solve all the world's problems at once.
PH: I think, going in, people should realize that in spite of the fact that there are products on the shelves out there, this is a really hard problem to solve correctly, and particularly with all the various university related wrinkles.
JB: So I guess that another piece of advice, then, is to watch this space.
HS: Watch this space and feel free to prod your vendors or prospective vendors about where they're going to be in relation to the standards that we're developing.
JB: Okay, great. Howard, final question?
HS: No, I think I filled all the negative time we have here.
JB: All right.
HS: We're more over than we normally are!
JB: We really are, and I want to thank Paul and Bob for their time today and I think the fact that we ran so much over on a topic such as calendaring and scheduling means that there's more to this time stuff than we can possibly handle.
So with that, I'd like to invite everyone to set aside time on their calendars for our next TechTalk, two weeks from today, and we're going to be talking about Designing and Using Collaborative Environments.
Many thanks to all the institutions who support these TechTalks and for their support today. Also for Meeting Maker and be sure to look for their special offer, actually, to today's participants on the web page.
A special thanks to guest experts Paul Hill and Bob Mahoney; to our technology anchor, Howard Strauss; to Terry Calhoun, event page producer; to David Smith and Patty Gaul of CREN; Julia O'Brien, Jason Russell, Gayle Terkeurst and the whole support team at Merit; to Susie Berneis, audio file transcriber; to Laurel Erickson, transcript editor and indexer, and finally, a thanks to all of you for being here. You were here because it's time.
Bye, Paul, bye, Howard, we'll see you all next time.
HS: That's great. I'm looking forward to it. Bye bye.
JB: Bye now.
