handle cancellation message with more than one attendee #53046
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1. make it possible to process imip cancellation messages with more than one attendee 2. create a specialized version of the original event containing only the relevant data to cancel the actual copy of the event for the given attendee Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
kesselb
force-pushed
the
bug/noid/handle-n-attendees-in-imip-cancel
branch
from
84b1202 to
b86d600
Compare
kesselb
added
bug
2. developing
kesselb
changed the title
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
Contributor
Author
|
Withdrawing in favor of #52622 |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
handleIMipCancel assumes that there is only one attendee, but calendarData is the original event and may contain a list of attendees. Instead of forwarding the original event, a new cancel reply is now generated for the recipient.
RFC: https://www.rfc-editor.org/rfc/rfc2446#section-3.2.5
The approach is to create a cancellation message from a cancellation message. I therefore assume that requirements, such as incrementing the sequence, were handled by the sending party.
One thing that is unclear to me after reading the RFC is whether we need to include DTSTART and DTEND. I assume that for canceling only a recurrence, it should be enough to include the RECURRENCE-ID, but I would appreciate your feedback on how you interpret the RFC.
I left a note in the code after discussing the issue with Sebastian to double-check if it's a problem that we do not handle multiple attendees in CalendarImpl.handleIMipMessage as well. Yes, it seems wrong to assume that there is only one attendee, and we should consider adjusting the implementation. However, I tend to ignore that for now because a new cancellation message is created with only one attendee, and thus it's not a problem anymore in this code path. Looking at the code in CalendarImpl.handleIMipMessage, I'm also not sure if we are even able to handle multiple attendees properly because we no longer know who the actual recipient of the message was.
TODO
Checklist