Subject: Minutes from Wednesday's meeting

From: Bob Mahoney <[email-masked]>
Date: Thu, 21 Nov 2002 09:38:21 -0500

Calendar & Scheduling Working Group minutes, Wed Nov 20
reported by Larry Greenfield <[email-masked]>

Bob Mahoney is chairing.

. Chair, introduction & agenda bashing

. Chair, status of drafts

CAP is very long lived and still changing. More eyeballs are needed
and encouraged! xCal has been in and out of the working group. We
didn't want to get distracted from our major goal (CAP) but maybe it's
possible for us to do work on xCal without getting too distracted.

. Chair, interop results

Novell intended to hold a physical interop, but not enough
participants would have been able to come. Instead a virtual interop
was held with IBM/Lotus, Oracle/Steltor, Novell, and KOrganizer
participating: exchanging calendar objects and participating in
conference calls.

We need a better feature matrix if we want to move iCal to draft;
anyone interested in doing so should volunteer.  Drop a note to the
chairs if you would like info on how to help.

. Chair, point of information

There's a Java iCal parser at
http://www.sourceforge.net/project/jical/.

. Pekka Pessi, iTIP SIP binding "iSIP"
draft-pessi-calsch-isip-00.txt

iSIP currently uses xCal ("it seemed like a good idea at the time")
but the iCal format might actually be more extendable and more suited
for our purposes.

iSIP doesn't conflict with the current calsch work. Should it be part
of calsch? What interesting applications are enabled by iSIP?

The chair pointed out that the WG is already way overdue on some
milestones so it might not be that wise to take more stuff on. Paul
Hill asked why this wasn't being done in SIPPING; Pekka replied that
SIPPING is very crowded and has many requirements and the calendar
expertise is here. Aki Niemi thought that SIPPING had shown some
interest.

Chris Newman pointed out that there needs to be applicability of when
to use iSIP instead of or in addition to iMIP and iRIP.

. Chair, mailing list

The mailing list can seem unfriendly or imposing but don't let us old
bitter people scare you. Please participate!

. Chris Newman, some issues with CAP

Issue #1: How are calendars named and how do clients discover
calendars available. Clients need to be able to find out what
calendars it can access: private, shared, and public calendars.

Larry Greenfield and Paul Hill discussed that this was brought up some
time ago, and Paul talked about how the various subscription models of
the calendars can be fairly confusing. Disagreements about what the
namespace is makes coming to consensus hard. Chris pointed out that
the mailbox namespace is one of the worst parts of IMAP
interoperability, and committed himself to drawing an analogy between
IMAP and CAP namespace on the mailing list.

Issue #2: What should the mandatory to implement security be? Chris
recommends requiring implementations support TLS with the SASL
mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt
Zeilenga agrees.

Issue #3: Multiple connections versus BEEP channels. The current draft
doesn't discuss whether servers have to process channels in parallel
or if processing on one channel can block the other channels. If
clients only make a single TCP connection, rate limiting and other
accounting is much easier---but if clients have to open multiple
connections to keep long running operations from blocking, they
will. Larry Greenfield said that requiring parallel processing of
channels is a barrier to implementation and it isn't clear how to
write an on-the-wire specification requiring it. Some discussion on
Jabber with Marshall Rose and Larry Greenfield.

Patrick Falstrom said that understanding congestion control/resource
allocation on the application layer is a general concern for the IETF
but no one has any good ideas.

Issue #4: Round trips are very expensive; pipelining should be
mandatory.

. meeting adjourns

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Nov 2002 09:30:31 -0700

> possible for us to do work on xCal without getting too distracted.

To subscribe send email to [email-masked]' with
a subject of 'subscribe xcal-dev'.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Nov 2002 09:37:50 -0700

> calendars it can access: private, shared, and public calendars.

I think that the IMAP model and CAP model differ in this way.
With IMAP - the spec specifies that INBOX will always exist (I think).

There is also RFC-2739 ( Calendar Attributes for vCard and LDAP )

> IMAP and CAP namespace on the mailing list.

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Nov 2002 09:42:53 -0700

> mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt

I thought that we were told by the IESG that we MAY NOT use PLAN
as the default.

We used to have SASL/PLAIN - and were told NO by the IESG.
Then we migrated to BEEP - and PLAIN was still out.

Has the IESG changed the policy?

The IMAP WG reciently had a request from the IESG NOT to use
plain in one of its newer drafts that they wanted to go to
proposed standard status. As I recall the discussion, the only reason
that the IESG said yes to IMAP-PLAIN - was that it would break all (many?)
existing IMAP implementaitons and that they needed more time to transisition.

CAP - does not need any transistion time as there is nothing
to transistion from.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Nov 2002 09:51:26 -0700

> Jabber with Marshall Rose and Larry Greenfield.

We DID have this discussion - when we moved from pre-BEEP to BEEP.
We used to have some kind of parallel processing and we had an attribute
of CAPABILITY to specify how many parallel operations were possible.
Then we changed to BEEP - simply allow or do not allow a new channel.

 > Issue #4: Round trips are very expensive; pipelining should be

