Subject: CAP / BEEP / XML / iCalendar

From: [email-masked] (Steve Mansour)
Date: Thu, 21 Mar 2002 19:40:38 -0800

Hey All,

While here in Minneapolis, several people brought up that there was
concern over the use of  XML with BEEP. I did a quick search through the
messages since Jan 12. I can't really tell if there is a problem or not.
I'd like to resolve this asap because there are other issues surrounding
the transport / application layer separation that we need to work
through. If anyone has an issue with the following, please bring it up
on the list so we can work through it. Otherwise, we can press on with
the other issues for draft 07.

     CAP defines a Transport  protocol layer and an Application
     protocol layer.  The data content type used in the Application
     protocol is text/iCalendar.  The data format for the Transport
     protocol is application/beep+xml.

Is everyone OK with this?  If you're not OK with this, can you please
describe the problem?

(our chairs do not view silence as consensus)

-Steve

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 21 Mar 2002 23:00:30 -0500

>...CAP defines a Transport  protocol layer and an Application protocol
layer.  The data content type used in the Application protocol is
text/iCalendar.  The data format for the Transport protocol is
application/beep+xml.

describe the problem?

I'm OK with the use of beep and the use of XML in the transport protocol.

The limited use of XML that has been introduced will not require a full
parser to be used by an implementation. I see no prior work by the group
that will be invalidated by this use.

Paul

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 21 Mar 2002 23:28:49 -0500

Hi Steve,

I'm one of those people who gets easily confused.  Looking at the OSI
model, the "transport layer" is layer 4, and is occupied by TCP.  If
anything, BEEP occupies the "presentation" layer.

My general confusion is why certain things were chosen to be put into
the XML _application_ layer (such as "<search ...>") and what was put
into the payload (the iCAP CDATA blobs).  here's one example from
draft 07:

 1   C: MSG 1 4 . 2043 680
 2   C: Content-Type: application/cap+xml
 3   C:
 4   C: <search latency="3" action="ask">
 5   C: <![CDATA[
 6   C: Content-Type: text/calendar
 7   C:
 8   C: BEGIN:VCALENDAR
 9   C: METHOD:SEARCH
10   C: TARGET:relcalid-123
11   C: CMDID:xyz12346
12   C: BEGIN:VQUERY
13   C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
14   C:  WHERE DTEND >= '19990714T080000Z' AND
15   C:  DTSTART <= '19990715T080000Z'
16   C: END:VQUERY
17   C: END:VCALENDAR
18   C: ]]>
19   C: </search>
20   C: END

Of this, lines 1,2, and 20 are specified by BEEP and are part of the
presentation layer.

Lines 4-19 are specified by CAP and are in the application layer.
These lines consist of a single command, "search".  The search command
appears to have three parameters: two of them are attributes
("latency" and "ask") and one of them is in the body (the CDATA iCAP
object).

The iCAP object, lines 6-18, appears to be some sort of data payload.
It's not clear to me why there isn't just a

LATENCY:3
ACTION:ask

inside the VQUERY.  It's also unclear to me if line 9 could be
anything but METHOD:SEARCH; it appears to contain duplicate information
from line 3, but I guess I'd have to reread the draft to state with
any definitiveness.

At this point, there appears to be much more investment into making
more iCal objects; in fact, the examples in 6.2.2.5 don't even show
the XML!  Is there any reason for any of the XML fragments besides
that BEEP uses XML messages for some of it's presentation?

Larry

---

From: Andrew Davison <[email-masked]>
Date: Fri, 22 Mar 2002 14:40:44 +1000

Steve Mansour wrote:

> concern over the use of  XML with BEEP. I did a quick search through 
> the messages since Jan 12. I can't really tell if there is a problem 
> or not. I'd like to resolve this asap because there are other issues 
> surrounding the transport / application layer separation that we need 
> to work through. If anyone has an issue with the following, please 
> bring it up on the list so we can work through it. Otherwise, we can 
> press on with the other issues for draft 07.
>

why does CAP have to mention this. surely just saying the transport 
protocol layer is BEEP implies the data format (and much else). it 
doesn't even have to know the details.

i'm new to this (the last time i looked at CAP it was still CSTP) so 
maybe i'm missing something. my implementation of CAP will use BEEP 
purely as an API and so will not know anything about how it works.

