4 ms·

>Currently CalDAV and CardDAV agents expect servers to be able to store custom properties, and retrieve those again. This is relevant for sync clients such as y

>Currently CalDAV and CardDAV agents expect servers to be able to store custom properties, and retrieve those again. This is relevant for sync clients such as yours, but it becomes even more important for scheduling systems. What's wrong with storing a file inside the calendar folder? Why do clients need to do this? Even in CalDAV/CardDAV's case: Flock had massive compat issues because no server actually supported this. So I guess it's not actually necessary? I'm not knowledgeable enough to respond to the rest of your points. Perhaps somebody from FastMail could respond to them. But I wonder if we should simply ignore some of those feature requests to make a simple protocol for the majority of us possible.

treve 11y ago
> What's wrong with storing a file inside the calendar folder? Why do clients need to do this? I'm talking about iCalendar properties, parameters and components, NOT webdav properties. The distinction is important. > Even in CalDAV/CardDAV's case: Flock had massive compat issues because no server actually supported this. So I guess it's not actually necessary? Flock used custom 'dumb' WebDAV properties, this is not widely supported, and actually wasn't supported by sabre/dav until 3.0. Flock was the first client that required it. Not true for iCalendar properties. CalDAV and CardDAV servers really should support it. Servers such as fastmail and google calendardon't do this well and they'll usually silently discard user-supplied data. Fastmail is part of interop the problem that we have today. They've only done this for a bit over a year, so it's not entirely surprising that their conclusion is a simpler data-model. I think most people tend to take that path before they realize the shortcomings. Jmap and fastmail is bad for interop, and letting Fastmail pick their favourite subset of caldav and carddav and attempt to make that the standard is not really a solution, and will also probably never fly.
- untitaker_ 11y ago
  >I'm talking about iCalendar properties, parameters and components, NOT webdav properties. The distinction is important. It wasn't clear at all what you meant. It has caused quite a bit of trouble for CardDAV interopability, since particularly Apple has defined proprietary extensions for crucial features like groups. This lead to other clients adopting the proprietary extension, only for it to be invalidated at the next wiggle of the worm. On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions. Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user. EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item.
  - treve 11y ago
    > It has caused quite a bit of trouble for CardDAV interopability, since particularly Apple has defined proprietary extensions for crucial features like groups. This lead to other clients adopting the proprietary extension, only for it to be invalidated at the next wiggle of the worm. The problem here is actually the lack of vCard 4 adoption, but I agree that it's an issue. Apple (and others) have effectively extended vCard 3 to adopt vCard 4 features. > On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions. I also thought it was completely wrong. An extremely minor thing compared to all the things that _have_ been standardized or are currently. But there's a lot of work still to be done. Also a lot of work has been done. Work which is discarded by JMap. > Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user. I could grant that could be an issue, but creating a standard that simply does not support any of these features out of the box is not really a solution either. In the end, people will want to implement certain features on top of these servers because the standards don't cover the range of features of non-standard alternatives such as Lotus Notes and MS Exchange. But I want to iterate that I agree that DAV, iCalendar and vCard each have issues, but however you look at it, JMap is a massive step backwards because it discards and ignores many years of actual standardization and development. > EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item. HTTP works because browsers, other clients, servers and proxies don't need to be aware of every detail of the protocol. They need to understand the overall structure and certain baserules, but if it were restricted what the response body had to look like, or which headers are legal, it would have stumped innovation. HTML, CSS, Atom, you name them and they have a well defined-extension system and I think it's contributed to their success. The iTip protocol needs to work like a carrier and not care about all it's contents. If in the future iSchedule lands, and we get multiple caldav servers talking together and do scheduling together, you'll want individual iSchedule nodes to ignore extensions, so that servers and clients can innovate and extend without having to alter the underlying protocol. Have those optional extensions been that bad? I would say that they've only been bad when people have badly implemented the core protocol. To extend the CSS analogy, it would be as if Fastmail created something similar to SASS or Less, but instead of having a 1:1 mapping, new syntax is created for every property. Well, most of them... because many CSS properties are not supported. Also, any future CSS extension would need to get explicitly added to this new stylesheet format.

treve 11y ago

> What's wrong with storing a file inside the calendar folder? Why do clients need to do this? I'm talking about iCalendar properties, parameters and components, NOT webdav properties. The distinction is important. > Even in CalDAV/CardDAV's case: Flock had massive compat issues because no server actually supported this. So I guess it's not actually necessary? Flock used custom 'dumb' WebDAV properties, this is not widely supported, and actually wasn't supported by sabre/dav until 3.0. Flock was the first client that required it. Not true for iCalendar properties. CalDAV and CardDAV servers really should support it. Servers such as fastmail and google calendardon't do this well and they'll usually silently discard user-supplied data. Fastmail is part of interop the problem that we have today. They've only done this for a bit over a year, so it's not entirely surprising that their conclusion is a simpler data-model. I think most people tend to take that path before they realize the shortcomings. Jmap and fastmail is bad for interop, and letting Fastmail pick their favourite subset of caldav and carddav and attempt to make that the standard is not really a solution, and will also probably never fly.

untitaker_ 11y ago
>I'm talking about iCalendar properties, parameters and components, NOT webdav properties. The distinction is important. It wasn't clear at all what you meant. It has caused quite a bit of trouble for CardDAV interopability, since particularly Apple has defined proprietary extensions for crucial features like groups. This lead to other clients adopting the proprietary extension, only for it to be invalidated at the next wiggle of the worm. On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions. Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user. EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item.
- treve 11y ago
  > It has caused quite a bit of trouble for CardDAV interopability, since particularly Apple has defined proprietary extensions for crucial features like groups. This lead to other clients adopting the proprietary extension, only for it to be invalidated at the next wiggle of the worm. The problem here is actually the lack of vCard 4 adoption, but I agree that it's an issue. Apple (and others) have effectively extended vCard 3 to adopt vCard 4 features. > On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions. I also thought it was completely wrong. An extremely minor thing compared to all the things that _have_ been standardized or are currently. But there's a lot of work still to be done. Also a lot of work has been done. Work which is discarded by JMap. > Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user. I could grant that could be an issue, but creating a standard that simply does not support any of these features out of the box is not really a solution either. In the end, people will want to implement certain features on top of these servers because the standards don't cover the range of features of non-standard alternatives such as Lotus Notes and MS Exchange. But I want to iterate that I agree that DAV, iCalendar and vCard each have issues, but however you look at it, JMap is a massive step backwards because it discards and ignores many years of actual standardization and development. > EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item. HTTP works because browsers, other clients, servers and proxies don't need to be aware of every detail of the protocol. They need to understand the overall structure and certain baserules, but if it were restricted what the response body had to look like, or which headers are legal, it would have stumped innovation. HTML, CSS, Atom, you name them and they have a well defined-extension system and I think it's contributed to their success. The iTip protocol needs to work like a carrier and not care about all it's contents. If in the future iSchedule lands, and we get multiple caldav servers talking together and do scheduling together, you'll want individual iSchedule nodes to ignore extensions, so that servers and clients can innovate and extend without having to alter the underlying protocol. Have those optional extensions been that bad? I would say that they've only been bad when people have badly implemented the core protocol. To extend the CSS analogy, it would be as if Fastmail created something similar to SASS or Less, but instead of having a 1:1 mapping, new syntax is created for every property. Well, most of them... because many CSS properties are not supported. Also, any future CSS extension would need to get explicitly added to this new stylesheet format.