Subject: CAP: Filing of components

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 05 Oct 2001 08:39:44 -0400

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".

If calendar users use multiple calendars for filing purposes,
it is not clear that they will want to let other calendar users
choose which calendar to address their scheduling commands to,
since they won't be able to moved the components in the calendar
of their choice afterwards.

Although calendar users could use access rights (VCAR) to control
which calendars other users can address their commands to, that
would only allow filing based on users.

I understand that allowing users to move components between
calendars would prevent other calendar users to find these
components directly in the calendars they expect.  Obviously,
it wouldn't be reasonable to notify other calendar users each
time a component is moved between calendars, but on the other
hand, what would be the usefulness of specifying the calendar
address of ATTENDEEs in VEVENTs if one can't rely on them?

I would like to propose the addition of a new container, say
VFOLDER (for lack of a better name), to allow filing of components
within calendars, in such a way that moving components between
these new containers would not change the calendar address where
these components can be found.  The MOVE command would have to be
changed to allow components to be moved between these new containers.

Scheduling commands could be addressed to calendars only, while
calendaring commands could be addressed to both calendars and
VFOLDERs.

Calendars and VFOLDERs could both contain other VFOLDERs but not
other calendars.

The addition of this new container will probably reduce the
number of calendars a user may want, and consequently expose
to other calendar users, which will reduce the confusion that
may arise when a calendar user want to invite a calendar user
that has multiple calendars.

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

---

From: Doug Royer <[email-masked]>
Date: Mon, 08 Oct 2001 15:06:36 -0600

You invite users, not calendars. If a user had multiple
calendars, they would have to specify their preferred
calendar. This is no different than email. If you have
more than one email address, persons wishing to reach you
need to know where to send the email, or they may email 
to all of your addresses.

Failing that (read included text below):

> move a calendar within the CS's hierarchy of calendars".

True, as a MOVE could not be done across calendar stores,
perhaps across vendor implementations, firewalls, domains, ...
(The same EFFECT is still possible - see my reply below).

> of their choice afterwards.

Yes and No.  Perhaps the user only has access to your company
calendar (company-cal). You however keep everything impotant
to you on your ISP provided personal calendar (my-cal).

There are two kinds of entries. Those made by the owner and unprocessed
invitations deposited by non-owners. The unprocessed invitations
are initially not committed to by the calendar owner/user they
are simply stored there until processed by the calendar owner.

So, if someone drops a calendar appointment request (METHOD == REQUEST)
asking you to attend the school play into your work calendar (company-cal),
your USER AGENT assumes the responsibility (with user input) to determine
what to do, which might be:

	(1) Decide if you wish to attend. 
		(1.a) No - delete it.
		(1.b) Yes - go to (2).

	(2) Copy the entry into YOUR preferred calendar (my-cal).
	(3) Delete it from company-cal calendar.
	(4) Reply (METHOD == REPLY), and confirm you are attending.
	    Setting you REPLY-TO value to be 'my-cal'.

Your UA will have to look into all of your calendars for legitimate
invitations anyway. And you UA will have to be able to create new
entries anyway. No new CAP code needed.

Does this address your issue?

> would only allow filing based on users.

Which may also be all you have if all your friends and busisness
associates do not have a username/password to all of your calendars.
Or if some are behind firewalls and have limited access.
For example, you PUBLIC-calendar may be outside your firewall
and you personal-calendar may be inside a firewall. Then they
could only make requests to your PUBLIC-calendar

> address of ATTENDEEs in VEVENTs if one can't rely on them?

At the time you METHOD == REPLY to an entry from someone else,
it MAY include a reply-to paramater which CAN BE a CAP address.
That is how they are informed on how and where to send updates
to you/your calendar.

If YOU invide people to an event, THEN IF 'YOU' move the event's
calendar, then YES YOU MUST notify them, or else they can not reply.
That is done with a METHOD == UPDATE.

> changed to allow components to be moved between these new containers.

Given what I said above, do you feel this is still needed?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 10 Oct 2001 17:39:10 -0400

Doug Royer wrote:
>
> You invite users, not calendars.

Calendaring and scheduling commands must be addressed to
calendars and not to calendar users, as VCOMMANDs apply
to calendars not to users.

To invite users, you must address a VCOMMAND to one (or
more) of their calendars by specifying a calendar address
in the TARGET property.

