iCal Server invitations use urn:uuid as invitee identifier; Lightning can't match with email address



Provider: CalDAV
7 years ago
10 months ago


(Reporter: Stefan Winter, Unassigned)



(Whiteboard: [calconnect25])



7 years ago
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: "stefan.winter@restena.lu". 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 stefan.winter@restena.lu, 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.org/NONSGML Mozilla Calendar V1.1//EN
ATTENDEE;CN=Foo Bar;EMAIL=foo.bar@restena.lu;PARTSTAT=NEEDS-
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

7 years ago
Other people are apparently fighting with this themselves, see this thread:


Any chance of this being implemented before 1.0?

Comment 2

7 years ago
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

7 years ago
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

7 years ago
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

6 years ago
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.


6 years ago
OS: Linux → All
Hardware: x86_64 → All

Comment 6

6 years ago
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.
Ever confirmed: true
Whiteboard: [calconnect25]

Comment 7

4 years ago
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.

Comment 8

10 months ago
Having same issue :(

Comment 9

10 months ago
aostrovsky,  could you try to change the preference "calendar.icaljs" to true (menu Tools > Options > Advanced > General > Config Editor) to see if something changes? It needs to restart Thunderbird to see the effect.
icaljs is still an experimental feature so there may be something else that doesn't work, just test your issue and then revert the preference to false.
Flags: needinfo?(aostrovsky)

Comment 10

10 months ago

Nothing changed.
User who received invite still not able to Accept. As that option does not appear at all.

Only works if I remove urn related things at all and add mailto: user's_mail.
Then TB recognize that as event for 'user's_mail' and allow me to Accept.

Comment 11

10 months ago
Sorry, I didn't read comment 2, it seems that iCalendar standard (rfc 5545) doesn't allow a parameter "urn:" used in that way (or it doesn't allow at all), hence icaljs library doesn't make difference compared to libical.
Flags: needinfo?(aostrovsky)
You need to log in before you can comment on or make changes to this bug.