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
[calconnect25]
:
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
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-28 02:29 PDT by Stefan Winter
Modified: 2016-09-22 04:42 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Stefan Winter 2010-10-28 02:29:08 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) 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:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

Hi,

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:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
UID:fe3bf991-f74a-4d41-889e-6f1cf876c4ae
DTSTART;VALUE=DATE:20100826
DTEND;VALUE=DATE:20100827
ATTENDEE;CN=Foo Bar;EMAIL=foo.bar@restena.lu;PARTSTAT=NEEDS-
 ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1.2:urn:uuid:A8A9F56
 E-D16C-460B-870B-57902521FCDC
CREATED:20100826T075658Z
DTSTAMP:20100830T120459Z
LAST-MODIFIED:20100830T120459Z
ORGANIZER;CN=Collectif;EMAIL=planning@restena.lu;PARTSTAT=ACCEPTED;ROLE=CH
 AIR;RSVP=TRUE:urn:uuid:3C51A29D-E627-44D2-9D7D-6B15D0A0E3A8
SEQUENCE:1
SUMMARY:CT: Congé (récup. 15/08/2010)
TRANSP:TRANSPARENT
X-MOZ-GENERATION:1
END:VEVENT
END:VCALENDAR

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:

http://lists.apple.com/archives/ical-server/2010/Jun/msg00011.html

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.
http://tools.ietf.org/html/rfc5545
http://tools.ietf.org/html/rfc4791

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 3.8.4.1 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
      notation:

       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.

Greetings,

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:
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;CN=Felix Möller;EMAIL=mail@f
 elixmoeller.de:urn:uuid:272c501f-366c-517d-8af3-44c37777ef83

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.
Comment 8 aostrovsky 2016-09-21 23:54:59 PDT
Having same issue :(
Comment 9 Decathlon 2016-09-22 00:45:13 PDT
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.
Comment 10 aostrovsky 2016-09-22 02:10:54 PDT
Configured.

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 Decathlon 2016-09-22 04:42:50 PDT
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.

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