> 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.
All I ever demanded from my calendaring protocol was to safely and quickly synchronize my calendars between the server and the client. CalDAV has utterly failed at this because it is a complex protocol, and I have no idea how this new protocol improves upon that situation.
I don't give a shit about my CalDAV servers talking to each other and "doing scheduling". I use WhatsApp and email for my scheduling. We don't need more features, we need less of them. CalDAV, iTip and iSchedule seem to be designed around the needs of the corporate bureaucratic world, with little to no regard to the average users' needs, and frankly, I'm horrified that for a protocol drafted in the last three years, XML is still used.
Simplicity is not just some arbitrary property I'm striving for. It's what all protocols out of the DAV series lack to be actually sensibly implementable. Have you read this thread? People are struggling to mount a simple WebDAV collection, because either the clients or the servers are so bad. And you're talking about scheduling.
This isn't even in defense of JMAP. While it at least doesn't try to add crap on top of the crappile, it's just too complex for my usecase either.
I guess I'll just stick to remoteStorage and some ics files in it.
> I guess I'll just stick to remoteStorage and some ics files in it.
Well that was all you needed to begin with, wasn't it? As far as I can tell your use-case could probably be satisfied by rsync alone... might be another option.
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.