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

[Doug Royer]

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
other users.

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 
> future.
> 
>     -wsv
> 
-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: text/x-vcard
Size: 332 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-caldav/attachments/20051216/0710ef5f/Doug.vcf