Subject: CAP/BEEP content type.

From: Doug Royer <[email-masked]>
Date: Sat, 12 Jan 2002 12:31:38 -0700

As BEEP allows the 'Content-Type:' to be anything, why
not 'text/calendar' and just send iCalendar objects?

When we get XML-iCalendar out, then we can use that
content type?

I am going to send out some specific text that will be
my proposal for the 07 draft. It will include:

(1) Moving the data out of the transport and placing it
    back into the data portion. This includes returning
    the MODIFY command to what it was in 05.

(2) What I think are tweaks needed in order to get what
    I think has already reached consensus in the data
    sections into the draft. 

(3) Any additions I think I needed to understand 06.

(4) BEEP is great, I wish that we had this when we started.
    However BEEP does not require that all commands and data
    be in XML. I think that we should XML iCalendar after
    CAP is out, and then it should be fairly simple to
    put that into beep. I am interested in getting CAP out
    the door (AS ALL OF US ARE). So I am going to send text
    that I think is 05 + beep transport only.

I will not be offended if any, all, or none of it is used.

-Doug

---

From: George Babics <[email-masked]>
Date: Mon, 14 Jan 2002 11:22:55 -0500

> not 'text/calendar' and just send iCalendar objects?

  Other application protocols that use BEEP, separate the command from the
data, e.g., draft-ietf-apex-core-05.

  There are many advantages from separating commands from the data:

  - Reduce the coupling between CAP and iCalendar:
    less changes or extensions to iCalendar.
    For instance, previously we had many extra iCalendar properties
    such as VCAP, TARGET, etc.
  - More easily extensible. XML is easily extensible and less dependent
    on iCalendar.
  - Makes the syntax clearer.
  - The syntax of the data is easier to define using XML.

  Furthermore, in the previous version of CAP, not all the objects
were in iCalendar format, such as the GENERATEUID and the CAPABILITY
commands.
  
>     back into the data portion.

      What are the problems with having the data in the transport
      layer?

>     This includes returning

      Yes, please fix the MODIFY command. Removing the "update"
      element would give the same functionality as in CAP version 05.

>     that I think is 05 + beep transport only.

      Yes, this is not a requirement in BEEP. However, it is
      the standard practice to have the commands in XML.

      We are not defining an XML iCalendar, instead iCalendar is
      placed in a "text/calendar" MIME object.

      How does separating commands from the data hinder us in getting
      CAP out of the door?

> I will not be offended if any, all, or none of it is used.

George

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 12:28:09 -0700

Let me start off by saying that having also produced text
for CAP, I understand the tremendous hard work that George
is putting into this. George - please don't take these
debates to heart (I don't think you are) - the debates are
just part of the IETF process - GREAT WORK - THANKS.

>       What are the problems with having the data in the transport

iMIP/iTIP becomes a pain. We will then have to specify a mapping
between the iTIP methods and CAP commands. Right now I can iTIP
without any BEEP commands.  We should allow ALL iTIP objects
to be passed to a CS 'as is' and not have to pull some of
the data into the beep level by using the create command.

I should be able to just wrap the iTIP data with
	
	MSG...
	<create>
	<icalendar-blob>
	END

And it gets placed in the CS.

Additionally it confuses the errors. If I get a CAP error
to an iTIP reply that originally came from an iMIP source,
now we have to make sure that there is a way to map that
error back into iMIP from XML in order for the CUA to
iMIP the reply back to the ORGANIZER.

Also, the METHOD's CREATE and such and TARGET CAN BE sent to
an iMIP implementation, they just don't know what to do with them
at this time.  But they ARE valid iCalendar format data as
specified in 2445 (iana extensions).

The errors and replies in 05 may have needed work, but
it was already in iCalendar format.

>       element would give the same functionality as in CAP version 05.

I'll send text that I propose soon - working on it.

>       the standard practice to have the commands in XML.

Yes - beep commands.
And yes xml-cap commands - great.

But the advantage to BEEP is that anything can be transported, including
the already agreed on iCalendar data format (including TARGET, and
its new METHOD values).

>       placed in a "text/calendar" MIME object.

I guess you could argue that is 100% commands, but I see
data going into the transport layer and that data
already had a definition.

>       How does separating commands from the data hinder us in getting

Because the DATA was already defined. We have do only then
debate the XML-CAP commands and the BEEP-COMMANDS.
If we map the 05 CAP commands 1:1 to the XML-CAP commands
then we don't have to debate all of that over again.

---

From: Patrice Lapierre <[email-masked]>
Date: 15 Jan 2002 10:39:51 -0500

On Mon, 2002-01-14 at 14:28, Doug Royer wrote:
>...

  A similar result can already be obtained with draft-06 
(with the addition of the CDATA construct):

<schedule id="abcd12346">
  <target relcalid="john-relcalid"/>
   <data content='#Content'>
<![CDATA[
Content-Type: text/calendar
Content-ID: [email-masked]

BEGIN:VCALENDAR
VERSION:2.0
METHOD:REPLY
BEGIN:VEVENT
UID:abcd12345
DTSTART:19990307T180000Z
DTEND:19990307T190000Z
ORGANIZER:cap://cal.example.com/relcal1
ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2
SUMMARY:Important Meeting
END:VEVENT
END:VCALENDAR
]]>
   </data>
</schedule>

Granted it take a few extra bytes, but where is the pain?

  It has the advantage that an imip message can be sent 'as is' 
wrapped in an XML envelope. In your proposition, the imip must be
modified to include the TARGET property, and a new set of 
restriction tables is needed in CAP.

> iMIP the reply back to the ORGANIZER.

  Good point, the schedule command should include a iCalendar
in its responce.  

> specified in 2445 (iana extensions).

  This seems extremely dangerous! And might be the best argument
to keep the "schedule" command distinct from the "create".

  If a naive iMIP implementation was to forward (i.e., "create")
iCalendar objects with unknown METHOD or properties to a CAP 
server (e.g., simple bridge between your email and calendar
account):

Then a malicious person, could send you emails that:

  - Book VEVENTs (as opposed to schedule).
  - Create new VALARMs.
  - Potentially modify VCARS?
  
In addition, if all cap operations used a meta command 
(e.g, SENDDATA of draft-05) then:

 - METHOD:MODIFY: VEVENTs, VCARs, ...
 - METHOD:DELETE: your agenda.

---

From: Doug Royer <[email-masked]>
Date: Tue, 15 Jan 2002 09:52:26 -0700

> (with the addition of the CDATA construct):

See my previous post on it is out of scope to invent new
data models in CAP 1.0.

> Granted it take a few extra bytes, but where is the pain?

The pain is that we have to now think about the interactions,
debate how it is going to be done. That is WHY we had a CAP
requirements doc - to STOP re-inventing from scratch when
people think up new and better ideas. We can't wait for all
new ideas to stop before shipping CAP.

> restriction tables is needed in CAP.

BTW - adding TARGET to the object is still iMIP compliant
and does not introduce a new data model or the need to
add stuff later to the existing 2445 data model to pass
stuff back down the iMIP path.

> to keep the "schedule" command distinct from the "create".

It is not only NOT dangerous, it IS going to be done. CUAs ARE
going to translate CAP information back to any iMIP path. That's
one of the reasons that TARGET goes into the existing 2445 object
model.

>   - Potentially modify VCARS?

That is why we say use S/MIME in iMIP ?

>  - METHOD:DELETE: your agenda.

YES!!! And that was one of the goals. If you don't trust
the S/MIME signature or the person sending the data - then don't.
But if you do - it works. That is one of the reasons that we
placed using the 2445 object model as a CAP requirement.

At NO point is anyone saying that a CUA MUST honor all iMIP
requests. And NO ONE is saying that even if the S/MIME signature
is valid, known, and trusted, that the CUA MUST send it to
the CAP server. However - now you can IF you want to.

---

From: Patrice Lapierre <[email-masked]>
Date: 17 Jan 2002 10:47:13 -0500

On Tue, 2002-01-15 at 11:52, Doug Royer wrote:
...
> one of the reasons that TARGET goes into the existing 2445 object

  iTIP is designed to be transport independent, CAP is not. 
And AFAIK it's not a requirement for CAP.

  The email transport has limitations, handling these
is beyond for scope of CAP.

  If 2 CUAs need to communicate by email, they must use iMIP.
If more functionality is required, then iTIP should be extended,
and the schedule command of CAP will accept the extensions.

  CAP is built on top of iTIP, not the other way around.

---

From: Doug Royer <[email-masked]>
Date: Thu, 17 Jan 2002 10:22:46 -0700

>   CAP is built on top of iTIP, not the other way around.

NO - CAP is build on iCalendar, iTIP, and perhaps iMIP.
     iTIP is build on iCalendar
     CAP is extending iCalendar

And it is most definitly a requirement that iTIP transport
ANY VALID icalendar data, even if they were not defined
at the time iTIP was written. (...or any iana ... is in iCalenar
and in iTIP). It was designed so that we could extend it. We
knew that iCalendar was going to be extended by CAP and the
other proposals icap, hcap, irip, ... that evolved into CAP
knew that and had plans to extend iCalendar also.

It is iTIPs job to transport iCalendar objects. It is NOT
limited to what existed in November 1998. Same for iMIP.

If we extend iCalendar - we are extending iTIP and iMIP.

Several of us went out of our way to make sure that those
statements saying that components, properties, and paramaters
were extendable. And this IS why.