The sharing spec says the sharer may choose to include alarms and event status when publishing; likewise the sharees may choose to filter out alarms/status when subscribing. This is fine in a "one-way" share situation like iCal. However, since Chandler sharing is bi-directional, if a sharee decides to discard alarms/status but then writes back a changed item to the server, that discarded data is lost.

One possiblity is to make the alarm/status filtering a property of the Share, and the sharer initially determines what filtering to do, and all clients adhere to that. Let's see how that covers the main scenarios:

1. Sharing a calendar with yourself (to sync multiple machines, or as a backup): you would allow alarms/status to be published; changes made to alarms/status on any machine would propagate to all other subscribed machines.
2. Sharing a group calendar: you would not allow alarms/status to be published; all subscribers would have "private" alarms/status values that don't get propagated to others.
3. An Executive/Administrative-Assistant pair: same as 1)

If this is not sufficient, there are a couple possibilties for avoiding the "discarded data" problem:

1. Have the clients keep around a copy of any attribute values that the received from the server but are "discarding" (not applying to local items), so that when it comes time to write those items back to the server, those attribute values can be substituted back into the transmitted XML. However, this could end up overwriting info that the sharer published. This also gets really complicated because a given item can belong to multiple shares, and you would have to keep separate copies (a set per share) of the discarded attributes.
2. When a filtered item is being written back to the server, the client avoids overwriting filtered attributes by keeping around a representation of the XML and modifies only certain values in the XML document; slightly better than 1 in that you only have to keep around that XML representation during the sync operation; however, you could end up using a lot of memory keeping those XML documents around.
3. The server understands filtering and handles this for us; I don't think this is on the radar.

I think given the complexity of these other solutions, I would recommend for now that attribute filtering is a property of the share, and that the sharer determines the filtering.