Subject: RE: capreq questions

From: Andre Courtemanche <[email-masked]>
Date: Sat, 21 Nov 1998 17:10:27 -0500

Mark, 

Here are the answers to your questions:

1-Relationship of CAP to ICAP.

ICAP was submitted by Pete O'leary as a private
proposal about 2 years ago. Because there were
many issues with the "calendar access protocol"
and because ICAP could not be used "as-is" it was 
decided to prepare a "Requirements document" 
before any protocol issue was to be discussed. 
The requirements document combines the experiences 
of many different individuals from many different 
companies. The result is draft document capreq-02.

2-Relationship to iTIP/iMIP/iRIP, and other issues.

iTIP defines an interoperability between different
calendaring systems, in a form independent of the
transport.  iMIP describes how a mail transport
would implement iTIP. In a similar fashion, iRIP 
describes a real-time transport for iTIP.  

CAP, as indicated in the capreq document, is a 
user-agent-to-calendar-store protocol. In the 
long run it should allow people to mix and 
match different clients with different servers. 

As for transport issues, your confusion may be 
coming from the fact that they have been dealt 
from a "requirement position" only, and not from 
an implementation point of view. 

Once there is closure on the requirements, the
group will move to actually define the transport,
addressing all the requirements previously put
forward.

3- In the document, the term CS has only 
been used to described "CALENDAR STORE", as defined
in the terms section of the document.  "CALENDAR SERVICE",
again from the definition section means an implementation
of a calendar store. The authors of the CAP requirement
document have been very careful to define all terms used
and if we have missed any, please let us know.

4. calendar hierarchy and sub-calendars.

Sub calendars are a way to organize data elements in 
a hierarchy manner. That is, a calendar can contains
components (Events, todo, journals, etc) as well as 
calendars. A use for this would be to store your
kids baseball games in a sub calendar to yours.  This
is *Very* similar to files and directory.

Inheritance is not defined as a requirement and is 
out of scope for the CAP definition.

5. calendar renaming (section 4.3).

A calendar as an object has properties, and one of 
them is the name. Renaming a calendar consists in 
changing the property value. There is no relationship 
between the Name of a calendar and the name of its 
parent. The only requirement on the relationship 
is that given a Calendar ID (CSID), the calendar store
must be able to retrieve the name.

The other important relationship is that the Name
of the Calendar is a human readable and localizable.

6. Name and ID's

CDID uniquely identifies a calendar in a calendar store,
whether that calendar is a "top-level" or "sub-calendar"
and operations are conducted using a CSID, not using the
calendar Name.

7. synchronizing objects vs. changes (section 4.5.2)

The requirement for CAP is to allow Calendar user agents
to be able to identify what has changed on a calendar,
that is, components that have been added/deleted/modified.

That information about the changed components can then 
be used by a CUA (calendar user agent) to synchronize 
two calendar stores, resolving conflicts by prompting 
the users etc.

It is not a requirement for CAP to automatically synchronize
two calendar stores.

Hope that helps

Andre Courtemanche
CS&T

-----Original Message-----
From: Mark D. Anderson [mailto:[email-masked]]
Sent: Saturday, November 21, 1998 2:07 PM
To: [email-masked]
Subject: capreq questions

I have not been on the WG mailing list long. I'm going off of
the published WG docs, and those have left me confused. This 
briefly summarizes those confusions. I'm confused enough that
I don't know if these are really CAP-specific or not :( -- but
nominally this is in reference to temp-capreq-02. 

1. relation to ICAP (draft-oleary-icap).
I see no mention in capreq of how that document relates to
draft-oleary-icap. Is that latter document being thrown out?
Re-thought? Or what?

2. relation to ITIP/IMIP/IRIP.
Neither section 3 of capreq nor the draft-ietf-calsch-mod document
is sufficient for me to understand the principled boundary between
CAP and ITIP. CAP has access control, and has provision for
scheduling on another user's calendar (section 4.4). That sounds a bit
like ITIP
to me. CAP has some vague adumbration of how synchronization among
CS's might be done, or between a CUA and a CS. Is that so different from
component exchange across users? How do delegates differ from proxys?
The whole protocol conception mystifies me, particularly when it comes
to transport layer proxying and authentication wrt to
transport-independent
delegation and authentication.

3. CS?
The phrases "calendar service", "calendar store", and "calendaring
system"
all have the acronym "CS". If those 3 things really are different, then
perhaps we should disallow the "CS" acronym and use longer ones?

4. calendar hierarchy and sub-calendars.
I can find no discussion of sub-calendars or calendar hierarchy in
the other documents. Even in capreq, I don't understand what the
intended semantic is. Is this a cascading model, where a child 
also shows its parent's events? Why do i need sub-calendars?
Or is this purely a lexical matter of syntax of the calendar id?
The notion smacks of webdav's muddle about "collections"; last
time I checked they are still trying to figure out whether those
really have to do with ID's or resources.

5. calendar renaming (section 4.3).
What is so significant about calendar renaming? Isn't that just
another property? Or does "rename" entail a move operation because
this is really a change of id?

