[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CAP Draft 6 comments

Hey All,

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):

  1. 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.
  2. 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.
  3. Is there a VSCHEDULE anymore? We still refer to it in 2.2.
  4. Section 2.4.4 we mention trusted server relationships. We should mention explicitly that this is out of the scope of [CAP]
  5. Section 2.6 - we mention "printable 7 bit ASCII characters".  Is this sufficiently explicit? Should we list the character value range?
  6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't they match?
  7. Section 4.1.2 Use 'DTSTART <= ...'  -- the two strings look identical. I think it's a typo... or is it?
  8. What was intended for 4.1.3 Querying Experimental Properties ?
  9. 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.
  10. 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.
  11. Section 6.1.3 needs an example
  12. 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 :-)
  13. Section 6.2.4.1.  (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.
  14. Section 6.2.4.2.  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.
  15. Section 6.2.4.3.  Are there sequencing (ordering) issues? are removes always processed before updates? does it matter?
  16. Section 6.2.4.3.  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?
  17. Section 6.2.4.4. "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).
  18. Section 6.2.4.4, 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 ?
  19. Section 6.2.4.5, 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.
  20. Section 6.3.3.1   was the Organizer intentionally left out of the ATTENDEE list?  Seems like the organizer should be in the attendee list.
  21. Section 6.3.3.4   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 fix it.
begin:vcard 
n:Mansour;Steve
tel;fax:408-276-4930
tel;work:408-276-4268
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@xxxxxxxxxxxx
title:Director of Engineering
adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043;
x-mozilla-cpt:;28912
fn:Steve Mansour
end:vcard