Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Zocker1999NET opened this issue Sep 24, 2023 · 2 comments
Open
Labels
dependent need info Needs more information

Comments

@Zocker1999NET
Copy link

Zocker1999NET commented Sep 24, 2023

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

@rfc2822
Copy link
Member

rfc2822 commented Sep 24, 2023

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

@rfc2822 rfc2822 added the need info Needs more information label Dec 3, 2023
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependent need info Needs more information
Projects
None yet
Development

No branches or pull requests

3 participants
@rfc2822 @Zocker1999NET and others