andrew

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Mar 2002 08:41:42 -0700

Steve Mansour wrote:

>     CAP defines a Transport  protocol layer and an Application protocol

There are two layers. For CS commands lets go with application/cap+xml
(or better yet ical-xml).  For ALL iTIP objects there is NEVER a need to
add another layer or two wrap the the data in CDATA, lets just send 
text/calendar and as we already added CMDID to the iCalendar
object pre-beep anyway.

Then we make (as in 07) SEARCH, DELETE, MOVE, MODIFY, a valid method (and
any I missed here). Then the only time we need appliction/ical+xml is
when we send CAP only commands. For all other objects they are iCalendar
objects (in CDATA or future xCal).

Then in xCal - we specify the XML binding for the iCalendar objects.
This is out of scope for CAP and is only going to confuse things
when xCal is in the hot seat.

-> Why cap+xml (or ical+xml) and not beep+xml?

So we can use ical+xml in xCal and it means the same thing - that
a xCal object or a CDATA text/calendar object is in the XML blob.
If we use beep+xml, then we have to invent the same thing again
so that we can transport xCal objects via non-CAP where their
MIME type can NOT be beep+xml. We do NOT need two ways to
wrap iCalendar or xCal objects.

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Mar 2002 08:53:56 -0700

> anything, BEEP occupies the "presentation" layer.

ISO transport died? :-)

> into the payload (the iCAP CDATA blobs).  here's one example from

Issues:  (1) iCalendar objects are iCalendar - not XML.

          (2) CAP is a protocol to move iCalendar objects.

          (3) There are CAP commands and iCalendar objects.
              We agreed the CAP 'commands' can be XML.

          (4) xCal will describe how iCalendar objects are mapped
              1:1 into XML objects - not CAP. That was never in
              the scope of CAP.

          (5) xCal (or a separate draft) will describe how
              to transport xCal objects with CAP - it was never
              in scope for CAP.

          (6) The WG agreed that CAP MUST BE iCalendar objects.

          (7) Latency and ask are transport issues, not data issues.

         (8) Small or thin devices (cell phones) must be considered

              in the protocol. It is more important to transport the
              data than to develop an elaborate protocol just because
              someone else did. 07 reduces the byte count significantly
              over 06. 07 is not as pretty - I agree with that.

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Mar 2002 08:58:37 -0700

> doesn't even have to know the details.

It is not sufficient because I MUST know exactly what you
are sending. Many people seemed to have just copied the
BEEP examples and tweaked them.

iCalendar objects exist outside of BEEP and so will xCal objects.
Which is why I want the MIME type to be application/ical+xml (or
what ever) and not appliction/beep+xml for any XML iCal objects.
And why I want to keep text/calendar for any object that can
be transported via iTIP.

> purely as an API and so will not know anything about how it works.

BEEP is not an API. So we have to describe the model.

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 22 Mar 2002 11:33:44 -0500

Date: Fri, 22 Mar 2002 08:53:56 -0700
   From: Doug Royer <[email-masked]>
[...]
   ISO transport died? :-)

The word "transport" was used.  I don't know what definition was
being applied.

I don't understand how these two points cooperate.

I think my message was asking why CAP 'commands' are XML; the
iCalendar object appears to contain all of the information necessary.

I am _not_ arguing that the WG should adapt xCal objects.

Larry

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Mar 2002 09:57:26 -0700

> iCalendar object appears to contain all of the information necessary.

I agree - it is called compromise.

I would prefer if EVERYTHING was a iCalendar object in CAP.
Then xCal (or an add on) could specify an optional capability
for a CS.

Pre-BEEP, the CAP commands were non-iCalendar objects. So it
looked like a good place to split.

> I am _not_ arguing that the WG should adapt xCal objects.

Thanks.

---

From: Andrew Davison <[email-masked]>
Date: Sat, 23 Mar 2002 08:42:50 +1000

> BEEP is not an API. So we have to describe the model.

why not, it's how i implemented it? if the content-type is 
'application/beep+xml' then it's a beep control message and the BEEP API 
(or transport layer) processes it, anything else is passed up to the 
application layer, in this case CAP. so CAP needs knows nothing about 
how BEEP works and knows nothing about 'application/beep+xml' types. in 
my implementation it never even sees MSG or RPY or ANS or NUL or SEQ or 
'application/beep+xml' stuff, CAP is just payload data. other 
applications may also choose to layer themselves over BEEP.

i don't  really care about whether CAP uses XML itself (ie. 
'application/cap+xml'). my only issue is that CAP spec seems to concern 
itself with how BEEP works, when there is no need for it.

---

From: [email-masked] (Steve Mansour)
Date: Fri, 22 Mar 2002 14:14:04 -0800

> anything, BEEP occupies the "presentation" layer.

Larry, we're not thinking of the OSI model. We're thinking very
CAP-centric. We're using transport to mean something that gets a blob of
iCalendar information from here to there; it doesn't attempt to crack open
what's in the blob or make sense of it. The transport's only responsibility
is to shuttle iCalendar blobs.

Originally, we rolled our own (remember the old SENDDATA command?). We were
asked to look at BEEP so that we wouldn't have to create yet another
transport.  BEEP provides everything we need to shuttle iCalendar blobs,
multiple channels, etc.

> into the payload (the iCAP CDATA blobs).  here's one example from

OK, I agree. It's not exactly the point I wanted to nail, but I can see why
you brought it up here. We're providing hints about what's inside the blob
-- yet, as I stated above, the transport should not know anything about
what's inside the blob. So, We need to fix that.

We should probably stick with something generic like <cap  latency="3"
action="ask">.  There should not be any requirement to see what command
we're executing from the transport layer.

