Subject: 05 sendata -> beep.

From: Doug Royer <[email-masked]>
Date: Mon, 21 Jan 2002 15:16:37 -0700

In order to get things back to the way they were in 05, PLUS add BEEP.

I propose we replace the beep-cap-commands with <senddata/>
then restore all of the existing agreed on objects. Where
<senddata/> has an optional argument of 'letency' who's value
is in seconds.

Example:

C: MSG 1 8 . 124 234
C: Content-Type: application/cap+xml
C:
C: <senddata/>
C: <![CDATA[
C: BEGIN:VCALENDAR
C: METHOD:CREATE
C: TARGET:target...
C: ...
C: END:VCALENDAR
C: />]]>

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 22 Jan 2002 16:24:01 -0500

> C: Content-Type: application/cap+xml

Which problems in the current draft are you trying
to address?

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: Tue, 22 Jan 2002 15:39:01 -0700

> Which problems in the current draft are you trying

The task for 06 was to move the old CAP transport commands to
BEEP. However more than that was done. The problem I am addressing
is fixing that so that is all that was done. So the objects
are again 2445 compliant and can again (as was in 05) be sent
via iMIP.

---

From: George Babics <[email-masked]>
Date: Wed, 23 Jan 2002 15:47:07 -0500

> are again 2445 compliant and can again (as was in 05) be sent

  The task for draft-06 was to change CAP into a BEEP profile.

  And it is what was done. Certainly there are many ways of doing it.
The way that was chosen is in line with most of the BEEP profiles that
we looked at, that is, they all separate the commands from the data.

George

---

From: Patrice Lapierre <[email-masked]>
Date: 23 Jan 2002 16:12:57 -0500

> Bernard Desruisseaux wrote:
...
> are again 2445 compliant and can again (as was in 05) be sent

As far as I know CAP extensions to iCalendar, as defined in 
draft-05, could not be included in a valid iTIP objects, and 
this is not a requirement.

ITIP supports a finite set of methods, and RFC2446 provides 
restriction tables for them.  The restriction tables in iTIP 
do allow additional X-PROPERTYs and X-COMPONENTs, but do not 
seem to allow the addition of new iana properties or components. 

As such in iTIP:

 - A TARGET property cannot be part of a METHOD:REQUEST.
 - VQUERYs or VAGENDAs cannot be included in a METHOD:PUBLISH.
  
Furthermore naively sending the calendaring commands of CAP
through email would not work. Email has limitations that are
not present in a connection oriented protocol such as BEEP.
The limitations includes: lost of messages and messages arriving
in incorrect order. iTIP was design with these limitations in 
mind, the calendaring commands of CAP were not.

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Jan 2002 15:14:24 -0700

> this is not a requirement.

Not true on both. All of the METHOD objects can be transported
in iTIP (METHOD was invented for iTIP - not CAP). Which is why they
were METHOD's and not CAP commands. And the requirements doc DOES
specify that the objects are to be 2445 compliant. Same with TARGET,
it is a PROPERTY and NOT a CAP transport command so that it could be
transported via iTIP. And same with CMDID - and I just noticed
that it is also gone from 06, which was how you tied the object
replies back to the source (iTIP or CUA).

> seem to allow the addition of new iana properties or components.

NO - iTIP like iCalendar specified a specific set of components,
properties, and parameters. And the CAP requirements document
DOES specify that CAP may extend those objects. We separated
the CAP transport commands from the 2445 objects using METHOD,
TARGET, and CMDID.

> mind, the calendaring commands of CAP were not.

Loss of messages: If the CUA did not get them, the CS is not
going to get them - your CS better be able to handle that anyway.

Incorrect order: If the CUA gets them out of order, they may
be deposited out of order into the CS. If you CS can not handle
that it is going to be busted.

CAP supports iTIP, so an implementation that supports iTIP and CAP,
MUST support those features.

The objects are stored by the CS, the 'CUA' does the processing
of the objects - not the CS. So if the messages are lost or
out of order it has NO effect on a CS. The CUA decides when
the iTIP objects will be processed and collapsed or deleted
from the CS. Not there may be a CUA-bot that does it for a CU,
but that is still a CUA.

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Jan 2002 15:19:47 -0700

> we looked at, that is, they all separate the commands from the data.

06 BREAKS iMIP as it is written.

The instructions were to take TRANSPORT out of CAP and make it BEEP.
It was NOT to make iCalendar objects into Beep objects (new METHOD
values,
TARGET, and CMDID were iCalendar objects - not CAP transport commands).

