Subject: [Ietf-calsify] RFC 2445: URL versus ATTACH property

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu May 24 12:07:26 2007

Both Apple iCal and Mozilla Sunbird/Lightning provides user
interface to allow users to specify a "URL" in a calendar
component.

Both clients store the "URL" specified by the end user in the
"URL" property which is described as follows in RFC 2445:

 > This property may be used in a calendar component to
 > convey a location where a more dynamic rendition of
 > the calendar information associated with the calendar
 > component can be found.

I'm having a really hard time believing that end users will
actually specify "a location where a more dynamic rendition
of the calendar information associated with the calendar
component can be found".

I can only imagine that end users will actually specify an
external attachment in this field, and as such, this value
should be stored in the ATTACH property.

What do you think?

Cheers,
Bernard

---

From: bcm at osafoundation.org (Brian Moseley)
Date: Thu May 24 12:24:40 2007

> of the calendar information associated with the calendar

i think this happens quite regularly in practice. for example, i often
use URL to specify evite urls for parties and upcoming.org urls for
concerts and other public events.

---

From: douglm at rpi.edu (Mike Douglass)
Date: Thu May 24 12:48:20 2007

We use this for public events to link to a related web site.

We discourage our administrators from trying to turn the calendar into a 
web site.

We would use attachments for providing other information - pdfs etc.

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

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies
518 276 6780(voice) 518 276 2809(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu May 24 23:56:22 2007

> Both clients store the "URL" specified by the end user in the

KOrganizer and all other KDE applications using this kind of stuff use thee 
ATTACH property.

> should be stored in the ATTACH property.

I fully agree with your assessment here.

The URL property (according to the wording of the RFC) should rather be used 
e.g. for a link to the event's page on the groupware server (e.g. the page to 
edit / view the event on the exchange or OpenGroupware server)

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri May 25 07:43:27 2007

Hi Reinhold,

--On May 25, 2007 8:55:16 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> KOrganizer and all other KDE applications using this kind of stuff use
> thee  ATTACH property.
>
> The URL property (according to the wording of the RFC) should rather be
> used  e.g. for a link to the event's page on the groupware server (e.g.
> the page to  edit / view the event on the exchange or OpenGroupware
> server)

A more fundamental question to ask here is how clients/servers actually 
interpret the URL property. If they simply provide a clickable link for the 
user, then frankly, it doesn't matter what goes in there, so long as it has 
some relevance to the event (that's how I interpret the "dynamic rendition 
of the calendar information" statement in the rfc) - and at the end of the 
day someone authoring an event is going to put a URL that is of relevance 
to that event in there.

If, on the other hand, clients/servers attempt to do some automatic 
processing based on URL, then the semantics of those need to be very 
explicit. But the statement in the spec is very vague as to what might be 
there - client servers would potentially have to cope with any type of URL 
pointing to any type of data. The spec does not say the "dynamic rendition" 
has to itself be actual calendar data.

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Fri May 25 07:54:20 2007

Cyrus,

> explicit. But the statement in the spec is very vague as to what might 
> be there - client servers would potentially have to cope with any type 
> of URL pointing to any type of data. The spec does not say the 
> "dynamic rendition" has to itself be actual calendar data.

Other than passing this information to the browser it's not clear what 
one would do, given the dearth of semantics.

Eliot

---

From: douglm at rpi.edu (Mike Douglass)
Date: Fri May 25 07:58:02 2007

In our public events calendar we present it as a link to further 
information - no automatic processing. Almost always points to a web page

Cyrus Daboo wrote:
> A more fundamental question to ask here is how clients/servers 
> actually interpret the URL property. If they simply provide a 
> clickable link for the user, then frankly, it doesn't matter what goes 
> in there, so long as it has some relevance to the event (that's how I 
> interpret the "dynamic rendition of the calendar information" 
> statement in the rfc) - and at the end of the day someone authoring an 
> event is going to put a URL that is of relevance to that event in there.
>

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri May 25 08:55:15 2007

Hi Mike,

> information - no automatic processing. Almost always points to a web page

Is the value set automatically or do users/admins get to set/edit it?

-- 
Cyrus Daboo

---

From: douglm at rpi.edu (Mike Douglass)
Date: Fri May 25 12:52:51 2007

It's one of the fields they set when they add an event.

 From the uwcal days the amount of data allowed in the description has 
been limited to 500 characters. We kept it that way to prevent 
administrators from putting entire documents into the description.

Our hope is to have mobile device access to the calendar and limiting 
the amount of event data seems appropriate. Many of these public events 
already have an associated web site or page.

We don't automate the setting (though we had thought of adding a feature 
to a cms which would automatically generate an event with a link back to 
the page)

--

---

From: pbh at MIT.EDU (Paul B. Hill)
Date: Fri May 25 18:41:54 2007

The lack of semantics is unfortunate. We know that for years customers 
of certain products have been asking for lazy evaluation of attendee 
lists defined by groups.

What is less frequently mentioned is that over time the location 
changes, the agenda changes, and almost any of the other descriptive 
data about an event might change. My impression is that people are 
packing the information into URLs when they can and asking user to pull 
this information because some products, and site specific product 
configurations make it difficult to capture and disseminate these 
variations otherwise.

Paul

---

From: TimHare at comcast.net (Tim Hare)
Date: Sat May 26 17:27:10 2007

I believe the best use case for URLs (not excluding what others do with
them) is for drag-and-drop; for example I could drag the URL for the web
site describing the Woodstock Music and Art Fair to my calendar for August
15th, 1969 and my calendar UI could then put the URL into some property of
the component - it may be an X- property, or it could be COMMENT or
DESCRIPTION.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mike Douglass
Sent: Friday, May 25, 2007 3:52 PM
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-calsify] RFC 2445: URL versus ATTACH property

 From the uwcal days the amount of data allowed in the description has been
limited to 500 characters. We kept it that way to prevent administrators
from putting entire documents into the description.

Our hope is to have mobile device access to the calendar and limiting the
amount of event data seems appropriate. Many of these public events already
have an associated web site or page.

We don't automate the setting (though we had thought of adding a feature to
a cms which would automatically generate an event with a link back to the
page)

--

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Sat May 26 18:51:27 2007

Hi Tim,

> the component - it may be an X- property, or it could be COMMENT or

Right its not clear exactly what the utility of using URL is as opposed to 
pasting into the DESCRIPTION field (I don't think I've seen any clients 
giving their users a way to set the COMMENT property). What's more, URL is 
only allowed once in any VEVENT, so if you wanted to put links to multiple 
items, you would have to use description anyhow.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun May 27 03:43:36 2007

Am Sonntag, 27. Mai 2007 schrieb Cyrus Daboo:
> What's more, URL is

We use the ATTACH property for this.

Cheers,
Reinhold

- --