User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) 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:188.8.131.52) 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: "email@example.com". 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 firstname.lastname@example.org, 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
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.
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.
Other people are apparently fighting with this themselves, see this thread:
Any chance of this being implemented before 1.0?
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?
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 184.108.40.206 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.
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.
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.
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.
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.