Subject: Re: CAP: Filing of components

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 01 Nov 2001 10:59:23 -0500

Bernard Desruisseaux wrote:
>
> CAP doesn't allow calendar users to move components between
> calendars.  Currently, the MOVE command can only be "used to
> move a calendar within the CS's hierarchy of calendars".

Can we close this issue by simply modifying the MOVE
command to allow calendar users to move components
between calendars?

To modify the MOVE command as such, I propose the
addition of a DESTINATION property to specify the
address of the calendar into which components should
be moved.

Furthermore, I propose to use a VQUERY component to
select the components to be moved.  To stay consistent
with the READ command, the VQUERY would perform its
selection on all the TARGET(s) specified in the VCOMMAND.

Here's two examples:

#
# Move the event with the UID "[email-masked]"
# currently stored in the calendar "relcalid-source"
# into the calendar "relcalid-destination".
#
BEGIN:VCALENDAR
VERSION:2.1
BEGIN:VCOMMAND
METHOD:MOVE
DESTINATION:relcalid-destination
TARGET:relcalid-source
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = [email-masked]'
END:VQUERY
END:VCOMMAND
END:VCALENDAR

#
# Move the agenda with the RELCALID "relcalid-agenda"
# currently stored in the calendar "relcalid-source"
# into the calendar "relcalid-destination".
#
BEGIN:VCALENDAR
VERSION:2.1
BEGIN:VCOMMAND
METHOD:MOVE
DESTINATION:relcalid-destination
TARGET:relcalid-source
BEGIN:VQUERY
QUERY:SELECT * FROM VAGENDA WHERE RELCALID = 'relcalid-agenda'
END:VQUERY
END:VCOMMAND
END:VCALENDAR

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 1 Nov 2001 11:15:46 -0600

In looking at this a few questions come to my mind as a vendor considering
implementing CAP.

1 - does this add another layer of security complexity that I must negotiate
and handle?

2 - What defines a valid "DESTINATION" - at the very least this would need
to be clearly spelled out

3 - Within a specific CS I am comfortable that UID's assigned will be
unique, that I can validate users, that I can manage access rights to each
calendar etc. - when it comes to a separate CS - I become somewhat less
confident - what needs to be negotiated between the two CS to handle a MOVE
command as proposed cleanly?

	- CS & CSofDestination must agree on access rights (to the old Calendar and
the Destination Calendar)

	- CS & CSofDestination must agree on uniqueness of component being moved -
i.e. there must be some means to handle a message from CSofDestination
"already here"

	- Should this be a "Transaction" - i.e. what happens on error conditions -
when is the "moved" object REMOVED from the original Calendar? Within one CS
I as a vendor can take steps to ensure transactional integrity within
actions on that server - but as soon as I am negotiating a transaction with
another server it is a more complex action.

	- Can a MOVE command happen via another means? i.e. can (should?) it be
possible via email (iMIP) - my initial reaction would be NO - but it does
raise questions

4 - logically what is happening if a component is moved from one calendar to
another? Does this trigger another round of messages if the component in
question is a meeting? i.e. what is the difference between DELEGATING the
meeting to another ATTENDEE and MOVEing the meeting component to another
calendar?

5 - Are vendors in fact implementing and using Parent/child relationships
between Calendars? My rough reading of CAP was that MOVE was intended to
move whole Calendars within hierarchies of calendars - i.e. a command to
modify the PARENT and CHILD fields. However I have not seen well detailed
and documented examples of how these are intended to be used.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bernard
Desruisseaux
Sent: Thursday, November 01, 2001 9:59 AM
To: [email-masked]
Subject: Re: CAP: Filing of components

Here's two examples:

#

#

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 02 Nov 2001 17:05:15 -0500

> to be clearly spelled out

DESTINATION would have the same value type as TARGET.

> possible via email (iMIP) - my initial reaction would be NO - but it does

The first version of CAP will not address issues related to fanout.
Thus, TARGET and DESTINATION will have to be local calendar addresses.

> meeting to another ATTENDEE and MOVEing the meeting component to another

See Doug's previous posts on this thread.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Recherche et développement              Tél.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Fri, 02 Nov 2001 15:45:59 -0700

> See Doug's previous posts on this thread.

! Lay it on me :-)

The discussion was the lack of the ability for a CU to move an entry.
As you can not be logged in twice in the same session, this would
mean that you have exactly the same access as you would have before
this existed. No permission gained, none lost. I don't think there
are any security issues.

This (As I understand it) allows you to move an entry from one of
YOUR calendars to another of YOUR calendars (in the same CS).
I guess the DESTINATION could be any calendar for which the CU
has access already (on the same CS).

Issues (which MUST BE added to CAP if this is agreed to):

1) The CS implementation MUST do (a) or (b) .IF. the ORGANIZER's
   is moving the reply-to (cal-address) entry:

	(a) Transparently allow users to continue to have access
	    to the same entry as if it had never changed via
	    the UID for the entry. The CS could do this without
	    the CUA ever knowing the OWNER move the entry to
	    there preferred calendar. Note: A CS ~could~ have already
  	    implemented this - it is not dependent on the DESTINATION
	    addition.

        (b) Notify the users of an update to the cal-address
	    for the event using the iTIP update method. The UID
	    MUST remain the same. NOTE: This is nothing new, if
	    you caged your ORIGANIZER:cal-address, you had to
	    notify them already. Via UPDATE.

   One of these two MUST BE done or the iTIP portion of CAP breaks.

2) If the ATTENDEE's entry is changing in the ATTENDEE's calendar,
   any updates to the entry MUST ether:

	(a) Be transparently handled.
     or
	(b) The ATTENDEE MUST notify the ORGANIZER of new 
	    ATTENDEE:cal-address, followed by a REFRESH.

   NOTE: (a) Could have already been done in an implementation.
         (b) Would have to be done anyway for iTIP to work.

> > and documented examples of how these are intended to be used.

I don't think it adds any requirements to a CAP server, other
than allowing a CU to move the CU's entries to any calendar
on the same CS where the authenticated user already has access.

I think this is a recognition that we missed this as an issue.
If someone deposits a entry in one of YOUR calendars, and you want
it in another of YOUR calendars on the same CS - there was no way
to do this. With this there is. You could have parent/child calendars,
you could have peer calendars. Ether way, the OWNER of the calendar
should be able to re-organize their own calendars.

-Doug