Broker.processMessageRequest blindly trusts the iTip message

[ddolcimascolo]

Hi again,

When the iTip broker processes a REQUEST message, it blindly overwites all VEVENT components from the original event (if present). This is wrong as per the iTip spec for occurrences because the organizer might send an update for a single exception only, and the iTip does not contain the master VEVENT in this case.

I'm opening a PR to support both cases, let me know what you think, then I can write a complete test suite to validate the change.

Regards,

[evert]

Hi @ddolcimascolo ,

Could you point me to the relevant standards that support this? I thought that REQUEST is really always a replacement. For instance, if I receive a second REQUEST that only has 1 occurence, I would assume that I'm un-invited to all other instances except that one.

I might be wrong though, but I had some trouble finding the answer in RFC5546

[ddolcimascolo]

Hi @evert,

There's a nice example in https://tools.ietf.org/html/rfc5546#section-4.4.2
Also in constraints table in https://tools.ietf.org/html/rfc5546#section-3.2.2 you can see mentions of the use of RECURRENCE-ID to identify occurrences versus series.

Regards,
David

[evert]

Hi @ddolcimascolo ,

Great examples. Sorry for not finding them, always a bit hard to get into it when you've been out of it for a little bit =)

[evert]

But yea based on this, this sounds like a great idea. Having some of those unittests would be great to validate your changes =)