6. hierarchical name and ids (section 4.4, 4.5.3, et al).
I can do any operation with *either* a "hierarchical name" or an ID?
What is a "hierarchical name"? It isn't in the "terminology" section.
Perhaps this is related to my incomprehension of sub-calendars.
Regardless of what it means, it seems to me unlikely that we
need the complexity of interconverting between two addressing
schemes?

7. synchronizing objects vs. changes (section 4.5.2)
It appears that there is currently a blithe assumption that
synchronization
is merely a matter of asking for all the remote components that have
been
created/deleted/changed since the last sync. What about conflict
resolution
for multi-master synchronization? Is there a merger of individual
properties?
Or does a single component from one of the two always win? What about
rules excluding time conflicts that would prevent the incorporation of
a component? What if I want to associate workflow triggers, checks, or
audit records with the individual change operations (rather than just
getting the result of possibly multiple changes sent to me wholesale)?

-mda

---

From: "Mark D. Anderson" <[email-masked]>
Date: Sat, 21 Nov 1998 16:35:49 -0800

Andre Courtemanche says:
>proposal about 2 years ago.
>...

ah. it would be helpful to indicate something about that
document in the capreq, since oleary's doc is referenced
on the WG home page, and those not "in the know" will
naturally want to know what is going on with it.

>match different clients with different servers. 

Yes, i picked up this much from the model doc.

What i'm debating -- and this must have been hashed
out before -- is whether there really is a coherent
distinction that separates the charters of the
two protocols (iTIP and CAP).

Maybe ITIP is supposed to be a transfer protocol,
and CAP an access protocol?
I know there is a semi-religious distinction between
transfer protocols (http, nntp) and access protocols
(ldap, imap), but i think that history mostly just 
shows that transfer protocols alone are insufficient
and end up growing into access protocols.
Furthermore, iTIP doesn't really seem to be a transfer
protocol anyway, but instead seems to be an attempt
at two-phase commit, except it isn't quite enough for
that, and has other stuff in it too (ADD, etc.).
(Is it just a coincidence that iTIP is a letter away from a
related protocol proposal, TIP?).

Given the intended wide spectrum in power of CUA's,
and the many-to-many connections possible between
CUA's and CS's, I'd be hard put to identify operations
that are meaningful only between CS's. Not that "CS-to-CS"
defines the charter of iTIP either.

Or maybe the difference is that if my CUA is talking to
"my" CS, it is CAP, but if my CUA is talking to "your" CS,
it is iTIP? This really doesn't seem coherent.

I guess I'm still confused.

>addressing all the requirements previously put

I get the model/transport distinction. That is one
of the things I like about what the WG has done so far.
I wish other WG's did this.

>and if we have missed any, please let us know.

And is a "calendaring system" the same as a "calendaring service"?

>out of scope for the CAP definition.

So the containment hierarchy has no semantics, and is
merely a lexical property of the identifiers?
Or is it just a lexical property of the names, and
not even the identifiers?
Could different users choose to arrange their hierarchy
differently, yet use the same ID's?

>must be able to retrieve the name.

That's what I figured; i was confused why this requirement
was drawn out as i didn't think of Name as being particularly
distinguished among the properties.

But maybe it is special after all because of this
hierarchical name business....

>of the Calendar is a human readable and localizable.

localizable by providing multiple values with different
lang parameters?

>and operations are conducted using a CSID, not using the

Huh? 4.4 says that CAP MUST specify "how hierarchical name [sic]
can be used for all operations ... any functionality which
could be done on a component or calendar by specifying the component ID or CSID,
MUST also be available by specifying the hierarchical name."

How is the "hierarchical name" related to the Name property?
Do components have hierarchical names (as implied above),
or only calendars and calendar stores? 
Why does the protocol need to muck around with addressing by
those pretty human readable names (which as you point out
aren't unique anyway, because of language variants)?

And who says a hierarchical name is readable anyway....

>It is not a requirement for CAP to automatically synchronize

There should be some discussion of how an automatic synchronization
could be done. In the end, for large organizations, an automatic
scheme is going to be almost mandatory because of the ensuing
help desk issues otherwise. Also, in many cases the end user isn't
the one who should be making the decisions about merger anyway,
because whatever the decision is, it has to result in an eventual
global consistency, which entails decisions for other stores.
That is why every large messaging system (Notes, etc.) as well
as every distributed directory system (X500, LDUP) has mechanisms for
automatic synchronization with rules/policies that are maintainable by
an administrator.

I might note also that IMHO retaining only 
mod times on components (the only requirement stated) throws
away too much information to do decent synchronization (that
is why LDAP and others have a change log).

-mda

---

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 16:51:40 -0800 (PST)

> From: "Mark D. Anderson" <[email-masked]>
> 
> >Andre Courtemanche says:

IETF WG submissions are named 'draft-ietf-*'.
Individual submissions are named 'draft-<last-name>-*'.

They were on the WG home page because they were submitted :-)

There can often be no relationship between drafts.

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL