Is there a way to test iCalendar

I want to test that iCalendar data is valid. I'm generating iCalendar 
data and reading it with the calendar in mozilla. That app uses libical 
and does ok with finding errors. I was wondering if there were other 
ways to validate? Is there a service or ? that would validate iCalendar 
data?

Gary

(unknown)

www.calsch.org moved to new server

Just FYI- if anyone sees problems with the website, please drop me a 
note.  I think we got it all moved over correctly, but if anything is 
amiss, let me know.

The new server should be stronger, faster and able to leap buildings 
in a single bound...  

-Bob

CAP Issue: Where to store METHOD info

All,

Here's a summary of the next CAP issue to nail. We have not yet defined
what we're going to do with METHOD information. We have stated that we
want to move METHOD information into components. But we have not yet
defined a property in which to store the info.  We may not want to store
it in a property named METHOD because that property is already used in
iTIP and it appears in the VCALENDAR container (not a component
container). We need to define the property we want to use.

Once the method information is stored in a VEVENT, VTODO, or VJOURNAL,
it is less an action and more a state. It's name should reflect its
use.  So, something like WORKFLOWSTATE is probably better (though I'm
not wed to that name).

We also need to define how the WORKFLOWSTATE property is added to a
component, especially in the iTIP workflow.  That is, when we store an
iTIP request like

          BEGIN:VCALENDAR
          PRODID:-//ACME/DesktopCalendar//EN
          METHOD:REQUEST
          VERSION:2.0
          BEGIN:VEVENT
          UID:012345
          ORGAGNIZER:cap://cal.example.com/mary-relcalid
          ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/john-relcalid

Re: CAP Issue: Where to store METHOD info

Steve Mansour wrote:
> 
> Do we need something like VITIP ?  or is migrating the METHOD value into
> WORKFLOWSTATE good enough?  Other thoughts?

Tossing PRODID, VERSION and CALSCALE is probably acceptable, but
we should not forget that VCALENDAR components may have x-prop.
Tossing x-prop is probably not acceptable.

The VITIP component proposed in Minneapolis would cover this issue.

Cheers,
Bernard
--

-- 
Bernard Desruisseaux                    mailto:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

Re: CAP Issue: Where to store METHOD info

Steve Mansour wrote:

> All,
> 
> Here's a summary of the next CAP issue to nail. We have not yet defined
> what we're going to do with METHOD information. We have stated that we
> want to move METHOD information into components. But we have not yet
> defined a property in which to store the info.  We may not want to store
> it in a property named METHOD because that property is already used in
> iTIP and it appears in the VCALENDAR container (not a component
> container). We need to define the property we want to use.

(I'll address your VERSION and PRODID questions in a separate email)

I think we are making this too complicated - lets go back to simple.
So forget what you know and listen to my proposal 

There are two kinds of objects - iTIP and non-iTIP objects.
Non-iTIP objects are anything not defined in iTIP (or any later
version of iTIP). These are also called scheduling requests (not REQUEST).

The METHOD is never 'moved' into the component. It is an implementation
detail on how the CS 'knows' that any object was stored into the
CS where the iTIP object had a iTIP METHOD:{whatever} .

	SELECT * from VEVENT where METHOD = 'REQUEST'

As long as the CS returns all VEVENTs that were stored into the CS
with iTIP METHOD:REQUEST. And the CS returns a VALID iTIP object, it

Re: CAP Issue: Where to store METHOD info

Steve Mansour wrote:

> All,
> 
> Here's a summary of the next CAP issue to nail.
> ...
> 
> 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?

VERSION - it is the VERSION of the iCalendar wire format - not data.
As long as the CS returns VALID iCalednar objects, and the CUA sends valid 
iCalendar objects - it DOES NOT MATTER if the CS stores VERSION or not.
I say we leave it un-specified. I'll store it in case we ever bump
the iCalednar object format version. I'll always return the correct
VERSION over the wire to the CUA.

How about we add to CAP:

	 It is not valid to query by VERSION as it has no meaning.
          VERSION is the format over the wire format of the iCalendar object
          and it is NOT the VERSION of the data.

          A CS MAY store the VERSION. The CS MUST always return
          a correct VERSION in the iCalendar objects. A CUA
          MUST always send a valid VERSION.

Re: CAP Issue: Where to store METHOD info

Doug wrote:

>VERSION - it is the VERSION of the iCalendar wire format - not data.

Doug, I don't think this is true.  From 2445:

>4.7.4 Version
>
>   Property Name: VERSION
>
>   Purpose: This property specifies the identifier corresponding to the
>   highest version number or the minimum and maximum range of the
>   iCalendar specification that is required in order to interpret the
>   iCalendar object.

That says to me that VERSION refers to all layers of the spec, the format 
and the data.  Suppose, in 2258, the IETF releases RFC-102245, which 
updates iCalendar with the ATMOSPHERE property, describing what type of 
atmosphere will be available at the meeting.  Kosh, a methane breather, 
sends an invitation to Fred, an oxygen breather.  Kosh's implementation 
sends "ATMOSPHERE:METHANE"; in order to interpret the iCalendar object 
correctly, Fred's implementation needs to understand RFC-102245.  (It 
could just ignore the ATMOSPHERE property, but then Fred's estate will 
probably sue the software vendor.) This means that adding the ATMOSPHERE 
property to the spec requires a new VERSION.

/=============================================================\
|John Stracke                    |Principal Engineer          |
|jstracke <at> incentivesystems.com   |Incentive Systems, Inc.     |

Re: CAP Issue: Where to store METHOD info

John Stracke wrote:

> Doug wrote:
> 
> 
>>VERSION - it is the VERSION of the iCalendar wire format - not data.
>>
> 
> Doug, I don't think this is true.  From 2445:
> 

Let me clarify what I meant:

VERSION - it is the VERSION of the iCalendar wire format - not the properly 'values'.

So the CS MUST know the format of the object (VERSION), but it need not
be stored. And the CS and CUA MUST generate objects with the correct VERSION
on the wire. So it does not matter what version is in the STORE, it matters
what is on the wire. A CS MAY wish to store the VERSION, and the CS
is responsible for sending a correct VERSION - no matter what is in the STORE.

Agree?

-Doug

Re: CAP Issue: Where to store METHOD info

>VERSION - it is the VERSION of the iCalendar wire format - not the
>properly 'values'.

This is not so.  The values are meaningless unless you can interpret them; 
and they must be interpreted in the context of a particular version.  And 
there's no way you can reconstruct the VERSION from the values.  Suppose 
version 9.0 says that, if you don't have the LOCATION property set, it 
implies that the meeting is being conducted via telepresence? (Could be a 
perfectly reasonable assumption by that time.) You get a version 1.0 
VEVENT, which doesn't specify LOCATION; you discard the VERSION; when the 
time comes, your CUA starts trying to contact the other attendees, and 
failing.

I believe the CUA MUST get the same VERSION that the CS received.

/========================================================\
|John Stracke                    |Principal Engineer     |
|jstracke <at> incentivesystems.com   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Don't anthropomorphize computers. We don't like it.     |
\========================================================/