[Ietf-calsify] location location location

[Tim Hare]

Some thoughts (for discussion):  

1. My understanding of RFC 2445 is that "components" are VEVENT, VTODO,
VJOURNAL - i.e. things with dates.  Trying to define a resource as a
component might break this concept.
2. As pointed out before, a resource is an "attendee" of a VEVENT (meeting)
set up by an organizer. Perhaps a VEVENT property that parallels ATTENDEE
would be useful at times.
3. ATTENDEE isn't really designed to hold all identifying information for a
person, instead it holds an indirect pointer (typically the e-mail address)
to the person.  Why should we design into iCalendar description of a
resource? Instead we should have a resource pointer, right? A URI seems
designed for this purpose (but I am not a web expert so correct me if I am
wrong).
4. For public event type publishing, each venue would/should own its own
VCALENDAR that contained all of the events at that venue, just as I own all
of the events describing my appointments and meetings. I point to my
calendar, and my calendar points to me, but that's the main extent of the
link. Maybe it should be the same for venues - they have a pointer to their
calendar, and if you download or otherwise connect to that calendar with
calendaring tools, the resulting object or file should point back to that
venue.

I don't have an easy answer, and I DO see the need for public event
publishing such as Eventful and Upcoming provide. I just don't see
description of the resource as one of the functions of iCalendar - and it
certainly doesn't help simplify the standard to move interoperability
forward.

Just my two cents worth,

Tim Hare
Interested Bystander, Non-Inc.