Because you've witnessed rejection from other calendars, I'd look into server addresses related to your test setup, perhaps an alias to that address or router addresses/ports through a firewall.
I see the uuid as a code that includes identifiers to an object that includes the addresses. By changing the ID to a mailbox, you've bypassed the part that identfies the unique server (along with all the stuff that identifies the invitation) and DNS took over as if it was a regular email.
I don't know more detail, but it smells like your test server might not be utilizing domain routing properly or be shut down by address or port. Imagine a message can go out but it can't come back in, not that the uuid is bad because I don't think it got far enough to judge it, getting dumped somwhere further up the protocol.
You could be right. But I don't see how external invitees would be able to tap into our server and translate the urn:uuid to an email. Or how that would be secure. Never mind security at this point though.
To clarify: My email is included in the reply iCal sends via Mail.app. It's just not in a format understood by the recipient.
The format looks like this:
I would love to dig deeper into the ways you are suggesting to look, but I just don't know where to dig.
I posted this more than a year ago. After battling the problem I eventually gave up. As we are getting more and more handheld devices i our company, a centralized iCal Server is needed even more now than before. I hope someone has found a solution to this problem?
My problem persists:
Everything looks like it's working. iCal Server is updating iCal local fine. All incomming replies are working. When I reply to an invitation, iCal Server updates fine and an .ics file is generates and put into my local Mail. The .ics. file contains my answer to the invitation, is has my name, my email and my urn:uuid. And the mail is sent and received by who ever invited me.
But: The one who invited me also uses iCal. He gets my reply-ics and it's read by his iCal local. But the inviters iCal cannot read the .ics file correctly.
It's as if the .ics is not correctly formatted:
If I manually replace the
mailto:firstname.lastname@example.org send that to the person at the other end, everything is working.
The corrected line then looks like this:
As my email is in the .ics file, I can't see that it could be a lookup problem. Nor a DNS problem. Everything is sent and received in both ends.
Note: I've tested with iCal 4.0.4 and Mozillas Lightning calendar. Neither of them work. Both experience the exact same scenario and problem.
Hi John and SkyHook17
No this is not me here: bugzilla.mozilla.org/show_bug.cgi?id=607906. But thanks for the links.
I've found questions and answers related to my urn:uuid vs. email problem on trac.calendarserver.org. And I've tried modifying python files as described in some of the posts. But it led to new problems and I quickly reverted to a backup.
One post said that the problem had been fixed by an update from CalendarServer-1.3 to CalendarServer-2.0. But as far as I understand, the iCal Server version on Mac OS Forge is different than the build in iCal Server on OS X 10.6 Server.
I don't know how I can implement updates from the Open Source version or if it's even possible without breaking something in OS X Server.
I still havent't fixed it, I haven't found anyone with the same problem who's fixed it. And I've given up.
Maybe I'm lucky I never managed to fix iCal Server. I've heard that it's nowhere as stable as e.g. Kerio and I could be facing a new migration to Kerio after running in to problems with a working iCal Server.
I do have the same problem. It took me several days just to find out that "it" just does not work. I just can't understand how an external System is supposed to recognize the urn:uuid. In fact even Darwin CalendarServer is not able to do so. I have setup two CalendarServers that were supposed to interact via iMIP, but the reply of an invitee will not be correctly processed by the inviting party, simply becaus it fails understand urn:uuid! No surprise. I was only using Apple Software (Calendar.app on Mavericks and several versions of the CalendarServer) expecting them to interoperate just fine, but no! I haven't yet understood if it's the Server or the Client, that is responsible for replacing/choosing urn:uuid instead of mailto:, maybe both of them. I might be wrong but when I tried iCal.app on Snow-Leopard and Calendar on iOS7.1 I noticed that they did not send the urn:uuid.... and the Status of the invitee was interpreted correctly by the inviting party. That makes me think, that it is also a client issue. I'm quite frustrated by now. I'll take a look at the source code, but I'm just about to give up now. I'll let you know if I find out something new.
Matteo, Frankfurt, Germany
I had been investigating this a long time ago and now have looked into it again. Last time I checked the interoperability between AppleCalendarServers<->AppleCalendarServer and AppleCalendarServer<->Gmail, I found that SnowLeopards CalendarServer and even https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/rel ease/CalendarServer-5.2/ ( I do not know what OSX version this coressponds, but it must be way after 10.6) have this "bad" behaviour. I had setup two systems talking with each other via imip-emails and accepting invitations was not possible between both - because the ATTENDEEs had urn:uuid that only one system could recognize but not both. I had messed with the python-code and had some success but that was not satisfactory. Now I've tried it again with CalendarServer-5.3 and it does work pretty nicely now ; also talking with gmail-calendar. I might be wrong, but I'm quite convinced that something has changed to the better (to my surprise ;-).