That is the advantage of BEEP. If the CS (for example) can handle
multiple parallel commands - then the CUA can send multiple in parallel
each on a separate channel. If the CS can not handle those parallel
commands then it should not accept the new channel open request.

I think we have already addressed this issue.

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 21 Nov 2002 12:02:57 -0500

The issue is that PLAIN is not in isolation. TLS gets started, and then a
username/password can be sent over the encyrpted channel.

If we specify digest, sites that have existing authentication systems still
have a problem on how to adapt their existing systems.

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 21 Nov 2002 12:07:09 -0500

Hi,

Chris pointed out that although BEEP provides for mutliple channels over a
single connection, nothing mandates it. If a client implementor decides to
use only a single BEEP channel and then open up a new connection for each
operation that they want to perform in parallel, we loose much of the
benefit of BEEP.

The draft should have some langauge about this. We really don't want clients
that open up a large number of parrallel connections.

Chris offered to take a stab at some suggested text.

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 21 Nov 2002 17:12:51 -0500

> Then we changed to BEEP - simply allow or do not allow a new channel.

Right, the question is whether we can require high quality implementations 
of BEEP that will correctly parallize different operations.

> I think we have already addressed this issue.

It's mostly an issue to make sure that common operations won't have the 
client make a query, wait for the response, then based on that information 
make another request. If there are obvious synchronization points that can 
be removed it's always a good thing to do so. I'll try to look for this on 
my next reading of the draft.

Larry

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Nov 2002 16:31:17 -0700

Lawrence Greenfield wrote:
> 
> --On Thursday, November 21, 2002 9:51 AM -0700 Doug Royer 
> <[email-masked]> wrote:
> 
> Right, the question is whether we can require high quality 
> implementations of BEEP that will correctly parallize different operations.

If a CS can only do one thing at a time, it should not open
up the other channels. If it does allow multiple channels to be
opened up and then performs them in first come basis. Then
the there is no way that I can think of for a CUA to send a 2nd
command which had results in it from a 1st command that has not
yet returned. I do not see that that problem can ever exist.

The only way that parallel operations can be performed and
not serialized by the CUA is when the commands from the CUA
are independent of each other from the CUA's point of view.

I do not think it is a protocol limitation or issue. I will
depend on the CUA implementation.

> client make a query, wait for the response, then based on that 
> information make another request.

That would be a CUA implementation issue, not a protocol issue.
If a CUA needs the results of one operation in order to start
another operation then it will need to wait for the data no
matter if the CS can performs parallel commands or not.

There are common operations where the CUA will have to wait.
An Example is looking for a time slot to book a VEVENT. The CUA
is going to have to get the VFREEBUSY and then deposit a BOOKED
or UNPROCESSED entry into the CS. I am sure there are many more
examples.

Parallel example: If a CUA were to search for available time slots common
to multiple calendars, then the CUA can perform multiple queries, each to a
separate calendar, process the results, then do parallel store operations in 
multiple calendars. If the CS can only do one thing at a time, then
the CUA is simply going to get the results one at a time.

If a CS does not allow a new channel to be opened, then the CUA
is already going to have to wait for an already opened channel
to finish so that the command can be sent.

As I understand BEEP - that is what BEEP does for us. It gives us
a predefined way to do (or not do) parallel operations. The CS
will or will not perform those operations in parallel. The CAP
protocol does not need to change. Pipelining will not have any
advantage if you can already perform multiple commands each in
a separate channel. And when the CS can not do parallel commands,
then BEEP still works, its just that the responses will always
be in the order the CUA sent the commands independent of the
channel.

 > If there are obvious synchronization
> points that can be removed it's always a good thing to do so. I'll try 
> to look for this on my next reading of the draft.

--

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 22 Nov 2002 12:06:46 -0500

Date: Thu, 21 Nov 2002 16:31:17 -0700
   From: Doug Royer <[email-masked]>
[...]
   That would be a CUA implementation issue, not a protocol issue.  If
   a CUA needs the results of one operation in order to start another
   operation then it will need to wait for the data no matter if the
   CS can performs parallel commands or not.

There are obviously protocol designs that can exacerbate or minimize
the roundtrip problem. The feedback in the WG meeting is merely that,
when possible, CAP should attempt to minimize roundtrips needed for
common operations.

This is not specific criticism of the protocol as written, just
general guidance of things that have bitten us in IMAP.

Larry

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Nov 2002 11:28:12 -0700

> when possible, CAP should attempt to minimize roundtrips needed for

Thanks - What are these obvious design issues in CAP?

> general guidance of things that have bitten us in IMAP.

That fine - but posting that you think that there might be some
obvious issues with no instances cited - only leads me to think that
you are not sure if your are correct with respect to CAP.

--

---

From: Gary Frederick <[email-masked]>
Date: Wed, 27 Nov 2002 07:03:20 -0600

FYI

> possible for us to do work on xCal without getting too distracted.
trim

The Mozilla Calendar uses a version of xCal in the import/export filters. Works well, easy to dance with, will be on more and more desktops as time passes.

Gary