Subject: CAP (TARGET moved out of CAP data?)

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 15:12:14 -0700

IN 
3.3 Bounded Latency

(1) The TARGET command is not in the CAP data, however the
    <source relcalid='opaqueid101'/>   tag is in the BEEP
    data.

    Did we remove TARGET?
    Did we rename it to 'source'?
    When did we debate this?

(2) The attributes MUST have quotes around them in XML.
    Typo?

	latency=3   -> latency="3"
        action=ask  -> action="ask"
        ...

(3) Why not just include the CAP data in the xml section?
    No CID needed.

(3.1) Why do we need a <select> xml tag?
(3.2) Why not keep the TARGET in the CAP data?

As is, this works:

	<search id="some-session-uid">
	<data>
	BEGIN:VCALENDAR
	TARGET:relcalid-20934
	BEGIN:VQUERY
	QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
	WHERE DTEND >= '19990714T080000Z' AND
	DTSTART <= '19990715T080000Z'
	END:VQUERY
	END:VCALENDAR
	</data>
	</search>

---

From: Patrice Lapierre <[email-masked]>
Date: Tue, 08 Jan 2002 19:14:12 -0500

Doug Royer wrote:
...
> (3) Why not just include the CAP data in the xml section?

  A possible advantage of multiple mime parts is the
different header parameters (e.g., charset, encoding, ...).

  If we include both in the same section we must be careful 
about characters with special meaning in XML (e.g. the <, > 
used your example).

  Note that this could be resolved using the XML <![CDATA[ .. ]> 
construct.

 A good compromise would be to support both (similar to what is 
done in the apex profile):

1.
   <data content="cid:[email-masked]"/>
2.
<data content='#Content'>
<![CDATA[
BEGIN:VCALENDAR
...
END:VCALENDAR
]>
</data>

Note: If and when the XML mapping to iCalendar standardized it
could also be good candidate to the fill of the data element.
  	
...
...

  For the "search" command, <select> may look superfluous, but 
it also used in other commands: "modify", "delete" and "move". The 
use of a single construct to select the targeted component seems 
more consistent.

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 18:02:23 -0700

> could also be good candidate to the fill of the data element.

 I agree.

> use of a single construct to select the targeted component seems

I agree that it is used, I don't agree that it is needed :-)
Without the <search> tags, the CAP server still has the
same information. 

I guess many of my posts boil down to the fact that we have
to stop re-inventing the wheel. We needed to re-do the transport.
But I think that almost all of the data portion had reached
consensus, now we want to change that again. Please that will
cost use a couple more years of debate as each and every
nuance of the changes are debated, tried, rejected, and debated
over and over again until some other transport or data model
is presented and we do it all over again.

Lets JUST alter the transport ONLY, and update the data portion
when we get xml-ical. Otherwise - lets use the data model that
has been debated over the last few years and had already
reached consensus. Not to mention vendors were already coding
to that data model.