Skip navigation

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

2984 Views 7 Replies Latest reply: Apr 14, 2014 12:51 PM by Matteo Ceruti RSS
ryanowich Calculating status...
Currently Being Moderated
Feb 5, 2011 3:42 AM
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
  • SkyHook17 Level 1 Level 1 (90 points)
    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.
  • SkyHook17 Level 1 Level 1 (90 points)

    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. 

  • John Maisey Level 5 Level 5 (6,870 points)

    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

  • Matteo Ceruti Calculating status...

    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

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.