> ("latency" and "ask") and one of them is in the body (the CDATA iCAP

The fact that we put the command name <search> in the transport mislead
you. "latency" and "ask" are purely transport functions from CAP's point of
view. They apply to all the blobs that a CUA sends to a CS over BEEP.

> that BEEP uses XML messages for some of it's presentation?

We needed some syntax for the transport.  BEEP used XML. So, we used it
too. No deeper reason than that.

I'm hoping that we can put the XML portion of this problem into
perspective. It is a *very* small part of what we're doing with CAP.  It's
just a detail that goes along with using BEEP.

We haven't done a good enough job at making clear the distinction between
CAPs transport and application layers. Your suggestion about the command
names will help make the distinction clearer.  The other thing is that the
XML part of the protocol is going to be a very, very minor part. Probably
two or three lines, compared to hundreds or thousands of lines of
iCalendar.

Do you still have concerns if the example you sent looked more like this:

 1   C: MSG 1 4 . 2043 680
 4   C: <cap latency="3" action="ask">
19   C: </cap>
20   C: END

-Steve

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Mar 2002 16:47:55 -0700

> why not, it's how i implemented it?

You have implemented an API (Application Programming Interface)
for your BEEP protocol implementation. But BEEP is a protocol
not an API. If BEEP were an API it would have specified function
calls, and it does not specify any.

		send_data(char * blob);
		get_data()
		...

BEEP has some options and we must agree which options we have to
use in order for it to be compatible with every other CAP implementation.
Other than that, I agree - just say use BEEP, and I think that 07
is closer to that goal.

---

From: [email-masked] (Steve Mansour)
Date: Sun, 24 Mar 2002 11:49:09 -0800

Folks,

After thinking about some of the feedback on this, I think that the XML
encoding, while harmless, is superfluous. At the meeting in Minneapolis, we
were thinking along these lines:

     ENCAPSULATION A

     C: MSG 1 2 . 1234 123
     C: Content-type: application/cap+xml
     C:
     C: <cap latency="3" action="ask">
     C: <![CDATA[
     C: Content-Type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: METHOD:SEARCH
     ...
     C: END:VCALENDAR
     C: ]]>
     C: </cap>
     C: END

The XML encapsulation is innocuous, but it adds nothing. Further, it tempts
us to move things out of the Application layer and into the Transport layer
(such as the command names, and attributes such as "latency" and "action"
-- undermining the transport/application separation and leading us down
slippery slopes.  Here is a simpler alternative (and yes, I know some of
you have been pushing for something like this all along :-) :

     ENCAPSULATION B

     C: MSG 1 2 . 1234 123
     C: Content-type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: METHOD:SEARCH
     C: LATENCY:3
     C: ACTION:ASK
     ...
     C: END:VCALENDAR
     C: END

The advantage of encapsulation B is that it represents exactly the same
content as encapsulation A, but it uses one rather than two encapsulations
and there are no hints about the calendaring commands in the transport. We
could substitute *any* transport.

Can anyone suggest why we would want to use encapsulation A rather than B ?

Are there any objections to moving forward with encapsulations as specified
in B ?

-Steve

---

From: Doug Royer <[email-masked]>
Date: Sun, 24 Mar 2002 13:18:55 -0700

Steve Mansour wrote:

>
> 
> The XML encapsulation is innocuous, but it adds nothing. Further, it 
> tempts us to move things out of the Application layer and into the 
> Transport layer (such as the command names, and attributes such as 
> "latency" and "action" -- undermining the transport/application 
> separation and leading us down slippery slopes.  Here is a simpler 
> alternative (and yes, I know some of you have been pushing for something 
> like this all along :-) :

>     C: ACTION:ASK

Or perhaps:

		LATENCY;ACTION="ask":3

And YES - XML is not needed in CAP.

---

From: [email-masked] (Steve Mansour)
Date: Sun, 24 Mar 2002 12:30:33 -0800 (Pacific Standard Time)

Doug Royer wrote:

Steve Mansour wrote:

> The XML encapsulation is
innocuous, but it adds nothing. Further, it
> tempts us to move things
out of the Application layer and into the
> Transport layer (such as
the command names, and attributes such as
> alternative (and yes, I know
some of you have been pushing for something

Or perhaps:

LATENCY;ACTION="ask":3

yep. this is better than two separate properties.

-Steve

Steve
Mansour
Director of Engineering
AOL / Netscape
AIM
StMansour

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 06:27:28 -0600

What would the XML version of encapsulation B look like?

Gary

Steve Mansour wrote:
> encoding, while harmless, is superfluous. At the meeting in Minneapolis, 
> we were thinking along these lines:
> 
>     ENCAPSULATION A
> 
>     C: MSG 1 2 . 1234 123
> content as encapsulation A, but it uses one rather than two 
> encapsulations and there are no hints about the calendaring commands in 
> the transport. We could substitute *any* transport.
> 
> Are there any objections to moving forward with encapsulations as 
> specified in B ?
> 
> -Steve
>

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 25 Mar 2002 10:23:01 -0500

I agree that this is preferable.  This removes the redundant
application layer.  This should make the protocol easier to understand
and simplify the document.

Larry

   Date: Sun, 24 Mar 2002 11:49:09 -0800
   From: [email-masked] (Steve Mansour)
[...]
	ENCAPSULATION B

	C: MSG 1 2 . 1234 123

---

From: [email-masked] (Steve Mansour)
Date: Mon, 25 Mar 2002 08:05:32 -0800

> What would the XML version of encapsulation B look like?

There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation
because that's how our application data is defined. The point of B was to show
that the iCalendar encapsulation is the only one needed.

-Steve

---

From: "Peter Thompson" <[email-masked]>
Date: Mon, 25 Mar 2002 08:06:24 -0800

So you are putting transport dependancies into the data area? 
I'm sorry if I'm confused about this, but I really hope that
you are keeping data separate from transport, as the iCalendar
data is used by other transports.

Cheers,
	Peter

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lawrence
> Greenfield
> Sent: Monday, March 25, 2002 7:23 AM
> To: CalSched IETF; Steve Mansour
> Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal
> 
> 
>

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 09:54:47 -0700

> What would the XML version of encapsulation B look like?

NONE  - use text/calendar ONLY.

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 10:53:46 -0600

Let me try again...

Steve, you gave an example that used good ol iCalendar in the 
application part of the message. I wanted to know what it would look 
like if the application part was XML/XCS rather than iCalendar.

     ENCAPSULATION B - XCS version

     C: MSG 1 2 . 1234 123
     C: Content-type: the correct type for xcs...
     C:
     C: <vcalendar>
     C: <method type='search' latency='3' />
     C: <action>ask</action>
     ...
     C: </vcalendar>
     C: END

The above is NOT an attempt to show what the XML/XCS should be. It's to 
clarify that I was asking what an encapsulation that used XCS rather 
than iCalendar would look like.

Gary

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 10:07:49 -0700

> So you are putting transport dependancies into the data area? 

CAP is not the transport. BEEP is the transport and BEEP does
not have LATENCY. And it won't break iTIP, iMIP, or iCalendar.

> data is used by other transports.

BEEP is not the only transport for iCalendar objects. I don't
see any reason that I could not add A LATENCY of "5 days" to an iMIP
object.

I hope you can accept any PROPERTY;paramaters="foo":value even
if you don't understand what they do. If you can, it has no
meaning as they are still valid iCalendar objects.

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 12:05:38 -0600

So we are dropping the XML version of iCalendar?

Gee, I must have missed that e-mail.

Gary

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 12:11:19 -0700

> like if the application part was XML/XCS rather than iCalendar.

The xCal draft, draft-ietf-calsch-many-xcal-01.txt

Is the 2nd pass at mapping iCalendar into XML. It is changing.
Once done, any component, property, or parameter can be mapped
between iCalendar and XML format.

XML is out of scope for CAP and I think that is what Steve is
also saying. XML does nothing for CAP for iCalendar objects.

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 12:18:44 -0700

> Gee, I must have missed that e-mail.

NO - We are dropping that CAP encapsulates iCalendar objects in XML.

The xCal draft is going forward. I would suspect that there can
be a draft on how a CS can optionally support xCal objects. It
won't be hard as xCal is a 1:1 mapping of iCalendar.

---

From: Steve Mansour <[email-masked]>
Date: Mon, 25 Mar 2002 12:06:21 -0800

> So you are putting transport dependancies into the data area?

Peter, I don't understand. What transport dependancies do you see in the
data area?

If you're referring to LATENCY and ACTION, I would claim that those are
values that we want to send to the server independent of transport. That
is, we would want to bound the latency on the command whether we send
the command via BEEP, or any other transport.

-Steve

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 15:14:57 -0600

I'll go back to no comment mode.

Gary

---

From: "Peter Thompson" <[email-masked]>
Date: Mon, 25 Mar 2002 13:28:32 -0800

If that is the intent with LATENCY, that is fine.  
How about ACTION?  That seems be beyond the realm of
calendar data...

Cheers,
	Peter

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 25, 2002 12:06 PM
> To: Peter Thompson
> Cc: CalSched IETF

---

From: [email-masked] (Steve Mansour)
Date: Mon, 25 Mar 2002 13:55:28 -0800

Yipes!  I would not want to promote that.  For better or worse, RFC2445 is not XML
based. We spent several years trying to get that RFC through. People have built
software expecting iCalendar syntax. To change CAP now and and promote the use of
XMLized icalendar would open up a huge can of worms, and it would be unfair to people
who have invested in iCalendar. Let's please not go there.  Such a move is really out
of the scope of CAP.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 15:12:55 -0700

> How about ACTION?  That seems be beyond the realm of

ACTION is the action to take when LATENCY times out.

In addition to 'data' there is what I will all 'control and workflow data'
that is independent of transport. I see ACTION and LATENCY as
falling into that category.

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 16:24:35 -0600

No problem - I went back to no comment mode

That's
   <comment mode="no" />
in XML

Gary

---

From: [email-masked] (Steve Mansour)
Date: Mon, 25 Mar 2002 21:35:44 -0800

Folks,

Here's where I think we're at for the transport versus application layer
encapsulation

     C: MSG 1 2 . 1234 123
     C: Content-type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: METHOD:SEARCH
     C: LATENCY;ACTION="ask":3
     ...
     C: END:VCALENDAR
     C: END

More detailed writeup

This incorporates Doug's suggestion for parameterizing ACTION.  Doug,
Larry, and I are OK going forward with this. Need to hear from some more
folks.

Does anyone have issues with this?  Can we close this issue and move on?

-Steve

---

From: Gary Frederick <[email-masked]>
Date: Tue, 26 Mar 2002 01:43:16 -0600

Great.

Gary

Steve Mansour wrote:
> <http://www.imc.org/ietf-calendar/mail-archive/msg05561.html>
>

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 26 Mar 2002 17:44:05 -0500

> Does anyone have issues with this?  Can we close this issue and move

I have no problem about removing XML from CAP.  On the other hand,
we need to look at the issues that need to be addressed as a result
of this change.  Don't worry, none of the following issues need XML
to be resolved!

1- The version of iCalendar supported by the CS will end up
   being specified in an iCalendar object (chicken'n'egg
   problem).  Shall we specify that the capabilities MUST
   always be returned in an iCalendar 2.0 object?  For
   instance, a CS supporting iCalendar 2.1 would returned :

      BEGIN:VCALENDAR
      VERSION:2.0          <-- Always 2.0
      BEGIN:VCAPABILITY
      VERSION:2.1          <-- Version of iCalendar
      ...                      supported by the CS
      END:VCAPABILITY
      END:VCALENDAR

2- The MODIFY command requires ordering of components (i.e.,
   OLD-VALUES component needs to appear before the NEW-VALUES
   component in the iCalendar object).  The iCalendar syntax
   usually doesn't impose ordering of components.  Are there
   iCalendar parsers known not to preserve the ordering of
   components in iCalendar objects?  Should the old and new
   values be identified explicitly by some other mean than
   their ordering?  Is that an issue?

3- According to RFC 2445, besides CALSCALE, METHOD, PRODID and
   VERSION, only "x-prop" properties can appear in the body of
   iCalendar components.  Do we want to break this syntax and
   allow TARGET, CMDID, LATENCY, etc. in iCalendar components?
   We used to have a VCOMMAND components for these types of
   properties.  Do we need to add it back?  What about iTIP?
   iTIP doesn't allow TARGET, etc. in the iCalendar object
   either.

4- We need to agree on the mapping of the existent DTD into
   the iCalendar syntax.  That is, we will need to define new
   components (e.g., VCAPABILITY, VGENERATE-UID) as well as new
   properties and parameters (e.g., UPN property or parameter
   for the IDENTIFY command, NUMBER-OF-UID property or parameter
   for the GENERATE-UID command).  We will also have to define
   the format of the response returned for the commands, perhaps
   we will need a VRESULT component?

5- Further to this change, I think it will become even more
   important to separate the method/command specified in the
   iCalendar objects from their actual state.  Perhaps, we
   will want/need the ability to create objects in a specific
   initial state eventually (e.g., a PDA willing to sync its
   meeting trash can on the CS (i.e., create meeting in the
   state DELETED)).

   We might also want to consider Doug's proposition of using
   a "CMD" property to hold the name of the command instead
   of using METHOD.  It might be worthwhile to use METHOD
   only in iTIP messages.  Doug's proposal can be found at
   http://www.imc.org/ietf-calendar/mail-archive/msg04741.html

Cheers,
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, 26 Mar 2002 16:24:47 -0700

>       VERSION:2.1          <-- Version of iCalendar

The capabilities VERSION was changed to CAP-VERSION - no longer a conflict.
And the CAP-VERSION is "1.0".

(I think this was a George suggestion and is currently in -07).

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 16:27:38 -0700

>    their ordering?  Is that an issue?

Good idea. It first I thought I could live with it being
an exception. But exceptions are killing us with query. So
it might be a good idea to specifically tag them.

Andy ideas for property names?

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 16:32:48 -0700

>    iTIP doesn't allow TARGET, etc. in the iCalendar object

2445 allows us to make new properties, parameters, and value types
as long as we register them with iana, or in an RFC.

iTIP allows iana registered properties, parameters, and value types.

So the sections in CAP that explicitly define those properties simply
have to also register them as new in CAP.  When CAP is an RFC, they
are iana registered and valid in 2445, iTIP, iMIP, and CRISP objects.

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 16:41:00 -0700

I assume you mean the BEEP DTD?

If no, yes xCal will describe how to generically
map iCal into and from XML.

If yes ...

>    we will need a VRESULT component?

GET-CAPABILITY simply is a METHOD, not a component.
Same with IDENTIFY and the others.

Is all we have to do is define how we return the results.
Pre-BEEP we had a way to do a iCalendar REPLY, I assume the
quickest way is to update that. Perhaps a VCALENDAR object
with METHOD:REPLY and CMDID and TARGET matching the original
command, then include any reply objects. It will require new
properties. And for 'capability' - we had pre-beep defined them
as CS or calendar properties. We can just go back to that and
update it for the additions and changes. Or if that no longer
fits, then we could make up new components.

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 16:42:36 -0700

I agree with my proposal :-)

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 26 Mar 2002 19:46:38 -0500

> And the CAP-VERSION is "1.0".

Draft-07 has both capabilities.

          cap-version    1+         Version of CAP. MUST include at
                                    least "1.0" for this version of
                                    CAP.

            version      1+         Version of iCalendar support.
                                    MUST BE at least "2.0".
                                    supported.

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 26 Mar 2002 19:58:11 -0500

> as long as we register them with iana, or in an RFC.

Unfortunately, that's not the case.

From section 4.6 (Calendar Components) of RFC 2445:

     calprops   = 2*(

                ; 'prodid' and 'version' are both REQUIRED,
                ; but MUST NOT occur more than once

                prodid /version /

                ; 'calscale' and 'method' are optional,
                ; but MUST NOT occur more than once

                calscale        /
                method          /

                x-prop
                )

> iTIP allows iana registered properties, parameters, and value types.

Unfortunately, RFC 2446 [iTIP] does not.  There is no such
thing as "iana-prop" in this RFC.

> are iana registered and valid in 2445, iTIP, iMIP, and CRISP objects.

Perhaps both 2445 and 2446 should have allowed "iana-prop",
but they did not.  If we decide to break the syntax we
should state it clearly in the CAP draft.

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 26 Mar 2002 20:10:57 -0500

> map iCal into and from XML.

I meant the CAP DTD.  Section 8 of draft-07
(was section 9 in draft-06).

> Same with IDENTIFY and the others.

I know, but in which component are you planning to return
the capabilities?  I figured METHOD:GET-CAPABILITY could
return a VCAPABILITY component.  Anyway, my point is that
removing XML is not straightforward.  We need to discuss
these issues (which is what we are doing now :-) ).

> properties. 

Can you provide an example of what you mean here?
I hope you don't mean adding numerous properties
directly in the VCALENDAR components.

> And for 'capability' - we had pre-beep defined them
> as CS or calendar properties.

Sorry.  Capabilities have never been defined as properties.
From section 7.1.5 of draft-05:

               C: CAPABILTIY
               S: 2.0
               S: .
               S: CAPVERSION=1.0
               S: ITIPVERSION=1.0
               S: AUTH=KERBEROS_V4
               S: AUTH=DIGEST_MD5
               S: .

> We can just go back to that and

Cheers,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 18:46:54 -0700

>>as long as we register them with iana, or in an RFC.

Okay, So we extent 2445. That is what the registration process
is all about.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 27 Mar 2002 09:44:15 -0500

> Andy ideas for property names?

Actually, it might be better to use components
to avoid creating yet another exception (i.e.,
property FOO is not a property of the component
being modified, it is only a property used to
identify which component is the OLD one and
which is the NEW one).

   BEGIN:VCALENDAR
   VERSION:2.0
   TARGET:my-cal
   CMD:MODIFY
   LATENCY;ACTION="ask":3
   BEGIN:VQUERY
   QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
   END:VQUERY
+  BEGIN:VOLDVALUE
   BEGIN:VEVENT
   LOCATION:building 3
   END:VEVENT
+  END:VOLDVALUE
+  BEGIN:VNEWVALUE
   BEGIN:VEVENT
   LOCATION:building 4
   END:VEVENT
+  END:VNEWVALUE
   END:VCALENDAR

Any ideas for better component names? :-)

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 27 Mar 2002 10:02:22 -0500

> Okay, So we extent 2445. That is what the registration process

The registration process doesn't allow us to break existent
rule parts.

If this WG agrees on breaking existent rule parts it needs to
make that clear to everybody.  Perhaps by changing the iCalendar
version being used.

Don't get me wrong.  I'm not against breaking the syntax.
Perhaps that the right thing to do, and perhaps it's the
right time to do it.  On the other hand, we need to be
clear on that.

I do understand that changing the iCalendar version being
used will be painful.

There are ways to achieve our goals without breaking the
existent iCalendar syntax.  Using VCOMMAND components as
was done in draft-05 is one of them.

Prior to using XML, CAP was using VCOMMAND components.
It just seems logical that we need to add them back
while removing XML.

Cheers,
Bernard