The CAP 'COMMANDS' were (05):	

	ABORT			- now in CAP-BEEP   - GREAT
	AUTHENTICATE		- part of BEEP      - EASY
	CALIDEXPAND		- NOT in 06 at all  - and I don't care :-)
	CAPABILITY		- now in CAP-BEEP   - GREAT
	CONTINUE		- now in CAP-BEEP   - GREAT
	DISCONNECT		- part of BEEP - or is it MISSING?
	IDENTIFY		- now in CAP-BEEP   - GREAT
	SENDDATA		- NOT in 06 at all  - MISSING
	STARTTLS		- part of BEEP      - EASY

	UPNEXPAND		- NOT in 06 at all  - 
		The was determined needed as viewed by the WG as a
		way to expand a group-UPN into its list of users so
		the CUA could determine who (non-group UPN) the command
		would effect.

	NOOP			- now in CAP-BEEP

	GENERATEUID  Which was called a METHOD, but all of the
	             examples show that it was in fact a COMMAND
		     as it was NOT a valid value for METHOD, and
		     was not used inside any 2445 object. So I suspect
	             the title of the 05 section that was:

			7.2.1.4 GENERATEUID Method

		     should have been called:

                        7.2.1.4 GENERATEUID Command

And the CAP 0X-05 'METHOD's were (and need to be METHODs again
so the OBJECTS are 2445 compliant and can be iMIP'd)
These were all sent with the 'SENDDATA' CAP transport command
inside of 2445 objects:

	CREATE			- REMOVED in 06 as a value to METHOD
	MODIFY			- REMOVED in 06 as a value to METHOD
	MOVE			- REMOVED in 06 as a value to METHOD
	READ			- REMOVED in 06 as a value to METHOD
	TARGET			- REMOVED in 06 as a PROPERTY
	CMDID			- REMOVED in 06 as a PROPERTY

These were not accidentally placed into 2445 objects, it was
the result of a lot of debate and meetings. They need to be
moved back into 2445 objects.

Please note that METHOD's are NOT CAP TRANSPORT commands and
there was over a YEAR's worth of debate and agreements between
many to separate the TRANSPORT from the iCalendar objects data.
The net result of that LONG debate that took place on the list
and in several interim meetings was - that they would be separate.

Prior to 06, I could iMIP the objects to another CUA/CS and
things worked. I'll be sending out this weekend text proposals
that keep the CAP-BEEP commands (+ some suggested tweaks that
will reduce the byte overhead for slow connections - using CDATA) PLUS
text proposals for how to reinstate the CAP METHODS back into
the objects so that iTIP/iMIP again works.

Now I think that what I am proposing will not change anything
other than the CAP transport commands will be BEEP transport
commands. If I suspect otherwise - I'll specifically tag it.

-Doug

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 24 Jan 2002 09:04:19 -0500

> 06 BREAKS iMIP as it is written.

But this is not a requirement.  Here's what the requirements
document says:

> 3.      Relationship To iCalendar, iTIP and iMIP/iRIP
> 
>    The CAP data elements MUST be based on the calendar architecture set
>    forth in [ICAL]. More precisely, CAP will define an Internet protocol
>    for accessing a CS that consists of one or more calendars, each
>    consisting of numerous [ICAL] components. The definition of CAP might
>    necessitate adding components, properties, parameters and other
>    elements beyond those defined in [ICAL]. These additions MUST be
>    defined in a manner consistent with and upwards compatible to the
>    data model defined by [ICAL].
> 
>    Where it makes practical sense, CAP SHOULD make use of the scheduling
>    workflow defined by [ITIP].
> 
>    CAP will not require that [IMIP] or [IRIP] MUST be used to
>    communicate with other calendar users.

CAP does not require that iMIP be used, and CAP already
makes use of iTIP where it makes sense (i.e., scheduling).

Regards,
Bernard

---

From: George Babics <[email-masked]>
Date: Thu, 24 Jan 2002 09:16:12 -0500

>                 the CUA could determine who (non-group UPN) the command

  Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG.
  See:

    http://www.imc.org/ietf-calendar/mail-archive/msg02128.html
  
George

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Jan 2002 09:20:31 -0700

> makes use of iTIP where it makes sense (i.e., scheduling).

I strongly disagree. Several of us fought very hard to make
sure that CAP is 2445 compliant. They must go back in to the
objects.

As I said earlier - it is NOT an accident that the TARGET, CMDID,
and CAP - METHOD values were inside of the 2445 object.

And it was not an accident that sendata, generateuid, and the
others were cap-transport commands.

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Jan 2002 09:22:56 -0700

>     http://www.imc.org/ietf-calendar/mail-archive/msg02128.html

First - I really don't care if they are gone. I never saw that
they were needed.

Second - one company agreeing with itself it not really that
impressive of a reason :-)

---

From: George Babics <[email-masked]>
Date: Thu, 24 Jan 2002 11:43:39 -0500

> impressive of a reason :-)

This was agreed to, in a CAP conference call, by many people.
It was posted on the list to see if anyone else had objections
to removing them. No one else commented.

George

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Jan 2002 10:39:20 -0700

> This was agreed to, in a CAP conference call, by many people.

My apologies.

It was not my intention to say that it was not. It was my
intention to say that the email you pointed me to was that way :-)