[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CAP Draft 6 comments
Thanks to a delayed flight, I managed to get through the entire draft.
Here are some things I noted (I'm not listing all the typos):
Section 2.1. We can use BEEP as a handle for "transport protocol",
However, there was no explicit mention of an "application protocol". I
believe that is what CAP has become now that we use BEEP. I think
it's important to state it.
Section 2.2 - We refer to many new components before ever listing them
and before we provide even a one-liner describing what they are. I think
a table that lists each of the components CAP deals with and a quick one-line
description would be really useful.
Is there a VSCHEDULE anymore? We still refer to it in 2.2.
Section 2.4.4 we mention trusted server relationships. We should mention
explicitly that this is out of the scope of [CAP]
Section 2.6 - we mention "printable 7 bit ASCII characters". Is this
sufficiently explicit? Should we list the character value range?
Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't
Section 4.1.2 Use 'DTSTART <= ...' -- the two strings look identical.
I think it's a typo... or is it?
What was intended for 4.1.3 Querying Experimental Properties ?
Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some places,
we refer to the METHOD value for "booked" events as NULL, and in other
places we refer to it as CREATED. I happen to prefer being explicit
and keeping it at CREATED, but whatever we choose we must be consistent.
Section 4.1.6 -- I thought we decided that we need a METHOD state for a
CANCELled event or a DELETEd event. This is important for several reasons.
One was mentioned in the draft, another is that it's important for synchronization
applications to determine which events have been deleted. If we use the
METHOD property to mark cancelled / deleted events, then the query needs
to be fixed.
Section 6.1.3 needs an example
We need to close on the iCalendar version we're going to require for CAP.
In the current draft we specify that we require VERSION 2.0 and VERSION
2.1. Let's pick one :-)
Section 22.214.171.124. (and most of the other commands that follow it)
-- need more error return values to be listed. All commands are showing
2.0, 6.1, 6.3. But there are many other errors that can occur; security
violations, etc. We need to list them.
Section 126.96.36.199. Regarding the editors note - my recommendation
is that the way to delete a VALARM is to modify or delete the component
that contains it. The delete command should apply to the VTIMEZONES
that exist at the calstore level. I don't think components like VEVENTS
can contain VTIMEZONE components, I think they only reference VTIMEZONE
components that exist at the calstore level.
Section 188.8.131.52. Are there sequencing (ordering) issues? are removes
always processed before updates? does it matter?
Section 184.108.40.206. The returned REQUEST-STATUS has a single 2.0 return
value, yet many error conditions can occur. Some of the requested edits
/ removes may be successful while others are not (perhaps due to access
control). When multiple errors occur, is there a separate REQUEST-STATUS
for each update/remove that failed?
Section 220.127.116.11. "CS MUST ensure that VCARs are still valid after the move"
seems pretty nebulous to me. I think the issue is the following: given
that VCARs are hierarchic, moving a calendar from one location in the hierarchy
to another could possibly change the access control considerably and yield
unexpected and unwanted results. I think what we want to do is make
sure that the access control is at least as restrictive (and possibly more
restrictive) than it was prior to the move. Note that with hierarchic
VCARs the way they are defined now, it may not be possible to provide exactly
the same access to a calendar as prior to the move -- something further
up the new hierarchy may be more restrictive. Also, there are ownership
issues. Is there something we want to say about the ownership of the new
parent calendar(s) given the owners of the previous parent calendars?
(this problem is pointed out in the editors note).
Section 18.104.22.168, in the example query for moving "Nellis" to "area-51"
there can only 0 or 1 calendars will match the query. Do we want to put
in a statement that discusses what would happen if the query resulted in
multiple calids (I'm not sure what it means). Or do we want to state
that the query can only produce 0 or 1 result, and if more than 1 calids
result from the query it would be an error ?
Section 22.214.171.124, just past the last example we show this query:
QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE
is being used as a special keyword here. We should probably list this somewhere
or find another way to do the query.
Section 126.96.36.199 was the Organizer intentionally left out of
the ATTENDEE list? Seems like the organizer should be in the attendee
Section 188.8.131.52 the second part of the example is wrong.
C cannot send a DECLINECOUNTER. DECLINECOUNTER is sent by the Organizer
to the Attendee who countered. C is not the Organizer. We'll
title:Director of Engineering
adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043;