bitfireAT / ical4android

Allows usage of iCalendar files with the Android calendar provider
GNU General Public License v3.0
18 stars 10 forks source link

Unknown reltype get changed (not only interpret as) parent (RFC 9253) #115

Open Zocker1999NET opened 11 months ago

Zocker1999NET commented 11 months ago

The issue tasks/tasks#2527 above is created by DAVx5, further possibly by this library. The assumption is at follows:

The following code transfers unknown iCalendar RELTYPE’s to PARENT: https://github.com/bitfireAT/ical4android/blob/76e30b7ebd9660d0cbd1849f50a5003ae498374c/lib/src/main/kotlin/at/bitfire/ical4android/AndroidTask.kt#L294-L301 The interpretation of unknown RELTYPE’s happens in compliance to 3.2.15, RFC 5545:

Applications MUST treat x-name and iana-token values they don't recognize the same way as they would the PARENT value.

However, this current implementation hinders depending apps from supporting further/custom RELTYPE’s and, more importantly, leads them to lose the original RELTYPE when saving iCal data back to a server. So users cannot connect e.g. DAVx5 to a server account, where new RELTYPE’s are already in use, without incurring data loss, making DAVx5 forward-incompatible. While RFC 5545 only emphasizes forward compatibility, RFC 9253 already defines new RELTYPE‘s, making this library & DAVx5 incompatible to RFC 9253.

IMO this library should allow its depending applications to interpret custom/unknown RELTYPE’s themselves. Then these apps can decide on their own how they want to handle unknown RELTYPE’s, making it possible to tolerate them. Falling back to the current behavior should only be possible with a warning attached that pushing the data back to a server can induce data loss to its users.


Depends on https://github.com/tasks/tasks/issues/2527

rfc2822 commented 11 months ago

How would you store the other RelTypes? Can you maybe prepare a PR?

github-actions[bot] commented 9 months ago

This PR/issue depends on: