headers
Pascal Robert | 8 Oct 2011 22:37
Picon
Gravatar

[ietf-caldav] Non-settable properties on collections

I'm doing some tests with the MkCalendar method, and it looks like some properties can't be set when you
create a collection, I'm getting "<responsedescription>Protected property
{urn:ietf:params:xml:ns:caldav}xxxxxxxx may not be set.</responsedescription>" errors for the
following properties:

max-attendees-per-instance
max-instances
min-date-time
max-resource-size 
max-date-time
supported-calendar-data

If we can't set those properties, how are they set? FYI, I'm testing about Darwin CalendarServer (trunk).
_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 4 comments |
headers
Evert Pot | 8 Oct 2011 22:50
Picon
Favicon
Gravatar

Re: [ietf-caldav] Non-settable properties on collections

CalDAV server implementations are free to make those properties 'protected', so not changeable by a client.

A better place to ask about these things may be the darwin server mailing list.

On 2011-10-08, at 9:37 PM, Pascal Robert wrote:

> I'm doing some tests with the MkCalendar method, and it looks like some properties can't be set when you
create a collection, I'm getting "<responsedescription>Protected property
{urn:ietf:params:xml:ns:caldav}xxxxxxxx may not be set.</responsedescription>" errors for the
following properties:
> 
> max-attendees-per-instance
> max-instances
> min-date-time
> max-resource-size 
> max-date-time
> supported-calendar-data
> 
> If we can't set those properties, how are they set? FYI, I'm testing about Darwin CalendarServer (trunk).
> _______________________________________________
> ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pascal Robert | 9 Oct 2011 00:12
Picon
Gravatar

Re: [ietf-caldav] Non-settable properties on collections


Le 2011-10-08 à 16:50, Evert Pot a écrit :

> CalDAV server implementations are free to make those properties 'protected', so not changeable by a client.

So when the conformance, in RFC 491, says it's protected:

   Conformance:  This property MAY be defined on any calendar
      collection.  If defined, it MUST be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      12.14.1 of [RFC2518]).

It means that it cannot be added/modified? I guess that if the answer is yes, it's probably read-only on all
RFC-compliant implementations. I'm still wondering how those properties can be set if the RFC says that
clients can't modify it. 

> A better place to ask about these things may be the darwin server mailing list.
> 
> 
> On 2011-10-08, at 9:37 PM, Pascal Robert wrote:
> 
>> I'm doing some tests with the MkCalendar method, and it looks like some properties can't be set when you
create a collection, I'm getting "<responsedescription>Protected property
{urn:ietf:params:xml:ns:caldav}xxxxxxxx may not be set.</responsedescription>" errors for the
following properties:
>> 
>> max-attendees-per-instance
>> max-instances
>> min-date-time
>> max-resource-size
(Continue reading)

Permalink | Reply | 1 comment |
headers
Evert Pot | 9 Oct 2011 00:17
Picon
Favicon
Gravatar

Re: [ietf-caldav] Non-settable properties on collections

On 2011-10-08, at 11:12 PM, Pascal Robert wrote:

> 
> Le 2011-10-08 à 16:50, Evert Pot a écrit :
> 
>> CalDAV server implementations are free to make those properties 'protected', so not changeable by a client.
> 
> So when the conformance, in RFC 491, says it's protected:
> 
>   Conformance:  This property MAY be defined on any calendar
>      collection.  If defined, it MUST be protected and SHOULD NOT be
>      returned by a PROPFIND DAV:allprop request (as defined in Section
>      12.14.1 of [RFC2518]).
> 
> It means that it cannot be added/modified? I guess that if the answer is yes, it's probably read-only on all
RFC-compliant implementations. I'm still wondering how those properties can be set if the RFC says that
clients can't modify it. 

I'm not the right person to answer this, but if you follow the spec by the letter, then yes this is true. 

My perspective is that if you need to extend the specification, and you're not breaking RFC-compliant
clients, no harm is done. If I didn't have that perspective, my WebDAV implementation wouldn't be
compliant with half the clients out there :)

But aside from the specification, it looks like you need additional functionality beyond what Darwin
currently provides.. so that's probably where you should be seeking your answers.

Evert

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 9 Oct 2011 13:40
Favicon

Re: [ietf-caldav] Non-settable properties on collections

Hi Pascal,

--On October 8, 2011 4:37:53 PM -0400 Pascal Robert <probert <at> macti.ca> 
wrote:

> I'm doing some tests with the MkCalendar method, and it looks like some
> properties can't be set when you create a collection, I'm getting
> "<responsedescription>Protected property
> {urn:ietf:params:xml:ns:caldav}xxxxxxxx may not be
> set.</responsedescription>" errors for the following properties:
>
> max-attendees-per-instance
> max-instances
> min-date-time
> max-resource-size
> max-date-time
> supported-calendar-data
>
> If we can't set those properties, how are they set? FYI, I'm testing
> about Darwin CalendarServer (trunk).

