Minutes from Calendaring Summit, 7/24/96

Re: Minutes from Calendaring Summit, 7/24/96

John,

I would like to extend a very hearty 'well done' to you for your tour de
force in note taking.

Like, wow, man!

Besides that, I think that your contribution to the repertoire of technical
vocabulary will prove to have been fundamental.  People worry about
reliability on the Internet and now we have a name for the problem:
intermittent Internet access is "internittent"...

d/

--------------------
Dave Crocker                                            +1 408 246 8253
Brandenburg Consulting                             fax: +1 408 249 6205
675 Spruce Dr.                                 dcrocker <at> brandenburg.com
Sunnyvale CA 94086 USA                       http://www.brandenburg.com

Internet Mail Consortium               http://www.imc.org, info <at> imc.org

Looking for vCalendar/vCard-compatible applications...

As a starting point for tracking the work in this group I implemented a
vCalendar export mechanism in the development version of Musi-Cal today and
will be implementing vCard export for venues shortly.  Over time I plan to
export other formats as well.

There's just one itty-bitty problem.  I have no applications that import
vCalendar or vCard so I have nothing to test my exporting.  I know that
Four11 exports vCard and that several sites on the Web (like Atlantic
Records) export NowSoft's format.  If I'm correct in my reading of the
Four11 site, NowSoft should import vCards, but that's all I've discovered so
far.  The Versit site is replete with vCard information, but has little
vCalendar stuff.

Any pointers appreciated...

Skip Montanaro     | Check out:
skip <at> calendar.com  |   Musi-Cal: http://concerts.calendar.com/
(518)372-5583      |   Conference Calendar: http://conferences.calendar.com/

Re: Minutes from Calendaring Summit, 7/24/96

John, 

your summary is outstanding.

All the best

    -Philippe-

	Philippe Kahn                Starfish Software, Inc.
	philippe <at> philippe.com        http://www.starfishsoftware.com
	Voice: 408-461-5855          Fax: 408-461-5955
	Pager: 1-800-841-9668        AOL: philippe

Accurate location information is a "must have" requirement

As the developer of a "calendar/schedule enabled application" I'd like to
chip in one thing Bob Tatar and I brought up at the meeting that appears to
be missing from the meeting minutes.

There is a lot of attention paid to meeting times, but virtually no
discussion of accurate location information.  Bill Spencer treated timezones
pretty carefully in the SWTP spec, and with recurring dates and all, it's
pretty clear that they need to be carefully considered.  However the only
real location tags I remember seeing are the LOCATION properties in SSTP and
SWTP (both free-format text fields) and the GEO field in vCalendar (which
takes a lat/long tuple).

Neither of these is adequate for a number of reasons:

    1. Lat/long information isn't enough to infer timezones because people
    at various places in the world have adopted different ideas about the
    correct relationship between the Earth's lines of longitude and the
    clock on the wall.  Simply put, there are some pretty daft people out
    there pushing the boundaries around.  (Take a look at the world map in
    the front of your handy-dandy "Rand McNally Comprehensive World Atlas"
    if you think I'm kidding.)

    2. Many applications that will want to interface to calendar systems
    (like our event calendars, Musi-Cal and the Internet Conference
    Calendar) will place as much emphasis on location as time.  It would be
    a shame to think that that basic events could only travel one way
    (toward calendar systems) because loss of information prevents it going
    the other direction.

    3. People will think up all sorts of different ways to enter information
    in free-format location fields so people trying to parse them will
    invariably run into snags.  (Believe me, I squeek from experience.)

    4. There seems to be an implicit assumption that events are entered
    one-by-one.  We get information in huge batches sometimes, often with
    varying degrees of consistency.  I have never seen concert or conference
    listings that indicated timezones.  Most listings don't even give event
    times.  It's impossible in most cases to add timezone information
    manually because of the sheer volume of data we deal with, and for most
    purposes it's pretty irrelevant.  Inferring it from accurate
    city/region/country information is the only chance of being able to feed
    it to calendar software.

    5. Finally, event location will take on greater and greater importance
    as scheduling reaches out beyond small groups to encompass organizations
    that are geographically dispersed.  No longer will it be sufficient to
    indicate "Mozilla Room" as the sole indicator of a meeting's location.
    If I add a conference in Miami, Florida to my scheduler it's not too
    wacky to think it should automatically add a to-do for two weeks prior
    to the conference as a reminder to book my super-saver tickets.

I welcome comments on this.

Skip Montanaro     | Check out:
skip <at> calendar.com  |   Musi-Cal: http://concerts.calendar.com/
(518)372-5583      |   Conference Calendar: http://conferences.calendar.com/

RE: Accurate location information is a "must have" requirement

In response to Skip Montanaro's comments about location
information I'd like to put forth a wacky idea.

In addition to a "location," an "event", if it is a "meeting"
often has an list of "attendees".

Versit's vCard spec defines a format for "person" information
which zeros in on location pretty well. In addition to the
Time Zone and Latitude/Longitude info Skip mentioned, it
has all the address structuring stuff needed to represent
a physical address in a machine-readable way. 

I put forth two ideas here. One is that a vCard is a good
representation for a meeting *attendee*. It can represent
attendees which have electronically reachable calendaring
agents (via email address or URL type pointers) and it can
represent those who do not, which is a plus in certain
scenarios. The second idea is that a vCard which represents a
place, in lieu of a person, be used to represent the meeting
*location* in whatever level of resolution is deemed useful.
Internally it may just need to be a conference room name but
as Skip points out, the further afield an attendee is, the
more likely that details like address, and even an attached
map, become useful in most applications, and mandatory in some.

-Roland

>

RE: Looking for vCalendar/vCard-compatible applications...

>There's just one itty-bitty problem.  I have no applications that
>import
>vCalendar or vCard so I have nothing to test my exporting.  

>Any pointers appreciated...

Versit demoed vCard/vCalendar support at PC Expo using
a pre-release of Lotus Organizer and OnTime. We don't
have permission to pass these around, but we'll using
them in demos at Networld+Interop next month, so if you
demo with us there we'll have some infrastructure to
help. We'll be adding trivial support for a calendar
object in the vCard demo applet too, to facilitate
some of the cut/paste scenarios and catch events 
off a web browser. I'll let you know when that's ready.

Re: Accurate location information is a "must have" requirement

On 8/3/96 at 1:07 PM -0500, Skip Montanaro wrote:

>Subject: Accurate location information is a "must have" requirement

I could not disagree more.

>There is a lot of attention paid to meeting times, but virtually no
>discussion of accurate location information.

The reason for this, I hope to show in this message, is that *seperate*
location information is not a needed component of a calendaring or
scheduling protocol. As some of us brought up during the meeting, a
location of an event is not a property of the event, but is much more
simply expressed as a resource of the event, like an overhead projector or
a computer.

>Bill Spencer treated timezones
>pretty carefully in the SWTP spec, and with recurring dates and all, it's
>pretty clear that they need to be carefully considered.

That's right. But this is because *time* is the important item of
information. We often express times in local time and therefore need
timezone information to convert it to something useful. But it is not
location which is important here, but the ability to calculate absolute
time.

>However the only
>real location tags I remember seeing are the LOCATION properties in SSTP and
>SWTP (both free-format text fields) and the GEO field in vCalendar (which
>takes a lat/long tuple).
>
>Neither of these is adequate for a number of reasons:
>
>    1. Lat/long information isn't enough to infer timezones because people
>    at various places in the world have adopted different ideas about the
>    correct relationship between the Earth's lines of longitude and the
>    clock on the wall.  Simply put, there are some pretty daft people out
>    there pushing the boundaries around.  (Take a look at the world map in
>    the front of your handy-dandy "Rand McNally Comprehensive World Atlas"
>    if you think I'm kidding.)

But no location information solves this problem anyway, at least in the
absense of a rather extensive database which would need constant updating.
People not only have adopted different ideas about geographical time zones,
but they change those ideas at assorted times in history. Location
information by itself does nothing at all to determine time information. It
is time zone information that must be encoded in the times of the event
itself.

>    2. Many applications that will want to interface to calendar systems
>    (like our event calendars, Musi-Cal and the Internet Conference
>    Calendar) will place as much emphasis on location as time.  It would be
>    a shame to think that that basic events could only travel one way
>    (toward calendar systems) because loss of information prevents it going
>    the other direction.

Again, as was said in the meeting, it is only an accident of the types of
events you deal with that they always involve a location to which all of
the participants must go. In most of the events I am involved with (like
phone conferences), a location is not part of the event; there are several
locations over which the event takes place. Certainly for to-do items,
location is never at issue. Location is a property of a particular
participant at a particular event.

>    3. People will think up all sorts of different ways to enter information
>    in free-format location fields so people trying to parse them will
>    invariably run into snags.  (Believe me, I squeek from experience.)

That *may* argue for (as Roland mentions) location information being
formally defined, but only in the attendees list for the event. It does not
indicate that we need a machine parsable location for the event.

>    4. There seems to be an implicit assumption that events are entered
>    one-by-one.  We get information in huge batches sometimes, often with
>    varying degrees of consistency.  I have never seen concert or conference
>    listings that indicated timezones.  Most listings don't even give event
>    times.  It's impossible in most cases to add timezone information
>    manually because of the sheer volume of data we deal with, and for most
>    purposes it's pretty irrelevant.  Inferring it from accurate
>    city/region/country information is the only chance of being able to feed
>    it to calendar software.

a) You need to find out the location of the venue for your sorts of events,
and that is simply a participant in the event.

b) Even with the city/region/country information, you will not be able to
figure out what time the event takes place at without a current database of
time zones and daylight savings time rules. Having tried to build such a
thing for a long time, I can tell you from experience that you will find it
impossible to keep one up to date and universal.

>    5. Finally, event location will take on greater and greater importance
>    as scheduling reaches out beyond small groups to encompass organizations
>    that are geographically dispersed.  No longer will it be sufficient to
>    indicate "Mozilla Room" as the sole indicator of a meeting's location.
>    If I add a conference in Miami, Florida to my scheduler it's not too
>    wacky to think it should automatically add a to-do for two weeks prior
>    to the conference as a reminder to book my super-saver tickets.

Actually, the geographical dispersion argues more against having a single
location field in an event. More and more people will be having
teleconferences where locations will be multiple.

I urge that we don't go down this path. Location for an event is a property
of a participant. Making it a property of an event will cause many more
problems than it will solve.

pr

--
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980

Usage Scenarios...

Ignoring content for a moment, the CSA exercise provided a number
of useful lessons for generating an acceptable standard in this
field based on existing industry practise.

One of these was our listing in plain view during meetings
a small (four to six) set of user scenarios that embodied all the
major requirements.  They were abstract enough not to preclude
anyone's existing implementation, but realistic enough to serve
as a checklist for each point discussed as we went through the
material and built the spec.

This had the additional benefit of freeing us from our
previously overlapping, but incompatible, calendaring lexicons.
We could just reject a proposal (etc.) by saying "that breaks
scenario number three".

Given the large number of participants in the current effort, and
the confusion we're already seeing over terminology and how to express
requirements, a reference document listing all the scenarios we are
agreeing to address in this effort would be a useful tool for the group.

I'll volunteer to start this off and find a home for it in the right
document if I hear some support for it.

Dave.

Re: Usage Scenarios...

I will appear to be a voice from out in left field in this list, but I
want to comment that documenting these scenarios is a critical part of
what I call "PreStandards Work" where-in an abstract model of the
domain of interest is developed and documented, and from which overall
requirements can be drawn.

Until such a model and requirements are in hand, it will not be
possible to do any useful engineering of the desired Internet
Protocols.  Among the things to do is reconfirm that the scenarios so
far identified are really the full set.

I want to endorse this effort and offer to assist in any way I can.

Cheers...\Stef

>From your message Sat, 03 Aug 1996 23:28:41 +0100:
}
}Ignoring content for a moment, the CSA exercise provided a number
}of useful lessons for generating an acceptable standard in this
}field based on existing industry practise.
}
}One of these was our listing in plain view during meetings
}a small (four to six) set of user scenarios that embodied all the
}major requirements.  They were abstract enough not to preclude
}anyone's existing implementation, but realistic enough to serve
}as a checklist for each point discussed as we went through the
}material and built the spec.
}
}This had the additional benefit of freeing us from our
}previously overlapping, but incompatible, calendaring lexicons.
}We could just reject a proposal (etc.) by saying "that breaks
}scenario number three".
}
}Given the large number of participants in the current effort, and
}the confusion we're already seeing over terminology and how to express
}requirements, a reference document listing all the scenarios we are
}agreeing to address in this effort would be a useful tool for the group.
}
}I'll volunteer to start this off and find a home for it in the right
}document if I hear some support for it.
}
}Dave.
}
}