Subject: [Ietf-calsify] Attendees without email addresses

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Mar 14 07:26:51 2007

Hi all!
While playing around with the ics validator 
(http://severinghaus.org/projects/icv/), I stumbled upon a little problem 
that I have not yet realized and what might be cleared in a Best Practices 
document or in an FAQ:

When an attendee (or an organizer) does not have an email adress (or any other 
type of unique URI), what shall be the value of the ATTENDEE property? E.g. I 
have an informal gethering at my place and I only know the names of some 
visitors, but nothing else. Clearly, I want to have these persons also as 
attendees to my event. However, RFC 2445 requires the value of the ATTENDEE 
property to be a cal-address, which is defined to be any valid URI (RFC 
1738). However, I don't have any uniquely identifying information, and simply 
using the name of the person is disallowed by the RFC...

So, what should a calendar application do in this case. Of course, you cannot 
send iTIP invitations, but for data im-/export with other calendaring 
applications (also with groupware servers!), this attendee information needs 
to be available.

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: Wed Mar 14 08:14:09 2007

Hi Reinhold,

--On March 14, 2007 4:25:41 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

> When an attendee (or an organizer) does not have an email adress (or any
> other  type of unique URI), what shall be the value of the ATTENDEE
> property? E.g. I  have an informal gethering at my place and I only know
> the names of some  visitors, but nothing else. Clearly, I want to have
> these persons also as  attendees to my event. However, RFC 2445 requires
> the value of the ATTENDEE  property to be a cal-address, which is defined
> to be any valid URI (RFC  1738). However, I don't have any uniquely
> identifying information, and simply  using the name of the person is
> disallowed by the RFC...
>
> So, what should a calendar application do in this case. Of course, you
> cannot  send iTIP invitations, but for data im-/export with other
> calendaring  applications (also with groupware servers!), this attendee
> information needs  to be available.

If you are not going to use iTIP at all, why not just use a bogus email 
address: e.g., "mailto:[email-masked]"? Or use the urn:uuid scheme 
and generate a uuid for each unique attendee.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Mar 14 08:45:02 2007

> and generate a uuid for each unique attendee.

Because we display that URI (in a clickable way) and let KDE's URL handler 
handle clicks on that URI (e.g. for sending a mail to that attendee or for 
showing the web page or for joining that IRC channel or jabber room). 
Inserting bogus data will (a) mess up that system as we need to filter out 
bogus data and (b) when importing that calendar in a different application, 
that application will treat the bogus data as real data...

Cheers,
Reinhold
- --

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Mar 14 08:49:48 2007

Hi Reinhold,

--On March 14, 2007 5:43:48 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

>> address: e.g., "mailto:[email-masked]"? Or use the urn:uuid
>> scheme and generate a uuid for each unique attendee.
>
> Because we display that URI (in a clickable way) and let KDE's URL
> handler  handle clicks on that URI (e.g. for sending a mail to that
> attendee or for  showing the web page or for joining that IRC channel or
> jabber room).  Inserting bogus data will (a) mess up that system as we
> need to filter out  bogus data and (b) when importing that calendar in a
> different application,  that application will treat the bogus data as
> real data...

Then use urn:uuid:... - your URL handler will likely not know what to do 
with it, so there should not be any unexpected actions resulting from a 
click on the URI.

-- 
Cyrus Daboo