3. Partecipant status is NEEDS-ACTION but partecipation was confirmed

Partecipant status is NEEDS-ACTION but partecipation was confirmed


  • Android device: Xiaomi Redmi Note 4 - Android 7.0
    DAVx5: version 2.2.3.1-ose-267
    Other CalDAV client: Thunderbird 60.5.0 on Win10 x64
    CalDAV server: SOGO 4.0.4.20190212

    Bug description:

    • received an invite to an event (not accepted yet)
    • in Google calendar the event is drawn as an “unfilled” rectangle with calendar-color border
    • accepted the event
    • in Google calendar the event is now drawn as a rectangle filled with calendar-color
    • after a resync the event rectangle got back to unfilled, like it was never accepted
    • in Thunderbird/Lightning I was marked as accepted
    • in SOGo Calendar web page I was also marked as accepted
    • confirming again my partecipation in Google Calendar started the same loop again: rectangle filled, resync, rectangle unfilled

    So it seems that the only client markink me as unconfirmed was Android/DAVx5.

    After some investigation I noticed that event organizer added my email with “unusual case”, say Myself@example.org
    instead of myself@example.org (note the initial Uppercase).

    I manually changed that ics record in SOGo database, then forced a DAVx5 resync and… the bug disappeared and I was marked as ACCEPTED!
    As a counter-proof, I set the ics record content back to “uppercased” version, reforced sync and the event got back to NEEDS-ACTION.
    In both cases Thunderbird/Lightning and SOGo web application correctly shown me as ACCEPTED.

    Below is the untouched ICS content that causes the bug (changed emails for privacy reasons, I’m the first attendee…):

    BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Rome
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20190213T175219Z
DTSTAMP:20190213T175219Z
UID:f6ce8b28-bd8d-4557-b8cb-a74a47bacc4a
SUMMARY:Summary
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=0;RECEIVE
 D-DTSTAMP=20190213T152257Z;CUTYPE=INDIVIDUAL:mailto:Myself@example.org
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE
 =0;RECEIVED-DTSTAMP=20190213T160158Z;CUTYPE=INDIVIDUAL:mailto:user1@exampl
 e.org
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE
 =0;RECEIVED-DTSTAMP=20190213T162824Z;CUTYPE=INDIVIDUAL:mailto:user2@exampl
 e.org
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE
 =0;RECEIVED-DTSTAMP=20190213T163556Z;CUTYPE=INDIVIDUAL:mailto:user3@exampl
 e.org
DTSTART;TZID=Europe/Rome:20190218T140000
DTEND;TZID=Europe/Rome:20190218T173000
CLASS:PUBLIC
X-MOZ-GENERATION:5
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT240M
DESCRIPTION:Description
END:VALARM
ORGANIZER;CN=Organizer User:mailto:organizer@example.org
END:VEVENT
END:VCALENDAR```
    0
  • R
    developer

    Hello,

    Thanks for your report. DAVx⁵ just inserts the attendees into the Android calendar provider, which is responsible for determining the “self status” (= status of the account owner when the same email address is an attendee).

    Seems like Android compares the email address with case sensitivity.

    Do you know how the rules are for comparing attendee/organizer emails? Do mailto: URIs have to be normalized in some way? According to https://tools.ietf.org/html/rfc5321#section-2.4:

    The local-part of a mailbox MUST BE treated as case sensitive. [… ] In particular, for some hosts, the user
    “smith” is different from the user “Smith”.

    This would mean that Myself@example.org can be another email address than myself@example.org, and then it would get complicated…

    Maybe it would be a solution that the server always rewrites attendees to a canonical version? So that if Myself@example.org is invited, but the server account is myself@example.org, the server rewrites the ATTENDEE to myself@example.org?

    But this is only the local part. The domain part of the email address could always be normalized. Because Android doesn’t do that, DAVx⁵ could rewrite it to lower case, as a workaround. But it would probably cause bug reports too (“bug: domain part of attendee mailtos always rewritten to lowercase”)…

    0

  • I don’t have any knowledge about .ics format (thanks for linking the RFC), but in the ICS I’ve posted I see that Myself@example.org line has the PARTSTAT=ACCEPTEDproperty like the others; isn’t it enough for the partecipant to be marked as ACCEPTED?

    Well, I wonder if this issue should be better resolved at server or client side.
    Since Thunderbird and SOGo web page both don’t care about casing, I’ve supposed Android should behave the same… but it’s not.

    Maybe an advanced option like “normalize email addresses” could be added in account configuration?
    Maybe together with a warning like “use only if you have issues with users adding mixed-case email addresses” 😉

    PS: will post an issue notice to SOGo bug tracker too, linking to this. If server side we could have a feature that will normalize all of the email addresses, we’re done.

    0
    R
     1 Reply
  • R
    developer

    @nicorac said in Partecipant status is NEEDS-ACTION but partecipation was confirmed:

    I don’t have any knowledge about .ics format (thanks for linking the RFC), but in the ICS I’ve posted I see that Myself@example.org line has the PARTSTAT=ACCEPTEDproperty like the others; isn’t it enough for the partecipant to be marked as ACCEPTED?

    As far as I see, the problem is that Myself@example.org is not identified with yourself, isn’t it? When you look in the event after accepting the invitation, is Myself@example.org set to “confirmed”?

    0

  • As far as I see, the problem is that Myself@example.org is not identified with yourself, isn’t it?

    Yes it is, no doubts.
    I was only justifying myself about how I’ve missed the casing issue at first sight 😉

    Maybe an advanced option like “normalize email addresses” could be added in account configuration?
    Maybe together with a warning like “use only if you have issues with users adding mixed-case email addresses” 😉

    Is this acceptable or do you think it’s a “too geeky” workaround?

    0
need info 1
Log in to reply