Subject: Implementors' Guide

From: George Babics <[email-masked]>
Date: Fri, 09 Jun 2000 11:10:09 -0400

Bob, Alex,

  As you know "Implementors' Guide to Internet Calendaring"
has expired. I feel that it should be brought back to life.
It provides a useful introduction to the calendering standards
and points people to the documents they should know based on
their needs. The document can be further improved by providing
more examples, guidelines, open issues, information on what is
not covered by the standards, and so forth.

  As CS&T and others develop applications that support the
standards we can continue to update the document.

  If we do bring it back, we should do so soon so that we will
be able to discuss it in Pittsburgh.  There are a few small 
changes that I suggest, and a few questions relating to the 
document.

  First, we can consider removing references to iRIP. It
seems to me that everyone has lost interest in it.

  Secondly, in section 2.1, we can add an example of a person
using a calendar for his or her own personal use and accessed only
from one CUA. It can be something like this:

   A doctor wishes to keep track of all his appointments.

   Need: Read and manipulate one's own calendar with only one CUA.

   Solution: The doctor can use a proprietary CUA with a local store,
             and perhaps use [ICAL] as a storage mechanism.

   Even though it is the simplest need, and it does not require
the standards for a solution, it can be part of the section
titled "Fundamental Needs" since it is very fundamental (many, if
not most people's calendars are like the one in the example).

  Third, we can add updates of CAP to the draft. For instance,
we should mention in the Authentication section (5.2) that CAP
must use SASL as its authentication mechanism.

  Fourth, do we want to clarify or add to the intent of the document?
Currently its intent is:

   It is the intent of this document to provide guidance for
   implementors of calendaring and scheduling products in determining
   which of the various existing protocol documents are applicable to
   their work, as well as providing some background information and
   pointers to the less obvious implications of the available choices.

   (from the introduction of the draft)

   Do we want to make its intent to provide a guide to implementors,
such as provide information on issues, common mistakes or misconceptions,
things related to calendering that are not part of the standards
(such as synchronization), and so forth? After all, it is an
"Implementors' Guide."

  Fifth, are there other sections that we can add to the document?
Currently, there are sections on Requirements, Solutions, Open
Issues, and Security Considerations. For instance, we can add
a section describing why certain decisions were made during
the development of the standard.

  Sixth, the examples given in section 3.2, "Systems", can easily
be updated. By adding more examples, we can show the wide variety
of systems that can exist. These new examples, can include calendar
services, multi-user systems, CUA without local stores, fanout,
services communicating using iMIP, situations where a CUA may need
to synchronize its local store with that of one or more calendar
services. Some possibilities:

   Single-user with multiple CUA

   A single user may use more than one CUA to access his or her
   calendar. The user may use a PDA, a web client, a PC, or some other
   device, depending an accessibility.  Some of these clients may have
   local stores and others may not.  If they do, then they need to
   ensure that the data on the CUA is synchronized with the data on
   the CS.

              -----------
             |   CUA w   | -----[CAP]----------+
             |local store|                     |
        O     -----------                    ----------
       -+-                                  |   CS     |
        A                                   |          |
       / \                                   ----------
              -----------                      |
             |  CUA w/o  | -----[CAP]----------+
             |local store|
              -----------

   Single-user with multiple calendars

   A single user may have many independent calendars.  One may be work
   related, another for personal use.  The CUA may or may not have a
   local store.  If it does, then it needs to ensure that the data on
   the CUA is synchronized with the data on both of the CS.

                                             ----------
                   +------------[CAP]------ |   CS     |
                   |                        |          |
        O     -----------                    ----------
       -+-   |  CUA      |
        A    |           |
       / \    -----------
                   |                         ----------
                   +------------[CAP]------ |   CS     |
                                            |          |
                                             ----------

   Users communicating on a multi-user system

   Users on a multi-user system may schedule meetings with each other
   using [CAP]-enabled CUA and service.  The CUA may or may not have
   a local store.  If they do, then they need to ensure that the
   data on the CUA is synchronized with the data on the CS.

        O     -----------
       -+-   |   CUA w   | -----[CAP]----------+
        A    |local store|                     |
       / \    -----------                    ----------
                                            |   CS     |
                                            |          |
                                             ----------
        O     -----------                      |
       -+-   |  CUA w/o  | -----[CAP]----------+
        A    |local store|
       / \    -----------

  Users communicating through different multi-user systems

  Users on a multi-user system may need to schedule meetings with
  user on a different multi user system.  The services can
  communicate using [CAP]

       O     -----------                    ----------
      -+-   |   CUA w   | -----[CAP]-------|   CS     |
       A    |local store|                  |          |
      / \    -----------                    ----------
                                                |
                                              [CAP]
                                                |
       O     -----------                    ----------
      -+-   |  CUA w/o  | -----[CAP]-------|   CS     |
       A    |local store|                  |          |
      / \    -----------                    ----------

George Babics
Research & Development
Corporate Software & Technologies
3333 Graham Boulevard, 5th floor
Montréal, Québec, Canada
H3R 3L5
Tel: (514) 733-8500 x303
Fax: (514) 733-8878
E-mail: [email-masked]

---

From: [email-masked]
Date: Sun, 11 Jun 2000 15:45:39 -0400

Brush it off if you want...But having some general guidelines for the 
scope will avoid this long banter back and forth.
But I do agree with you that if folks have constructive input on "lessons 
learned" then we solicit their input.
-- Frank