All those properties are typically controlled by the server to manage its 
own resource limits. In the case of CalendarServer some of those can be set 
via server configuration, but that applies to all calendars.

--

-- 
Cyrus Daboo

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Zitzmann | 20 Oct 2011 01:39

[ietf-caldav] MKCALENDAR and supported-calendar-component-set

Hi:

RFC 4791 says that clients can propose anything they want for the supported-calendar-component-set
property when sending a MKCALENDAR command to the server. But recently I've come across one CalDAV
server, <https://p01-caldav.icloud.com/>, that returns an error 400 if my client tries to issue an
MKCALENDAR command with both VEVENT and VTODO components in the supported-calendar-component-set
property. If the client instead issues the command with just the VEVENT component in the set, then the
server accepts the request. And the RFC says nothing about error 400 being a valid status code for the
MKCALENDAR command.

So I'm tempted to fix this by not sending the property and letting the server decide what to do with the
property in the collection, but I was wondering if there was some way to query the server and see what it does
and does not allow in the supported-calendar-component-set property when making a calendar, and if so,
then what do I have to do to get this information? I did search through the documentation but found nothing.

Nick Zitzmann
<http://www.chronosnet.com/>

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 12 comments |
headers
Cyrus Daboo | 20 Oct 2011 02:52
Favicon

Re: [ietf-caldav] MKCALENDAR and supported-calendar-component-set

Hi Nick,

--On October 19, 2011 5:39:24 PM -0600 Nick Zitzmann <nick <at> chronosnet.com> 
wrote:

> RFC 4791 says that clients can propose anything they want for the
> supported-calendar-component-set property when sending a MKCALENDAR
> command to the server. But recently I've come across one CalDAV server,
> <https://p01-caldav.icloud.com/>, that returns an error 400 if my client
> tries to issue an MKCALENDAR command with both VEVENT and VTODO
> components in the supported-calendar-component-set property. If the
> client instead issues the command with just the VEVENT component in the
> set, then the server accepts the request. And the RFC says nothing about
> error 400 being a valid status code for the MKCALENDAR command.
>
> So I'm tempted to fix this by not sending the property and letting the
> server decide what to do with the property in the collection, but I was
> wondering if there was some way to query the server and see what it does
> and does not allow in the supported-calendar-component-set property when
> making a calendar, and if so, then what do I have to do to get this
> information? I did search through the documentation but found nothing.

I am working on a draft (to be published soon) that describes how a server 
can advertise the set of component combinations it supports for 
supported-calendar-component-set. The basic idea is to advertise that via a 
WebDAV property on the calendar home.

--

-- 
Cyrus Daboo
(Continue reading)

Permalink | Reply | 7 comments |
headers
Helge Hess | 20 Oct 2011 06:50
Favicon

Re: [ietf-caldav] MKCALENDAR and supported-calendar-component-set

On Oct 19, 2011, at 4:39 PM, Nick Zitzmann wrote:
> And the RFC says nothing about error 400 being a valid status code for the MKCALENDAR command.

What are you talking about? A 400 (Bad Request) is a standard HTTP status code and of course you need to expect
this (and process like any other 2xx, 3xx, 4xx or 5xx code).

Anyways, a plain 400 sounds inappropriate (its not a bad request, its just an unsupported one). Cyrus, what
do you think a server should return if a specific combination is unsupported? 501 Not implemented?

hh

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 3 comments |
headers
Jack Cleaver | 20 Oct 2011 09:11

Re: [ietf-caldav] MKCALENDAR and supported-calendar-component-set

On 20/10/2011 05:50, Helge Hess wrote:
> On Oct 19, 2011, at 4:39 PM, Nick Zitzmann wrote:
>> And the RFC says nothing about error 400 being a valid status code
>> for the MKCALENDAR command.
>
> What are you talking about? A 400 (Bad Request) is a standard HTTP
> status code and of course you need to expect this (and process like
> any other 2xx, 3xx, 4xx or 5xx code).
>
> Anyways, a plain 400 sounds inappropriate (its not a bad request, its
> just an unsupported one). Cyrus, what do you think a server should
> return if a specific combination is unsupported? 501 Not
> implemented?

I agree, 400 means the request has malformed syntax (which is wrong).
403 (Forbidden) means: The server understood the request, but is
refusing to fulfill it. Authorization will not help[...].

Seems more appropriate to my mind.

--

-- 
Jack.
_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 2 comments |
headers
Stefan Santesson | 20 Oct 2011 11:53
Favicon

[ietf-caldav] How did I end up on this mailing list?

I have no interest in this list.

As I have not subscribed myself, I have no obvious knowledge on how to
un-subscribe.
Please remove me from this list or help me how I can un-subscribe.

/Stefan

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 1 comment |

Gmane