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:
|
relatedTo.parameters.add(when (row.getAsInteger(Relation.RELATED_TYPE)) { |
|
Relation.RELTYPE_CHILD -> |
|
RelType.CHILD |
|
Relation.RELTYPE_SIBLING -> |
|
RelType.SIBLING |
|
else /* Relation.RELTYPE_PARENT, default value */ -> |
|
RelType.PARENT |
|
}) |
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 tasks/tasks#2527
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:
ical4android/lib/src/main/kotlin/at/bitfire/ical4android/AndroidTask.kt
Lines 294 to 301 in 76e30b7
The interpretation of unknown RELTYPE’s happens in compliance to 3.2.15, RFC 5545:
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 tasks/tasks#2527