[Ietf-caldav] Dead properties on CalDAV events / folders
Doug at Royer.com
Fri Dec 16 11:08:58 PST 2005
If a vendor wishes to use its own properties, it should go through
the registration process and avoid these conflicts;
A server written in 2005 can not already know about a component,
property, or parameter registered in 2006. If a server does not
allows for unknown objects, then there better be some kind of
capability support built into the server so the client can tell
if it can use each server on each initial connection.
A guiding purpose of CALDAV is that you can mix clients
and servers - interoperability. If a client adds X-MOZILLA-EVENT-COLOUR
the user will expect it to work when the REQUEST get forwarded to
It should be up to the client documentation to somehow inform the user
which non-registered features the client uses. Users will expect COLOR
or any other property to work across vendors. And users often do not
read the RFCs.
I think that it needs to be a SHOULD for X- objects, as that may
be the only way to resolve X-NAME usage conflicts.
I think that unknown NON-'X-' objects should be a MUST, as they
may be registered the month after a server is released and
CUAs would then have the right to use them.
Wilfredo Sánchez Vega wrote:
> These are valid points, but I think this warrants a SHOULD in the
> same vain as WebDAV's suggestion on dead props.
> 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.
> 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.
> 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
Doug Royer | http://INET-Consulting.com
We Do Standards - You Need Standards
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 332 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-caldav/attachments/20051216/0710ef5f/Doug.vcf
More information about the Ietf-caldav