Subject: (was) 3.2 Use of XML, MIME and iCalendar

From: Doug Royer <[email-masked]>
Date: Sat, 12 Jan 2002 14:33:41 -0700

I propose we change section 3.2 so to the following so that
we have a minimum of change between 05 and the BEEP version of
CAP. This minimizes the data changes that have already reached
consensus and modifies only the transport command and CAP commands.
The CAP and iCalendar 'data' is unmodified from 05.

NOTE: the 'id' as defined in 06 and the CMDID as defined in 05
are not needed as that is the purpose of the BEEP msgno. That is
msgno uniquely defines the commands that were issued. And the BEEP
reply to that msgno contains the original msgno.

3.2 Use of BEEP, MIME and iCalendar

   BEEP supports any MIME object. Therefore as RFC-2445 objects are
   MIME objects with a Content-Type of text/calendar, they may be sent
   without modification between a CUA and a CS using BEEP.

   There are several types of information in CAP, and they are:

	(1) Transport Commands:

		Handled By: BEEP
		MIME Content-Type: application/beep+xml

	(2) CAP Commands and replies to CAP commands:
	
		Handled By: CAP
		MIME Content-Type: application/cap+xml

	(3) iCalendar Data

		Handled By: CAP inside of a CAP command or 
                            inside of a CAP command reply.
		MIME Content-Type: text/calendar

        (4) Transport status and errors.

		Handled By: BEEP
		MIME Content-Type: application/beep+xml

        (5) CAP and iCalendar status and errors.
	
		Handled By: CAP
		MIME Content-Type: text/calendar inside of a CAP command
                                   or inside of a CAP command reply.

   BEEP handles connection, authentication, channel management,
   and channel shutdown. These are independent from the CAP commands.

   CAP commands include manipulation of the data inside the CS
   as well as fetching data from inside of the CS. The CAP commands
   themselves are specified in XML with an optional CDATA section
   that includes a MIME object of type text/calendar.

   A CAP command my result in zero or more iCalendar objects being
   returned by the CS.

   CAP commands that do not return any iCalendar data return their CAP
   command results in XML.

   For CAP commands that results in one or more iCalendar objects being
   returned and require an CAP command reply. Their CAP command result
   is in XML and it includes a CDATA section that contains a MIME
   text/calendar object.

   For CAP command replies that can be expressed entirely in iCalendar
   format, the reply is any MIME object that is supported.

   Once BEEP has established the connection and the CS has accepted
   the authentication information provided by the BEEP implementation,
   the CUA and the CS have a CAP session authenticated. And only when
   a CAP session is authenticated may the CUA send CAP commands to
   the CS. The only exception to this is that a CUA may send a
   capabilities request to the CS and get a capabilities reply while
   in the un-authenticated CAP state.

   CAP Data flowing from the CUA or the CS may only be one of two
   MIME types as viewed by the BEEP implementation, text/calendar or
   application/cap+xml . In the following example, a CAP command is
   sent to the CS requesting 3 UID's and the CS's reply. Note that
   the BEEP msgno in the MSG is '2' (1st '2' after MGG) and it is
   in BEEP RPY message (1st '2' after RPY) and that is how the
   CAP commands is tied to the CAP reply.

   C: MSG 1 2 . 432 61
   C: Content-Type: application/cap+xml
   C:
   C: <generate-uid num=3/>
   C: END
   S: RPY 1 2 . 832 185
   S: Content-Type: application/cap+xml
   S:
   S: <uid>[email-masked]</uid>
   S: <uid>[email-masked]</uid>
   S: <uid>[email-masked]</uid>
   S: END

   Here is an example of a CAP command that includes an iCalendar
object.
   In this example, the CUA is requesting the CS to create a new
   iCalendar object into the both of the TARGET calendars, the
   command and reply identifier is '5' in this example:

   C: MSG 1 5 . 76 552
   C: Content-Type: application/cap+xml
   C:
   C: <create>
   C: <![CDATA[
   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: METHOD:REQUEST
   C: TARGET:relcal-id-1
   C: TARGET:relcal-id-2
   C: BEGIN:VEVENT
   C: UID:unique-xyz
   C: ORGANIZER:cap://cal.example.com/mary-relcalid
   C: ATTENDEE:PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid
   C: ATTENDEE;PARTSTAT=NEEDS-ACTION
   C:  ;C:  RSVP=TRUE:cap://cal.example.com/john-relcalid
   C: ATTENDEE;PARTSTAT=NEEDS-ACTION
   C:  ;RSVP=TRUE:cap://cal.example.com/bob-relcalid
   C: DTSTART:20010920T180000Z
   C: DTEND:20010920T190000Z
   C: SUMMARY:Mary invites John and Robert
   C: END:VEVENT
   C: END:VCALENDAR
   C: />]]>
   C: </create>
   C: END
   S: RPY 1 5 . 83 192
   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCAP
   S: METHOD:RESPONSE
   S: TARGET:relcal-id-1
   S: REQUEST-STATUS:2.0
   S: END:VCAP
   S: BEGIN:VCAP
   S: METHOD:RESPONSE
   S: TARGET:relcal-id-2
   S: REQUEST-STATUS:2.0
   S: END:VCAP
   S: END

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Jan 2002 11:49:19 -0500

> reply to that msgno contains the original msgno.

Using msgno raises other issues:

   1. Msgnos are part of the BEEP layer. I don't see it as 
      a good practice to introduce that knowledge in the profile 
      payload.

   2. Msgnos are recycled (unlikely happen in practice, 
      but in theory a huge queue could make a msgno in a message
      payload refer to the wrong message).

   3. Msgnos are not unique within a session. A different channel may
      have a message with an identical msgno in its queue.
      
NOTE: The use of a different channels could be very useful to implement
a preemptive "abort" command (as suggested in another post), but for
this to work the command id must be unique within all channels of the
session. 

For these reasons, I think that an id, as defined in draft-05, 
is more appropriate.
   
...
> 		MIME Content-Type: application/cap+xml

What is the motivation for introducing a new content-type?
   
The syntax and semantic of a message payload is defined in the
beep profile registration template, not in the definition of
the mime content-type. When receiving a new message, there is 
no unambiguity determining which DTD to use.

"Content-Type: application/beep+xml" is already registered and 
defined in RFC3080. Why not reuse it as done by other beep 
profiles (e.g., apex-core)?

>...

  That would add unnecessary complexity the beep profile registration
template. I don't see any problem in always using a thin XML envelope
for responses that includes iCalendar. It's easy to document and
consistent.

---

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

> What is the motivation for introducing a new content-type?

Because we DID define a new content - CAP commands and
this WG can define what that means. What if beep+xml
later defines a <create> command?

> profiles (e.g., apex-core)?

Because we are defining CAP commands, and some other WG gets
to say what beep+xml means.

The reason for application/???+xml is so that everyone can
tell what the content type is by looking at the header. If
it were true that everyone should use beep+xml, then the
entire header is not needed because it is always beep+xml.

> for responses that includes iCalendar. It's easy to document and

One of the reasons that BEEP allows content-type, is so that
the implementations can choose. We already have a content type,
why not use it when it is already defined and "is the reply",
such as iTIP replies?

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 15:26:44 -0700

Doug Royer wrote:
 (3) iCalendar Data
> why not use it when it is already defined and "is the reply",

In addition:

I PROPOSE:

  For iTIP objects that can be inserted into the CS directly
  without modification (see METHOD:COUNTER text below), we
  do not need ANY cap command:

	MSG 1 .....
	Content-Type text/calendar ; method=<any iTIP>

	BEGIN:VCALENDAR
	METHOD:<any iTIP>
	...
	END:VCALENDAR

  We do not need ANY CAP command because it is an implicit create.
  If you get one - store it.

  For METHOD:COUNTR - the CUA would tweak it into:

	METHOD;SENT-BY=mailtouri...:COUNTER

  Otherwise the send the METHOD:CREATE as received.

  So now the only reason to use the XML-CAP command of <create>
  is for NON-iTIP METHODs.

---

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

> > why not use it when it is already defined and "is the reply",

  I not saying that a iCalendar object should not be sent. On the
contrary as you stated, an iCalendar REQUEST-STATUS could be very
useful for the caller of the schedule command. 

  But for consistency the starting point of always use the
same content-type.

  This may come handy for future extensions. Here's an example
that comes to mind: the XML part of the result of search command 
could contain the number of element found, allowing the CUA to 
display a progress bar while the components are downloaded.

>   So now the only reason to use the XML-CAP command of <create>

Same objections as above.

  A future revision of the create command could be extended with
new optional argument, e.g. max latency if/when fanout is 
reintroduced.

---

From: Patrice Lapierre <[email-masked]>
Date: 15 Jan 2002 08:16:48 -0500

On Mon, 2002-01-14 at 14:36, Doug Royer wrote:
> this WG can define what that means. 

  In BEEP it is not the mime-content type registration that 
defines the semantic, but the CAP Profile Registration 
(section 8.1).

> What if beep+xml

It can't! 

  You seem to be confusing the concept of profile and mime 
content-type.  The BEEP Channel Management Profile could add 
the <create> element, but that would have absolutely no impact 
on the mime-content type "application/beep+xml" or the CAP profile.

> to say what beep+xml means.

 Well other WGs are designing beep profiles with XML payloads. 
I saw "application/beep+xml", "application/xml" and the default 
fallback. But I couldn't find a profile that introduces it's 
own content-type.

> entire header is not needed because it is always beep+xml.

Everyone doesn't always do what they should :-) 

(I'm not suggesting that everyone should use "application/beep+xml", 
just pointing out the logical error your last sentence).

---

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

>   But for consistency the starting point of always use the

So why not use what we have ALREADY registered, what applications
ALREADY can use, and what we have ALREADY defined, and
that is "text/calendar"?

I don't see ANY reasn that a CUA can just do minor tweaks to
an iMIP message and pass it down directly to the CS (add TARGET(s)).
Why do we need to define how to do iTIP scheduling PLUS how to
translate those into CAP? It just looks redundant and
I don't see any need to add the transformation.

> display a progress bar while the components are downloaded.

Yes - When we define xml-iCalendar. We are not doing that in CAP.
That is a seperate effort on this WG. For CAP lets just use the
propsed standard for calendar objects, and that is iCalendar - RFC2445
objects. Which is one of the CAP requirements:

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

When we have defined ical-xml, then lets open up the other door.
For CAP 1.0 defining NEW data models is out of scope.