Last Comment Bug 607906 - iCal Server invitations use urn:uuid as invitee identifier; Lightning can't match with email address
: iCal Server invitations use urn:uuid as invitee identifier; Lightning can't m...
Status: NEW
Product: Calendar
Classification: Client Software
Component: Provider: CalDAV (show other bugs)
: unspecified
: All All
: -- enhancement with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2010-10-28 02:29 PDT by Stefan Winter
Modified: 2013-09-22 20:16 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description Stefan Winter 2010-10-28 02:29:08 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100914 SUSE/3.6.10-30.2 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2


we are using Lightning plugin with Mac OS X 10.6 iCal Server. There are only a few things that don't work as expected. One of them is invitations.

When entering a new event with invitees from any CalDAV Client, we use email addresses. That is Attendee: "". iCal Server then processes the new event, and replaces internal email addresses with their urn:uuid as a means of identifying the user.

When viewing that same event in Lightning, it is not possible for that user to accept an invite to the event, since Thunderbird's email address identity is, while the event is linked to "Stefan Winter <urn:uuid:something>".

The good news is: the email address is still in the corresponding event. Downloading the file from iCal Server shows that there is an EMAIL= property in the invite (following example is one colleague of mine's event:

PRODID:-// Mozilla Calendar V1.1//EN
SUMMARY:CT: Congé (récup. 15/08/2010)

As you see, it would be possible for Lightning to parse the EMAIL= property, and try to match that with the user's configured mail address - and then invites could be processed properly.

Reproducible: Always

Steps to Reproduce:
1. have iCal Server 10.6 users with registered email addresses
2. invite user to event with his mail address
3. display event in user's Lightning
4. user doesn't get invite notification! Check properties of event: the user is listed with his URN.
Comment 1 Stefan Winter 2010-11-19 07:05:17 PST
Other people are apparently fighting with this themselves, see this thread:

Any chance of this being implemented before 1.0?
Comment 2 Bas van den Bosch 2010-11-19 11:36:17 PST
I guess something is going wrong here, RFC5545 doesn't allow adding urn: to a line. Also, rfc 4791 doesn't specify this. The urn:uuid should be handled by the server and shouldn't be present in the ics. So the answer link you posted is wrong.

only question is: is this an error in lightning or in Darwin?
Comment 3 Stefan Winter 2010-11-19 12:32:54 PST
Just took a look into 5545. I'm not quite sure it's not allowed (but please bear with me, this is not my typical OSI layer of RFCs).

- The line in question is inside an ATTENDEE.
- The ATTENDEE BNF production in is:

       attendee   = "ATTENDEE" attparam ":" cal-address CRLF

- CAL-ADDRESS is defined in 3.3.3 as being a URI, quoting:

"3.3.3.  Calendar User Address

   Value Name:  CAL-ADDRESS

   Purpose:  This value type is used to identify properties that contain
      a calendar user address.

   Format Definition:  This value type is defined by the following

       cal-address        = uri

   Description:  The value is a URI as defined by [RFC3986] or any other
      IANA-registered form for a URI.  When used to address an Internet
      email transport address for a calendar user, the value MUST be a
      mailto URI, as defined by [RFC2368].  No additional content value
      encoding (i.e., BACKSLASH character encoding, see Section 3.3.11)
      is defined for this value type."

Note the "*when* used to address an Internet email ..." -> then have to use mailto.

- In iCal Server's case, the server does not want to express an internet email transport address. It wants to express the user's URN in its directory, and is thus not bound to use mailto: . Since a URN is a type of URI (I think; I constantly get these UR* hierarchies wrong) the server is then free to use its URN. It's nice enough to include the EMAIL parameter in the "attparam" production though, and Lightning could make use of that.

So I don't think we can blame the server side here. IMHO, Lightning should just not expect that it always gets the email address within CAL-ADDRESS.


Stefan Winter
Comment 4 Felix Möller 2011-02-05 16:43:34 PST
I just wanted to report the same issue. 

The relevant line of my ics is:

I am running current SVN trunk of the Calendar Server 3.0 i.e. r6885.
Comment 5 Stefan Winter 2011-07-04 23:35:08 PDT
I upgraded to 1.0b4 a couple of days ago; the matching between emails and URNs still isn't there apparently.

Could we agree on whether it should or should not be supported at least? Please read my comment #3 - it looks to me like using a URN is possible as per the standard; so Lightning should be prepared to handle that.
Comment 6 TGOS 2012-03-02 06:06:27 PST
I can confirm this issue on OS X as well. Trying to work with iCal Server using Lightening is really a pain. It won't recognize events I'm invited to, thus I cannot confirm events either, it won't allow me to edit events at all as it "corrupts" the ORGANIZER line (see bug 723610), I cannot correctly add other users to events I'm scheduling and TODO events scheduled in my own remote calendars cannot be deleted or edited.
Comment 7 David Young 2013-09-22 20:16:39 PDT
I'd like to add to this. We have the same issue preventing non-Mac users from effectively using our calendar server with the rest of the organisation.

Note You need to log in before you can comment on or make changes to this bug.