Subject: Q: Handling non-conforming ICalendar

From: Mark Swanson <[email-masked]>
Date: Wed, 22 Jan 2003 00:21:25 -0500

Given that I am finding non-conforming ICalendar output from several of the 
most popular ICalendar implementations out there I was wondering how everyone 
else on this list is handling non-conforming ICalendar data?

F.E. ignoring it, modifying your parser to handle bad data, etc...

Thanks.

- -- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web Start:
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp

---

From: Gary Frederick <[email-masked]>
Date: Wed, 22 Jan 2003 08:21:28 -0600

The folks working on rdf-calendar are interested in having iCalendar 
test data. If anyone wants to contribute some test data and tests, I'll 
ask if they want to use it.

Gary

Re: reminder: next IRC calendar meeting 5pm GMT, 2003-01-22
...
http://www.timeanddate.com/worldclock/fixedtime.html?day=22&month=1&year=2003&hour=17&min=0&sec=0&p1=0

irc.freenode.net #rdfig
irc://irc.freenode.net/rdfig

---

From: [email-masked]
Date: Thu, 23 Jan 2003 13:57:34 -0500

Mark wrote on 01/22/2003 12:21:25 AM:
>                                                I was wondering 
howeveryone 
> F.E. ignoring it, modifying your parser to handle bad data, etc...

I don't see any responses from any other implementors yet.    I wonder if 
thats because of some backlog somewhere or everyone not wanting to go 
first...

We (Lotus Notes) took the approach of dealing with some issues by 
adjusting our engine to deal with them but for the most part though we 
took the approach of "If we cannot fully parse it or what we parsed is not 
properly formed then do nothing with it and tell the user about the 
problems." 

It all depends on how 'severe' the non-conformace is.  For example, we 
would NOT do any workflow on the Apple iCal object I used as an example 
yesterday because it had a TZID for the DTSTART and DTEND but NO matching 
(or any for that matter) VTIMEZONE.  Had there been a VTIMEZEONE but the 
lines wrapped at 80 octets instead of 75 then we would have overlooked 
that and let the user act on it.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 23 Jan 2003 14:20:20 -0700

[email-masked] wrote:

> I don't see any responses from any other implementors yet.    I wonder 
> if thats because of some backlog somewhere or everyone not wanting to go 
> first...
> 
> took the approach of "If we cannot fully parse it or what we parsed is 
> not properly formed then do nothing with it and tell the user about the 
> problems."  

My work is mostly on a CS, so I would expect that CUA's that are being
written will have interoperability issues. But trying to guess what
they are in advance is not on my 'to do' list. I agree with Burce
for my project - if it is not parsable - reject it.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Mark Swanson <[email-masked]>
Date: Fri, 24 Jan 2003 09:28:02 -0500

> [email-masked] wrote:
<snip>

Thanks Bruce, Doug.

As you have noticed (at least by my sig) I have released an ICalendar client 
and server, and it's top priority that I interoperate with everyone.

---

From: [email-masked]
Date: Mon, 27 Jan 2003 15:12:06 -0500

Doug wrote on 01/23/2003 04:20:20 PM:
>                                              I agree with Burce

May I suggest that we put in CAP an explicit text/requirement to the 
effect that any bad or incorrectly formed parameters or inputs MUST be 
rejected outright and the command terminated or considered complete?  This 
applys both ways considering that a command can be sent by either side.  I 
can draft up some explicit text if we dont have anything useful already; 
its only a couple lines that are needed I think.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 27 Jan 2003 13:54:25 -0700

[email-masked] wrote:
> rejected outright and the command terminated or considered complete? 
>  This applys both ways considering that a command can be sent by either 
> side.  I can draft up some explicit text if we dont have anything useful 
> already; its only a couple lines that are needed I think.

I would agree and please send text.

--

---

From: [email-masked]
Date: Wed, 29 Jan 2003 15:02:21 -0500

> I would agree and please send text.

Here is my attempt at additions to CAP draft 10-12Jan2003 under Section 
10.  Commands and Responses:

===============================================
10.1 Command input validity

All commands MUST perform a validity check of their inputs to ensure they 
are properly formed for the particular command.  Any invalid, irregular or 
omitted properties or property parameters MUST result in the command 
failing immediately and returning a suitable failure response. 

Omission of optional properties or property parameters is not grounds for 
failure; only omission of required properties or property parameters is 
grounds for command failure.  For example, failure to include an "ACTION" 
parameter with a "LATENCY" parameter MUST result in rejecting the command 
entirely.

Inclusion of unknown but properly formatted properties or property 
parameters is not grounds for command failure.  [Not sure how to best 
phrase this really so that new parameters can be added later that will not 
cause command failure just because they are unknown.]

Command failure results in no action being taken on the inputs and an 
immediate failure response being sent back to the sender.

All CAP command MUST perform input validity checking in order to prevent a 
malformed property or property parameter value having devastating effects 
and unintended side effects.

The failure repsonse is constructed using the following ABNF:

      failure-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                        calprops
                        failure-vreply
                       "END" ":" "VCALENDAR" CRLF

     failure-vreply  = "BEGIN" ":" "VREPLY" CRLF
                         request-status
                         other-props
                        "END" ":" "VREPLY" CRLF

The REQUEST-STATUS property SHOULD provide some indication as to the cause 
of the failure so that corrective action may be taken.  It is recommended 
that a diagnostic entry also be logged in the event of a command failure.

===============================================

There probably is a better or more consistant way to craft a reply that 
indicates the command failed rather than crafting a failure-vreply for 
every TARGET.  I defer to Doug on how to best describe this in an ABNF.

In addition I would change the following text in Section 10.1.5. DELETE 
Command: 

There is no partial success for a "DELETE" command. Ether everything 
succeeds or nothing is done. So if the VREPLY contains X number of 
successful replies and at least one (1) failure then no objects were 
deleted or marked for deletion. This is because a malformed "QUERY" 
property value could have devastating effects and unintended deletion of 
some objects could make a calendar unusable. The CUA could inform the CU 
that their request must be modified in order to succeed. 

by removing the 'if any fail, all fail' text and rephrasing:

The VREPLY may contain any number of successful and failure replies.  If 
the VREPLY indicates success then objects were deleted or marked for 
deletion for the indicated TARGET. If the VREPLY indicates failure then no 
objects were deleted or marked for deletion in the indicated TARGET. 
Success or failure is determined on a per TARGET basis rather than on a 
collective basis.

Thoughts?  Comments?

Bruce