Disclaimer, I am not a member of this project, so anything I say is not representative for this project
@untitaker obviously knew what recursion meant, just not within the context of what you are asking. Instead of copy-pasting parts of the spec, how about trying to do a better job telling what’s wrong.
The problem with what you pasted is that it’s indeed a DRAFT and the parts mentioning recursion are not in the final specification.
However, even if this were the standard, this has little to do with the issue brought forward. The only paragraph mentioning recursion is this:
Reports on collections containing calendars* A WebDAV collection which contains one or more calendar collections is not a new type of resource, but it may support these new REPORT. If so, then the REPORT is expected to have the semantics of including information from all the calendar data contained in the collection, and its children, recursively.
Which clearly states this as a MAY, not a MUST or even a SHOULD.
But even if it said MUST, this paragraph only addresses certain
REPORT requests on calendar collection. The specification says nothing about how or why the client should take advantage of it.
Despite your usual incredibly condescending and poorly written bug report, I have two potential guesses as to what your actual issue might be. Perhaps this helps you communicate your root problem:
Some clients and servers support regular collections in the ‘calendar home’, which in turn may contain calendars themselves. There is some language in RFC 4791 that does seem to support this concept, but support for this is in general poor. I don’t think it’s unlikely that this will be dropped in future versions of this spec. It’s possible that you are trying to do this on the server, and it’s possible that DavDroid does not support this.
You put in a random url and expect the client to work. What’s unclear what type of resource the url is. I don’t think clients are expected to support just any resource containing calendar collections. Many clients do support providing arbitrary urls to principals. The big question is then, what kind of resource is
https://mail.example.com/caldav.php/PublicResource in your example?
Am I close?
In case anyone reads this and wonders why I would respond as strongly as I did, go read #497 to get another glimpse of @ddblack 's communication style.