> If a user had multiple

But currently, users willing to file their components in
different containers will end up with many more calendar
addresses than email addresses.

In the case of email, messages sent to your email address
are delivered by SMTP to your mailbox.  In addition to this
mailbox, which is considered to be your primary mailbox,
known as your "INBOX", IMAP allows you to have a hierarchy
of mailboxes to file your messages as you want.

We must notice that SMTP is not aware of all these other
mailboxes (e.g., a user cannot send you a messages directly
to one of your IMAP mailbox).  Moreover, you don't get a
new email address each time your create a new IMAP mailbox.
IMAP has no notion of email addresses (other than the fact
that messages contain email addresses in their header).

The same way SMTP only has access to your primary mailbox
(i.e., INBOX), I've proposed to limit scheduling commands
to calendars, and the same way IMAP has access to your primary
mailbox and all your other mailboxes, I've proposed to give
calendaring commands access to both calendars and VFOLDERs.

> (The same EFFECT is still possible - see my reply below).

Currently, the MOVE command cannot be used to move calendars
across calendar stores either.  Since it has been decided that
the first version of CAP would not address issues related to
fanout, I don't see this has a big problem.  Isn't it acceptable
for the MOVE command to operate locally only?

>             Setting you REPLY-TO value to be 'my-cal'.

There is no mention of the REPLY-TO parameter in iCalendar
and the current CAP draft.  Could you provide us with more
information on how this parameter would actually be used?

> Does this address your issue?

I can understand the cost and complexity of moving component
between calendars, such as "company-cal" and "my-cal".  But
the goal of my proposition is exactly to reduce the cost
and complexity required when moving components only for
filing purposes.

Let's say that underneath my "company-cal" I have the sub-
calendars "team-meetings" and "boring-meetings".  Why would
I have to let everybody know that I moved a meeting from
"company-cal" to "boring-meetings"?  Even though relcalid
are supposed to be opaque, other users could probably still
be able to find the names of my calendar (i.e., "boring-meetings").

> That is done with a METHOD == UPDATE.

Moving a calendar within the CS's hierarchy of calendars
(i.e., not across CS) shouldn't affect the address of the
calendar.  So there is no need to notify the invited people
in this case.

> Given what I said above, do you feel this is still needed?

Yes. Given that scheduling commands are required whenever
a component is moved from one calendar to another, I don't
think that calendars are the right containers to do filing.
In my opinion, the way I file my components shouldn't have
any impact on other users.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 15 Oct 2001 18:28:41 -0600

> to calendars not to users.

Yes, but before you do that, you wanted to schedule with a
ATTENDEE, and you had to choose which calendar to select in
order to invite the user. (Work, Personal, Team,
Project, ...). And in the current world, you have to know
that information directly or by looking into some directory service.

> more) of their calendars by specifying a calendar address

Yes, but it must be a METHOD:REQUEST to invite the ATTENDEE.
And the ATTENDEE MUST BE known in advance. And the ATTENDEE
can be a calendar, email address, UPN, or whatever else is defined
as a valid ATTENDEE.

> addresses than email addresses.

Yes they can, but I suspect that calendar users that are
persons will consolidate the information into one calendar
or a few calendars that contains only things they care about.

> that messages contain email addresses in their header).

The calendering world is somewhat the opposite problem of email.
We export multiple calendars based on who the CU wishes
to see the calendar. I don't think that my customers want
to see my personal appointments. So I don't put personal
booked events into my public calendar. However the scheduled
and not booked events, could be placed into a non-personal
calendar and my CUA can then be directed to place them
in my personal calendar, accept, and update the SENT-BY
parameter in the ATTENDEE property.

If you choose to METHOD:CREATE, then YES you have to know the
exact name of the calendar and you have to have permission
to book an event.

However if you METHOD:REQUEST, it only has to be in any calendar
available to the intended ATTENDEE for which you have
a METHOD:REQUEST VCAR. You DO NOT NEED to know the final
destination calendar as you are scheduling with the ATTENDEE
by using a specific calendar for which you know the intended
invited ATTENDEE scans. The CS for that calendar would have
to make sure that ATTENDEE has READ and DELETE or UPDATE permission
in that calendar in addition to the ORGINIZERs ability to 
do a METHOD:REQUEST into that calendar. Then it is a valid
scheduling request and may be stored. You, your CUA, or the
protocol does not need to know if it is the primary calendar
for the targeted ATTENDEE(s).

