Subject: Questions about CAP draft

From: [email-masked]
Date: Tue, 8 Aug 2000 15:48:42 -0700 (PDT)

The CAP draft seems to be progressing nicely, and I have a few
questions/requests regarding the latest version. 

1) Why is the METHOD property in the parent container of a VEVENT in
RFC2446, but in the VEVENT in CAP? The METHOD is easy enough to move
when you store a component, but then you have to know where you got a
component from to know where to look for the method; it will be in a
different place in a component received in a CUA from iMIP than for one
received via CAP.  Can we have the METHOD property in the same place in
both?

I'd suspect that this is a planned change for the iCalendar-2 draft, but I
did not see it in the list. 

2) The current example of the AUTHENTICATE command in section 7.1.3 of the
latest CAP draft shows the capabilities being returned in a VCALENDAR
container, but the capabilities are not in RFC2445 format == They have "="
separating the name from the value. Furthermore, they are in a different
format than if they were returned from the CAPABILITIES command -- the
CAPABILITIES command does not contain them in a VCALENDAR. 

Can we have these two forms be the same, and have them in RFC2445 format
-- that is, make all of the capabilities be properties? I really don't
want to have a different parser to handle these when they are nearly
identical to properties except for the "=" character.

thanks, 

eric.

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Aug 2000 16:29:39 -0700

> received via CAP.  Can we have the METHOD property in the same place in

I think you are referring to the schema or query?

In the store you are going to have to know the difference between
iTIP data that has not been processed by the CUA and data
that has been processed by the CUA.

There was debate in Montreal last year about storing all
unprocessed iTIP data in a separate table, then as the CUA would
process the data; move it to the store, delete it, and respond
with any required responses.

The other model was store everything in one schema with a tag
that indicated the status of the data. We debated what this
tag should be, then concluded that it was identical to iTIP
METHOD + one tag for "done". We call the "done" tag booked
or METHOD:CREATE as it is identical to a CUA depositing a
non-iTIP'd component directly in the CS.

So on the wire iTIP/iMIP VEVENT does not have a method.
And even a CUA that does a VQUERY to get a VEVENT does not
see the METHOD inside the VEVENT.

Or - we have a typo bug in the spec ? :-)

> I'd suspect that this is a planned change for the iCalendar-2 draft,
> but I did not see it in the list.

No. It is not a change. If it's not the schema or VQUERY, it
may be a spec bug.

> 2) The current example of the AUTHENTICATE command in section 7.1.3 of
> the > latest CAP draft shows the capabilities being returned in a
> VCALENDAR container, but the capabilities are not in RFC2445
> format == They have "="  separating the name from the value.
> Furthermore, they are in a different format than if they were
> returned from the CAPABILITIES command -- the CAPABILITIES
> command does not contain them in a VCALENDAR.

> identical to properties except for the "=" character.

Excellent catch (= vs :) Cut/Paste too many hours on the keyboard error.

I also think they should use ":" and the values returned by the
CAPABILITIES command should be in a VCALENDAR (with ":")

If there are no objections - I'll make that change in the doc.