6 ms·

I don't know. Compatibility with jCal and jCard would've been nice, yes, but I don't think the kind of properties they support in their datamodel differ too muc

I don't know. Compatibility with jCal and jCard would've been nice, yes, but I don't think the kind of properties they support in their datamodel differ too much from what the VCard and iCalendar support. They also have a proxy server that proxies client => JMAP => DAV, so if that works without a massive translation layer, it'll probably be fine. EDIT: Just saw that you edited your post to address those points. In that case I'd like to see a list of things that are required from a -DAV successor. JMAP's syntax strikes me as quirky, I agree, but the datamodel and the amount of methods provided seem sensible to me.

treve 11y ago
Yes, the formats are inspired by standards and similar, but that's not the main point. 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. In addition, there's many useful efforts already existing and underway such as recursion for non-gregorian calendars, consensus-based scheduling (a la doodle), inter-server scheduling (iTip, iMip, iSchedule), Freebusy, Calendar sharing, Availability, etc that all cannot be expressed by JMap. I'm sure there's many more issues that would cause subtle bugs. As long as people are not actually storing iCalendar and vCard, and map to their own inferior data-models (such as Jmap, but Google Calendar is another big offender), we'll continue to have interop issues. The thing is, they don't really like jCal. It has a bit of an odd structure compared to most json formats. So my thinking is that they don't have to support jCal to work within the wider calendaring world, they just need something that maps to iCalendar in a lossless manner. They can deprecate VTIMEZONE and other frustrating features, they can introduce new properties that are easier for them to use, just don't lose compatibility. disclaimer, I'm the main author for sabre/dav and member of CalConnect. Fwiw I DON'T think that the iCalendar format is great, but a replacement will need to have actual backwards compatibility and not just loosely model the few things that a simple online calendar such as fastmail needs.
- untitaker_ 11y ago
  >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.
- brongondwana 11y ago
  We definitely need the ability to store custom properties on the server in JMAP - I think we've agreed on that. Hopefully you'll be at CalConnect in a few weeks and you and Neil can fight to the death or whatever about it.
  - treve 11y ago
    Can't make it unfortunately, but it's really great to hear that this is being considered. Everything seemed pretty set in stone in the past.

treve 11y ago

Yes, the formats are inspired by standards and similar, but that's not the main point. 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. In addition, there's many useful efforts already existing and underway such as recursion for non-gregorian calendars, consensus-based scheduling (a la doodle), inter-server scheduling (iTip, iMip, iSchedule), Freebusy, Calendar sharing, Availability, etc that all cannot be expressed by JMap. I'm sure there's many more issues that would cause subtle bugs. As long as people are not actually storing iCalendar and vCard, and map to their own inferior data-models (such as Jmap, but Google Calendar is another big offender), we'll continue to have interop issues. The thing is, they don't really like jCal. It has a bit of an odd structure compared to most json formats. So my thinking is that they don't have to support jCal to work within the wider calendaring world, they just need something that maps to iCalendar in a lossless manner. They can deprecate VTIMEZONE and other frustrating features, they can introduce new properties that are easier for them to use, just don't lose compatibility. disclaimer, I'm the main author for sabre/dav and member of CalConnect. Fwiw I DON'T think that the iCalendar format is great, but a replacement will need to have actual backwards compatibility and not just loosely model the few things that a simple online calendar such as fastmail needs.

untitaker_ 11y ago
>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.
brongondwana 11y ago
We definitely need the ability to store custom properties on the server in JMAP - I think we've agreed on that. Hopefully you'll be at CalConnect in a few weeks and you and Neil can fight to the death or whatever about it.
- treve 11y ago
  Can't make it unfortunately, but it's really great to hear that this is being considered. Everything seemed pretty set in stone in the past.