... continued:
Section 3.1
seems superfluous and covered in BEEP. do we really need this?
Section 3.2
(already posted to the list because we're trying to resolve this now). The XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines:
ENCAPSULATION A
C: MSG 1 2 . 1234 123 C: Content-type: application/cap+xml C: C: <cap latency="3" action="ask"> C: <![CDATA[ C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH ... C: END:VCALENDAR C: ]]> C: </cap> C: END
The XML encapsulation is innocuous, but it adds nothing. Further, it tempts us to move things out of the Application layer and into the Transport layer (such as the command names, and attributes such as "latency" and "action" -- undermining the transport/application separation and leading us down slippery slopes. Here is a simpler alternative (and yes, I know some of you have been pushing for something like this all along :-) :
ENCAPSULATION B
C: MSG 1 2 . 1234 123 C: Content-type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH C: LATENCY:3 C: ACTION:ASK ... C: END:VCALENDAR C: END
The advantage of encapsulation B is that it represents exactly the same content as encapsulation A, but it uses one rather than two encapsulations and there are no hints about the calendaring commands in the transport. We could substitute *any* transport.
Section 3.3
Second paragraph should end with a sentence describing what happens on an aborted command. The easy thing to do is something like this:
Partial results indicating homw much of the command completed MAY be returned.
Or we may want to get more ambitious require a precise reply.
The third and fourth paragraphs will need to go wherever we define Latency and Action.
The last RPY message on the last example of the section. This should probably become an application level error reply rather than a transport level reply.
Section 4.1
bullet (1) -- we should state how to handle Parameters, and how to handle components that contain other components.
bullet (3) -- what is the reasoning behind this limitation?
bullet (7) -- I'm not sure I understand the problem here. Can someone illustrate the point we're trying to make with an example?
bullet (7) -- do we really need USING_PROPERTIES and
USING_COMPONENTS ? I don't see the value based on the examples. Is
it just a shorthand to save characters?
Section 4.1.1 - FLOATING TIME EVENTS
We need to clarify how we search for floating time events. If we're going to send UTC times in queries, then I don't see how we can search for floating time events. Seems like the only way to get the "floaters" is to do a separate query for them where we specify the floating time range for the query.
Section 4.1.1
I'm just confused by reading it. I think it needs to be made clearer. The examples are throwing me off.
Section 4.1.1
bullet (7) - There's still a reference to CONTAINS(). Also, the next to the last paragraph seems like it will be a problem. When the schema is updated, servers won't know whether a new component / property is multivalued or not.
Section 4.1.1
bullet (8) - There were some typos fixed, but it seems like there are two logic errors.
'%,%' IN parameter should match NONE -- currently says it matches (d) and (e) LIKE(parameter, ',') should match (e) -- currently says it would NOT match any
Section 4.3
This is really not an issue with section 4.3. It just became clear when I read the example. I don't think we've defined anywhere that we're moving METHOD into components. We need to define this property somewhere. Also, as we're using it in the VEVENT, VTODO, and VJOURNAL, it is less an action and more a state. It's name should reflect its use. So, something like WORKFLOWSTATE is probably better.
We need to define when it is set, especially in the iTIP workflow. I recommend that the CUA be responsible for explicitly setting this
Another problem associated with this is that when data is migrated out of an ITIP wrapper and into a component, it will be a lossy transformation as things stand today. For example, consider the following ITIP request:
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ... END:VEVENT END:VCALENDAR
We are talking about migrating the METHOD:REQUEST value into a new component property like WORKFLOWSTATE. But what about information like PRODID and VERSION ? Might those or other values contained in the VCALENDAR become significant over time? Do we just toss them?
One suggestion in Minneapolis was to create a new component called VITIP that would contain everything in the ITIP request.
Do we need something like VITIP ? or is migrating the METHOD value into WORKFLOWSTATE good enough?
Section 4.7
In the example:
BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT USING_COMPONENT VALARM my-alarm WHERE my-alarm.TRIGGER >= '20000101T030405Z' AND my-alarm.TRIGGER <= '20001231T235959Z' AND METHOD = 'CREATE' END:VQUERY
use of "USING_COMPONENT" seems like it's not buying us much. Seems like this example could actually be shortened by writing it without the USING_COMPONENT line:
BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT WHERE VALARM.TRIGGER >= '20000101T030405Z' AND VALARM.TRIGGER <= '20001231T235959Z' AND METHOD = 'CREATE' END:VQUERY
The example may simply not constructed to show the real value of "USING_COMPONENT". Can someone describe the real value of this? Or can we drop it? Same thing for "USING_PROPERTY".
Section 4.7
The example just reminded me: I propose that we add a UID property to VALARM. We (Netscape) have implemented a calendar server where this value is very useful. Our experience has been that you have to jump through hoops to figure out which of multiple alarms you need to work on if you don't have this UID value.