SOAP API differences in v5.0.0

[notify]

We have been doing some testing against v5.0.0 and noticed a couple differences from testing against the previous release (v4.5.9 and v4.5.10). We can probably make changes to work around these differences but I wanted to check if these are expected.

Thanks in advance for any input!


1) When an event or task is changed and then a SyncRequest SOAP API call is made against Zimbra v5.0, the appt element is present in the SyncResponse, but the inv element is not as it was when going against previous versions of Zimbra. Was this intentionally not included in Zimbra v5.0?

2) When creating an appointment using the CreateAppointmentRequest SOAP API call against Zimbra v5.0, the following is returned from Zimbra:

invalid request: missing required attribute: action

An “action” attribute is not required when going against previous versions of Zimbra.

[jhahm]

inv element is no longer returned under appt of a SyncResponse. Please change your code to make a GetAppointmentRequest to get the full data. I believe it used to be returned by accident.

Can you provide more detail on the second issue? What is the full request you're making, and what is the full exception stack trace in /opt/zimbra/log/mailbox.log? If it's complaining about "action", I wonder if your request is somehow triggering folder move operation. But I need to see the entire data to better understand what's going on.

[notify]

Thanks for the response. I created a txt file attachment with the requested information about the request and the stack trace.

[jhahm]

Thanks. The stack trace points out it's the alarm element.

SOAP API for 4.5 said alarm element had a single attribute called rel-start, but it actually wasn't implemented and was inadequate to describe a RFC2445 VALARM component. In 5.0 alarm element was redefined. The relevant section in soap-calendar.txt is:

// VALARMs (RFC2445 Section 4.6.6)
[
<alarm action="DISPLAY">
<trigger>
// <rel> has the same attributes as <dur> and an optional
// "related" attribute. Default value of "related" is "START".
<rel [related="START|END"] .../> OR <abs d="YYYYMMDDThhmmssZ"/>
</trigger>
<desc>{reminder text to display}</desc>
// <repeat> has the same attributes as <dur> and an additional
// required count attribute. The duration is how often to repeat
// the alarm, and the count is how many times to trigger the
// alarm IN ADDITION TO the initial alarm.
[<repeat count="N" .../>]
</alarm>
]*
[
<alarm action="AUDIO">
<trigger/> // same as in DISPLAY alarm
[<repeat/>] // same as in DISPLAY alarm
[
<attach ct="{content type}" uri="{uri}"/>
OR
<attach>{base64-encoded binary data}</attach>
]
</alarm>
]*
[
<alarm action="EMAIL">
<trigger/> // same as in DISPLAY alarm
[<repeat/>] // same as in DISPLAY alarm
<desc>{email body}</desc>
<summary>{email subject}</summary>
<at .../>+ // attendees (one or more email recipients)
[<attach ... />] // sam as in AUDIO alarm
</alarm>
]*
[
<alarm action="PROCEDURE">
<trigger/> // same as in DISPLAY alarm
[<repeat/>] // same as in DISPLAY alarm
[<desc>{description text}</desc>]
<attach ... /> // same as in AUDIO alarm
</alarm>
]*

The syntax is pretty much a one-to-one mapping from RFC2445 VALARM.

Most alarms will have DISPLAY action value. The other action types are there simply because the RFC defines them. Each client must deal with the types as appropriate. For a mobile client, I would expect a pop up alert of some sort is adequate in all cases.