Subject: [Ietf-calsify] location location location

From: lear at cisco.com (Eliot Lear)
Date: Thu Apr 6 02:42:09 2006

Hello all,

Do people see a standard way or "best" way to handling reservations
regarding locations, such as meeting rooms?  Also, at a company like
Cisco it seems to me that we would want to tag something about a
conference bridge.  Is this the sort of thing that is ripe for
standardization?  Right now there are a few proprietary hacks so far as
I can tell.  Or perhaps I'm just showing my ignorance for all to see?

Eliot

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Apr 6 06:27:42 2006

Hi Eliot,

> I can tell.  Or perhaps I'm just showing my ignorance for all to see?

I guess right now most system handle meeting rooms etc by given them their 
own calendar and allowing them to be part of the normal 
free-busy/invitation process.

Actually a number of folks in Calconnect have been working on 'venue 
information' embedded in iCalendar data. Specifically the current Location 
property is not ideal for describing details about a location that can be 
parsed into constituents parts (e.g. address, box office phone number, map 
URL, website etc) but that is really needed for public event descriptions.

Several possible solutions have been examined, including embedding vCards, 
creating new properties similar to vCard items, and the favored solution a 
new component type. It seems like the 'capabilities' of a venue is what you 
are after - e.g. seating capacity, AV equipment etc The problem with that 
is that there are so many potential variables involved and its not always 
clear what criteria could be used for doing bookings etc. We probably want 
to avoid turning iCalendar into a resource tracking system too, so any 
effort along these lines needs to be carefully scoped.

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Thu Apr 6 07:47:55 2006

Cyrus & All,

Thanks for your thoughts.  Please see below:
>
> I guess right now most system handle meeting rooms etc by given them
> their own calendar and allowing them to be part of the normal
Right.
> information' embedded in iCalendar data. Specifically the current
> Location property is not ideal for describing details about a location
> that can be parsed into constituents parts (e.g. address, box office
> phone number, map URL, website etc) but that is really needed for
> public event descriptions.
Yes, that would be interesting.
>
> Several possible solutions have been examined, including embedding
> vCards, creating new properties similar to vCard items, and the
> favored solution a new component type. It seems like the
> 'capabilities' of a venue is what you are after - e.g. seating
> capacity, AV equipment etc The problem with that is that there are so
> many potential variables involved and its not always clear what
> criteria could be used for doing bookings etc. We probably want to
> avoid turning iCalendar into a resource tracking system too, so any
Indeed.  Do others think this is an interesting area of exploration?

Eliot

---

From: Anil.Srivastava at Sun.COM (Anil SRIVASTAVA)
Date: Thu Apr 6 13:04:52 2006

On 2006-04-06/09:28 [-0400], [email-masked] [Cyrus Daboo] wrote:

> > standardization?  Right now there are a few proprietary hacks so far 
> > as I can tell.  Or perhaps I'm just showing my ignorance for all to 
> > see?
> 

Having standard fields for common resource attributes (capacity, phone 
number, AV equipment, etc) is a very common request from calendar users.  

Now if we could model these as a properties of the calendar (including 
resource and user calendar), then that would be information that clients 
could consume when trying to find the 'right' resource for a meeting.

So I think there is a need for new component, one that can be attached 
to the calendar and encapsulates properties of the calendar.

Anil

> 
> -- 
> Cyrus Daboo
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

_______________
Anil SRIVASTAVA
[email-masked]

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Apr 6 19:06:51 2006

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.

---

From: lear at cisco.com (Eliot Lear)
Date: Fri Apr 7 00:05:45 2006

Tim,

Great message.  I think you've crystallized something I've been trying
to sort, which is do the characteristics of a meeting room belong in the
standard itself or should that be dealt with elsewhere?  Often times
conferences rooms are listed in LDAP *anyway*.  Is there/should there be
a standard schema for this sort of thing?

Eliot

---

From: leifj at it.su.se (Leif Johansson)
Date: Sun Apr 9 02:36:00 2006

> a standard schema for this sort of thing?

The COSINE schema contained a room objectclass with basic information
such as roomNumber, name and description. I don't know how widely
deployed it is though and you would have to expand on it to be able to
support any sort of capability-discovery for scheduling.

I suppose it is doable.

	Cheers Leif