RFC-7986 - URL property

[cociweb]

Hello,

We are activelly use this library for Home Assistant. There is a feature request which is originally comes from atomic-calendar-revive module to implement the RFC-7986/ - URL property. This property is used by owncloud/nexcloud, and many popular icalendar providers as well.

Can you please investigate how can be a part one of the next versions of the library?

Thank's in advance.

[tobixen]

What is the use case? Could you explain a bit better?

I also think the RFC is a bit unclear. It says the URL to the calendar event can be saved in the calendar event itself, ok, but what kind of calendar URL? Should it be the URL to the ics, or an URL to some user-facing web site showing the event in a pretty human-readable format? Should it be a publicly available URL or a private URL (for those that are logged into the caldav server)?

Assuming it's the caldav URL - the canonical URL used by the caldav client for fetching and saving the event - I can see some options:

1) When creating (or saving) an event (or todo or journal), we could automatically add the URL of the newly created event (or todo/journal) into the ics itself.

2) When extracting an event from the calendar, we could automatically add the URL to the ics fetched.

3) We can add a new method allowing the URL to be added to an event

4) It can be done outside the library

1 feels wrong ... I'm concerned this may come as a quite unexpected side effect. If it was a universal wish to have the URL saved in the ics, then the right place to do that would be the calendar server, not the client library. If it's made "opt-in", I can support it ... maybe through some setting at the calendar level. It would take a bit of work, but it's relatively trivial.

2 is wrong for the same reason as 1. If loading an object and then saving it right afterwards, nothing should be changed.

So we're left with option 3 and option 4. Option 3 is trivial, it's like five minutes work (plus some hours to write tests and get the tests to pass). I can make a quick PoC if you're interested. However, I'm in the middle of working on support for RFC6638, there won't be any new official release until I'm done with that.

If you need it immediately, then it can be done through 4, I may try to write some example code if you're interested.

[cociweb]

Hello Tobixen,

Thank you for your alternatives. The url property is attached to each event. such as a location or description or etc. property. Let me show an example of it from here:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//XXXX.org//NONSGML v1.0//EN   
BEGIN:VEVENT
UID:20210102_07_100@XXXX.org
DTSTAMP:20210102T135033Z
DTSTART:20210102T135033Z
SUMMARY:The Earth at perihelion
DESCRIPTION:The Earth reaches its closest point to the Sun.
URL:https://XXXX.org/news.php?id=20210102_07_100
END:VEVENT

If I understand it right, it is the option 3. BUT! Let me add, an additional note what I've found on the net: If I'm right, there is an older rfc which use intended to be used the URI property with the almost the same way (RFC5545). - May, it could cause incompatibility issues. Is it right?

I think it is not as urgent to throw everything away. :) may it could be after the upcomming version or later. (I'm not a python programmer, just an enduser who would like to use it in the HA environment. HA based on python an it use this library as well. May it can be done outside the library -option 4-. I feel that it could be much more easier in the HA language if it is implemented in the base library which is already used by HA.)

[tobixen]

The RFCs are very unclear, but from your example from in-the-sky.org, the URL is not a caldav URL, nor an URL pointing to some icalendar data, it's an URL that humans can follow to learn more about the event.

If using the python caldav library for saving that calendar data from in-the-sky.org on a caldav server, the URL field will be saved on the server. If you take out the calendar data from the caldav server, using the python caldav library, the URL field will be included. The URL-field is irrelevant for the caldav library (and quite irrelevant for the caldav server as well).

It's like when sending a suitcase on an airplane. Explosives and contrabands may need special handling. A bottle of wine may need special handling by the person packing it, but not by the airline company. A shirt, some underwear, socks, a sweater, a bottle of wine and a chocolate does not need any special handling. Similarly, the caldav library only cares for the UID-property of the icalendar data (if it's given), the rest of the icalendar data needs no special handling. The caldav server needs to do some special handling of fields like DTSTART and RRULE i.e. to make it possible to search for calendar events, but properties like the URL-field needs no special handling - it should just be stored.

If you have problems with the URL-field not working, then the problem may be a the server side, it may be in some other python library, or there may be some misunderstanding somewhere ... but in general, it should just work. It's the client, the software using the caldav library, that needs to support the URL.

As for RFC5545 vs RFC7986, it's quite unclear for me too what the difference is - it is quite subtle. The purpose of the change in RFC7986 is to "allow it to be defined in an iCalendar object". I don't get it, RFC5545 already specifies exactly that.

RFC5545 says that the purpose is to define a Uniform Resource Locator (URL) associated with the iCalendar object. RFC7986 changes this to convey a location where a more dynamic rendition of the calendar information can be found. I find the purpose better described in RFC5545, I think the phrasing "a more dynamic rendition of the calendar information" is both obscure and ambiguous.

RFC5545 says that the property can be specified once in an "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY". RFC7986 changes this so the property can be specified once in an iCalendar object. It's unclear to me if this represents a change at all.

The reason why I've become the maintainer of the python caldav library was not because I like those standards - it's rather the exact opposite, I needed well-working libraries to avoid having to deal with those standards. I found some issues and missing features in the library as it was back then ... and while fixing it someone threw me the maintainer-hat :-)

[cociweb]

Well, Thank you for the clarification and for your time. In this case, let's choose the option 4 :) and let me investigate the possibility from the other side (from HA point of view). If you interested, later on, I can post here some updates about it. In the mean time, let me raise my hat too. :-)

• If you agree, I will close this ticket.