[Ietf-caldav] Dead properties on CalDAV events / folders

[Mike Shaver]

On 12/16/05, Wilfredo Sánchez Vega <wsanchez at apple.com> wrote:
>    If you say that a server MUST not modify X- properties then you
> are removing the flexibility on the server side that you are
> requesting on the client side.  A server might, for example, want to
> define some of its own X- properties, or interact with a client or
> with another server through X- properties in a way that involves
> updating a property that the client originally set.

What I'm really saying is that it MUST not modify unknown X-
properties.  If it "knows about" them, then it can obviously modify
them -- that's really what they're for.  And I would expect that a
client MUST round-trip X- properties that are found on what it gets
back from the server.

>    A server author might also decide that X-MOZILLA-GIANT-TURD
> contains no data useful to the application at hand and is willing to
> lose some user functionality in Mozzila in order to save server
> resources.

A server author might also decide that about attachments and timezone
data, both of which are more likely to consume server resources than
some random X-PROP, IMO.  I'll happily admit that I think the
X-PROPERTY support is more useful than most of the alarm
functionality, in a shared-calendar environment.

It turns out that any server implementor can work around even the
strongest MUST, as long as they are allowed to delete or create events
without the explicit action of a given client: they can delete the
event and create a new, identical-but-for-X-MOZILLA-WORLD-PEACE event.
 (Probably in that order to avoid duplicate-ID issues, though the
operation could be atomic as seen by clients, and therefore can
benefit from an implementation optimization that simply mutates the
first event. :) )

>    Obviously, I'm making up stuff, but let's not assume that we know
> what either client or server authors will need to be able to do in
> the future.

Indeed not, which is why I think it's important to preserve the
reliability of a key iCalendar extension mechanism.  Are there _any_
iCalendar-using clients that don't produce (and consume) their own
X-WHATEVERs, for tracking things like sync versions, event
colouration, or such?  I would be surprised, though that's happened
before with calendaring technology.

Mike