Subject: capreq questions

From: "Mark D. Anderson" <[email-masked]>
Date: Sat, 21 Nov 1998 11:07:00 -0800

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: [email-masked] (Steve Mansour)
Date: Sun, 22 Nov 1998 20:39:33 -0800

Mark,

Thanks for the feedback. Comments below.

-Steve

> draft-oleary-icap. Is that latter document being thrown out?

ICAP is a personal submission from Pete O'Leary. It has been around since before
ICAL. The CAP requirements define the problem CAP is trying to solve. We'll write
CAP to address the requirements.

> CAP and ITIP.

You are correct. We have to make this clearer.

ITIP is an interoperability protocol. It allows you to publish events, invite people
to events, respond to events that you've been invited to, and ask for free-busy
information. ITIP does not address operations such as creating or deleting a
calendar, nor does it address operations such as requesting events from a calendar
(by UID, by a range of time, or by any search criteria). Operations such as these
must be addressed in CAP.

> How do delegates differ from proxys?

Delegates are those whose attendence to a VEVENT or VTODO has been assigned by
another ATTENDEE.  That is, I can't make it to the meeting so I delegate my presence
to a coworker.

Proxys (sometimes called "designates") are calendar users who are authorized act on
behalf of another calendar user.  That is, my admin can make meetings for me and
accept and decline meetings I've been invited to.

We have a definitions section in the new CAP requirements that may answer a few
other questions.

> perhaps we should disallow the "CS" acronym and use longer ones?

The definitions in the new CAP requirements draft will help out. We've made every
attempt to be precise. We typically use "CS" to mean "calendar store".

> really have to do with ID's or resources.

The current data model of a "calendar store" allows for calendars to contain other
calendars. We should have a nice gif image of the calendar store data model up on
the web site at imc.org sometime this week. We'll put a character version of the
image into the cap rqmts, but the gif image is better.

> this is really a change of id?

You are right on the money. As things are proposed now, the "name" is a property,
and it is simple to change without affecting the components contained in the
calendar. The CALID is a uniquely identifies the calendar and is distinct from the
calendar name. As this issue is very important in both IRIP and CAP, we'll have a
separate draft, *very* short, that details how calendars are identified.

> need the complexity of interconverting between two addressing

There is still an issue surrounding hierarchical names. This much is true: you can
do any operation with the CALID. We are very interested in everyone's thoughts on
this topic.

The issue surrounding hierarchical names boils down to a disagreement over adding
any sort of semantics to the "relativeCALID". In the qualified CALID
"cap:/cal.x.com/example/1234", The relativeCALID is "example/1234". In particular,
the concern is over whether or not there should be a "separator" character. One side
of the issue is that there should be absolutely no symantics associated with the
relativeCALID. The other side would like to add symantics by introducing a separator
character to indicate hierarchy.  In other words, one side of the issue is
"example/1234" is simply a string (much like a UID in ICAL), it has no meaning, it
is simply a unique identifying string on cal.x.com.  The other side of the issue
argues for a separator character used to indicate hierarchy. In this case, if the
separator character for relativeCALIDs was "/" then the relativeCALID "example/1234"
refers to a calendar named "1234" which is a subcalendar of "example".

What do others think about this?

> created/deleted/changed since the last sync.

No, this is not our assumption.

> 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

> getting the result of possibly multiple changes sent to me wholesale)?

We brought up many of these issues. The bottom line is that we do not want CAP to
answer them definitively simply because we do not believe there is any one correct
way to answer these questions. We are leaving it up to the CUAs to handle
synchronization. We've tried to word the requirements to say that CAP must provide
sufficient functions to support a CUA that wishes to do synchronization work.

-Steve

---

From: "Pete O'Leary" <[email-masked]>
Date: Mon, 23 Nov 1998 16:04:59 -0800

Mark,

ICAP is my own personal submission, dating back almost 2 years. The WG has
not yet taken up the issue of whether ICAP will be a good basis for CAP, but
my personal belief is that it's a darn good start. ;-) It's interesting to
me that capreq describes requirements that ICAP knocked out a long time ago.
I will be preparing a document that described how ICAP meets alot of
capreq's requirements today, but I didn't get it done in time for Orlando.

In any case, ICAP will not be "thrown out": I intend to keep the document up
to date and even incorporate new features to address the WG's requirements.
The reason for this is that ICAP is actually in use within my own company
and several of our customers as well. There are at least two implementations
that I know about and they seem to work just fine, so ICAP will stay alive
for the forseeable future.

Pete.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Mark D. Anderson
> Sent: Saturday, November 21, 1998 11:07 AM
> To: [email-masked]
> Subject: capreq questions
>
>