No, Your example is not valid iTIP for an VEVENT/REQUEST.
Syntax errors:
You have multiple definitions of UID=foo without any RECURRENC-ID specified. This means that you have ambiguous definition of the VEVENT where UID=foo. If you specify the UID only, then this means that you are referring to the complete recurrence set.
You only specify an ATTENDEE that matches the ORGANIZER. If this is a group scheduled event, then by definition (when two or more of you get together...) you need attendees other than the ORGANIZER. iTIP restriction table for VEVENT/REQUEST specifies "1+" which means more than one.
Semantic errors:
Your VEVENT specifies a DTSTART with a date-time value type. This means you need a DTEND. If you mean all-day, then you MUST not specify a date-time value type, unless you specify a DTEND.
As mentioned above, your semantics for this iCalendar object are ambiguous, as you specify the same UID in all the VEVENTs, but no RECURRENCE-ID. This implies that the scope for each VEVENT definition is the complete recurrence set for UID=foo.
As mentioned above it is unclear who the participants are in the meeting, besides the ORGANIZER. You need to specify other participants or this is not a group scheduled meeting, but rather an appointment. Hence, no one would be issuing a REFRESH on the event.
Which leads to another semantic error/issue. If you receive a REFRESH from a CUA that is not represented by an ATTENDEE value in the calendar component, then you MUST NOT respond to this REFRESH. This is a security threat by someone that is probing your calendar data base. See section 3.2.6, 'The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description...". This means that non-attendees are NOT supposed to be using this to get calendar info. These types of requests are security threats.
Hope this helps.
-- Frank
Frank_Dawson@lotus.com wrote:
>
> This is improver iCalendar sytax. No "UID", no "SEQUENCE", etc.
> Maybe you weren't trying to be precise?
>
> You can only add events to an existing request with an "ADD" method;
> not a "REQUEST".
>
> Dan's point was not just the scenario for adding an occurrence, but
> changing some other details in an occurrence so that a single
> REQUEST would actually obliterate the differences. You are right,
> for this you might be able to use a second REQUEST with an
> incremented "SEQUENCE" value and a "RECURRENCE-ID" to show the
> different property values from the original occurrence set. That is,
> as long as the occurrence was defined in the occurrence set defined
> by the initial "REQUEST".
>
Frank,
I was replying to what you said here
(Message-ID: <>):
> That is good! I forgot about this case. This is the case where you
> send out a REQUEST (SEQUENCE=0), then follow it up with a
> REQUEST (SEQUENCE=1, RECURRENCE-ID=19990726T133000Z) that changes the
> LOCATION (or some such peripheral property).
> Now you can't just send one REQUEST reply to the REFRESH. The
> RECURRENCE-ID values specifies one occurrence that will need
> a separate REQUEST to specify the different LOCATION property (or
> whatever).
I don't think that you ever need separate REQUESTs to respond to
a refresh. The following is valid iTIP, and shows how a single
REQUEST can include instance specific information. (Each recurrence
has a different location.) This could be an initial REQUEST
(SEQUENCE:0) or a response to a REFRESH.
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:bad string
VERSION:2.0
BEGIN:VEVENT
LOCATION:My place
UID:foo
ATTENDEE:mailto:bar@foo.tv
ORGANIZER:mailto:bar@foo.tv
DTSTART:19990712T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT
BEGIN:VEVENT
LOCATION:Martha's place
UID:foo
ATTENDEE:mailto:bar@foo.tv
ORGANIZER:mailto:bar@foo.tv
DTSTART:19990719T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT
BEGIN:VEVENT
LOCATION:Local pub
UID:foo
ATTENDEE:mailto:bar@foo.tv
ORGANIZER:mailto:bar@foo.tv
DTSTART:19990726T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT
END:VCALENDAR
Alex