The difference between inboxes/folders and calendars is that
with calendars you can have a finer grain of access. I may
give anyone a VCAR to schedule in my ~top~ calendar.
And perhaps only my boss (and me) has the ability to book
in my work calendar. As he would not schedule with me,
he may just inform me of the events.

I would not want to give my boss an open VCAR to
write ANY component using a METHOD:CREATE into my personal calendar.
I could limit it to VEVENT or VTODO or whatever by correct usage
of a VCAR, but I can't control the intended content of the
VEVENT or VTODO using VCAR's. Plus the CUA used by my boss
might not be able to book the event if the CS's do not allow
overlapped booking - there would be no way for a boss to book
the events with possible conflicts on a large number of 
work calendars for multiple users. His CUA would be scanning
a large number of calendar, trying to book, only to find conflicts.
Only to find that no one is busy at 2-3am :-)

The only way to do this is to give the boss a calendar to book into.

> calendaring commands access to both calendars and VFOLDERs.

I don't understand, you can schedule (METHOD:REQUEST) any
calendar already. (You say: "I've proposed to limit...").

> for the MOVE command to operate locally only?

Fanout is orthogonal.

You can't move across CS's because it would require all kinds
of locking and access problems between the CS's that would have
to have an account/password between them, it would require the
CS's to spoof the other user ids, store (or temporarily lend) their
passwords (A BIG NO NO!), and then a complete recovery protocol
if things failed.

Are you assuming that all calendars (for the move) have the same 
login/password on the same host and in the same process? That
works now.

If they are not in the same process, you are doing part of fanout.

To move an event across CS's:
	copy the event.
	If it works, delete the old one.
	
	If the item is booked (vs scheduled), then send
	an updated METOD:REPLY with an updated SENT-BY in the ATTENDEE.

> information on how this parameter would actually be used?

Sorry, I meant the SENT-BY parameter to the ATTENDEE property.

That is the reason SENT-BY exists, to redirect the calendar items
back to the SENT-BY value for the ATTENDEE (or ORGANIZER)

And in CAP (or not yet in CAP :-), was the idea that we were
updating SENT-BY to be an email address, URI, or calendar.
As it is the ONLY way to update users of calendar name changes
for booked items and scheduled requests.

> be able to find the names of my calendar (i.e., "boring-meetings").

You don't have to let them know - IF all they are doing
is scheduling commands - are you busy - and maybe to find out why.
If they created the item in "my-cal" with a METHOD:REQUEST,
then you move it to "boring-meetings" and never tell them.
Because any update will go to "my-cal" and your CUA already looks
there and in "boring-meetings" (and all of your other calendars) and
it knows that UID:12345 is booked in "boring-meetings", your CUA can
acknowledge any update and never tell anyone. If you do want to
tell them update the ATTENDEE:...SENT-BY... in the METHOD:REPLY.

If you decided not to attend the meeting and do a METHOD:REPLY,
then the CU/CUA can keep it in the "my-cal" calendar, store
it in a hidden look-aside calendar used to store dead requests
for a while. It can be moved to "boring-meetings" and marked no, ...

If you are going to allow them to book the item, then
yes you MUST tell them the exact calendar name.

For the most part, only the CU/OWNER will do direct booking.

> calendar.  So there is no need to notify the invited people

It does if the move is to the ORGANIZERs calendar as the
ORGANIZER cal-address has changed which can be a CAP-address.
If you move item ABC from CAL-one into CAL-two. When the users do a
reply with a METHOD:UPDATE directed to CAl-one, it no longer exists.
The ORGANIZER MUST notify the ATTENDEEs of the change if it expects
any METHOD:REPLY. Which can be sent for ANY and ALL METHOD:REQUESTs,
so I would argue that if it is moved and the ORGANIZER address is
a CAP-address, then the ORGANIZER MUST update the ATTENDEEs.

Or it MUST BE done if you wish to redirect all updates to
a new cal-address and you are the ATTENDEE.

> any impact on other users.

It only has to care when they are doing direct booking. It does
not effect scheduling requests.

And as there MUST BE a way to do direct booking (or NO CUA could function),
don't invite ATTENDEEs and use non-scheduling CAP direct booking.
Use CAP-Scheduling methods (iTIP scheduling methods).