Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Level 1

0 points

PARTSTAT=ACCEPTED:urn:uuid: or PARTSTAT=ACCEPTED:mailto:

I'm testing iCal Server so I'm currently the only one in our organization on iCal Server.

*The problem:*
When I reply to an event invitation, an email with an .ics with my reply is sent with my local Mail.app. But it is not accepted by the inviters local iCal. Note: iCal local is version 4.0.4 (1395) on both inviter and invitee user account.

I've looked for diffences between what local iCal sent before switching to iCal server. Here's what I found in the .ics that's sent:

iCal local used to send: PARTSTAT=ACCEPTED:mailto:my@email.com
iCal on server sends: PARTSTAT=ACCEPTED:urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB4838
(And around 30 lines before/after that)

If I manually edit the .ics and
change the :urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB4838 part
to :mailto:my@email.com
save a new .ics and send that to the invitee, the status is correctly updated in his local iCal.

It looks like the ivitees local iCal does not recognize me as an invitee and thus does not update the reply status from my@email.com.

If I reply to an invitation from Mozillas Lightning calendar, the inviters Lightning calendar updates like this:
1. my@email.com has not yet replied
2. urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB4838 has replies
+(although this user was not invited)+

Question:
1. Is there a way to get my iCal to send a reply which is understood by local iCal (and preferably also other calendar clients such as Outlook, Lightning and Sunbird?)
2. Can I manually change the template local iCal uses to generate the reply .ics file?

Mac Pro, Mac OS X (10.6.6), OS X Snow Leopard Server 10.6.6

Posted on Feb 5, 2011 3:42 AM

8 replies

SkyHook17

Level 1

105 points

Feb 5, 2011 1:37 PM in response to ryanowich

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.

ryanowich Author

Level 1

0 points

Feb 14, 2011 4:38 PM in response to SkyHook17

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:
ATTENDEE;CN="Myfirstname Mylastname";
CUTYPE=INDIVIDUAL;EMAIL="myemail@mycompany.dk";
PARTSTAT=ACCEPTED;
ROLE=REQ-PARTICIPANT:urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB4838

I would love to dig deeper into the ways you are suggesting to look, but I just don't know where to dig.

ryanowich Author

Level 1

0 points

May 7, 2012 5:13 AM in response to ryanowich

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:

ATTENDEE;CN="Ryan Grønborg";CUTYPE=INDIVIDUAL;EMAIL="ryan@tv-glad.org";PARTSTAT=ACCEPTED:urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB3858

If I manually replace the

urn:uuid:38BCCE7F-D85C-4C17-872E-5C3CFFFB3858

part with

mailto:ryan@tv-glad.org

and send that to the person at the other end, everything is working.

The corrected line then looks like this:

ATTENDEE;CN="Ryan Grønborg";CUTYPE=INDIVIDUAL;EMAIL="ryan@tv-glad.org";PARTSTAT=ACCEPTED:mailto:ryan@tv-glad.org

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.

SkyHook17

Level 1

105 points

Sep 22, 2012 1:03 PM in response to ryanowich

Forgive my ignorance. Is this link you? It might be that nobody else has figured it out either. I think I saw a link to this discussion in there too.

Sep 23, 2012 6:16 AM in response to ryanowich

Hi,

I suggest you are going to get more information if you join the CalendarServer-users mailing list and ask there. See also the Mac OS Forge Calendar and Contacts Server website.

Best wishes

John M

ryanowich Author

Level 1

0 points

Sep 26, 2012 3:59 AM in response to John Maisey

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.

Current status:

I still havent't fixed it, I haven't found anyone with the same problem who's fixed it. And I've given up.

As Apple is moving away from enterprise server solutions both hardware and system wise, we we are now looking at externally hosted Kerio Connect and Microsoft Office 365 solutions.

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.

Apr 14, 2014 12:51 PM in response to ryanowich

Hi ryanowich,

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.

Best regards,

Matteo, Frankfurt, Germany

Aug 20, 2015 2:40 PM in response to ryanowich

Hi there,

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 ;-).

Cheers,

Matteo

PARTSTAT=ACCEPTED:urn:uuid: or PARTSTAT=ACCEPTED:mailto: