Subject: [Ietf-caldav] expand example in sec 7.8.3
From: Randy Letness <[email-masked]>
To: [email-masked]
Date: Wed, 27 Sep 2006 15:23:54 -0500
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

I had a question regarding the example of expanded retrieval
of recurring events in section 7.8.3 of the latest draft.
The resulting calendar data includes:
 
   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060103T170000
   DURATION:PT1H
   RECURRENCE-ID:20060103T170000
   SUMMARY:Event #2
   UID:[email-masked]
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060104T190000
   DURATION:PT1H
   RECURRENCE-ID:20060104T170000
   SUMMARY:Event #2 bis
   UID:[email-masked]
   END:VEVENT
   END:VCALENDAR

The start date/times are floating, but in the original .ics
they are fixed with a timezone.  Is this just a typo?

Also, is "expand" supposed to convert floating date/times
to UTC, or leave them as floating?

-Randy

Date: Wed, 27 Sep 2006 17:00:14 +0200
From: Julian Reschke <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
Cc: [email-masked], CalDAV DevList <[email-masked]>

Jari Urpalainen schrieb:
> ...
> as an implementer, while I receive a delete request, I am only
> interested whether the request is allowed or not, so in principle
> request method behavior is of secondary interest. So DELETE may be
> ambiguous by rfc2616 terms, but why does <delete> (or similar, i don't
> care about the name...) privilege have to be ambiguous, if it just
> allows delete request to be performed ? As i tried to explain

Well, if a spec defines a privilege it at least needs to say what it 
means. So can you come up with a definition of that privilege, not in 
terms of method names both describing would kind of resource state 
change it controls?

> previously, you may encounter some unwanted behavior when a resource
> (attached with an acl) is being destroyed  which at least in my
> implementation means also destroying acls (well, i'll store acls within
> extended attributes btw.). And if these removals (acl & resource) are
> out of sync, definitely there's a chance of getting something wrong, but
> it doesn't need to be that way cause implementers should know ;-) what's
> happening. 

Could you explain how this is a problem of the protocol? As far as I can 
tell, it seems to be an implementation issue, right?

>> What we did agree upon is that you can't DELETE something unless you 
>> have a unbind permission on the parent collection. That's a well-defined 
>> privilege.
>>
> Well defined, right and yes, a useful privilege. The problem is, that it
> can be too powerful for shared collections, so if e.g. two users (or
> groups), a) & b) are allowed to create resources onto the same shared
> collection (so a) & b) have <bind> privilege there) and if i want them
> to also remove the resources they have created I must allow <unbind> to
> this shared collection. But then assume that a) & b) set strict acls for

Yes.

> these new resources ("private"). Well, an a) user may not even read b)'s
> resources but it can unbind b)'s resources (which means usually unlink
> in unix terms) ! When I started the module implementation, I took it for

It means that only in the case where you don't have an additional 
(custom) privilege preventing this.

> granted that rfc3744 had this basic unix sticky bit (t) like feature so
> that different users can't step onto the toes of others. So you can
> overcome this by only allowing collections by a group/user basis but I
> find this too limiting, given the fact that there's a relatively easy
> solution for this, imo (although we seem to be disagreeing here).  
> 
>> Now whether you need *more* than that privilege depends entirely on what 
>> the server does after removing the binding (nothing/move to 
>> trashcan/destroy object/whatever). The base spec just doesn't tell us. 
>> Thus, the ACL spec is silent on that.
>>
>> *If* a server requires additional privileges, it can add a custom 
>> privilege that a client can discover. However, that privilege wouldn't 
>> have shown up in the method table in 
>> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>, because 
>> by definition it wouldn't have been a *required* privilege.
>>
>> That being said, if you feel that the absence of something like 
>> DAV:destroy-resource is a problem, there's always the possibility to 
>> describe it in a separate document, and try to get implementors that 
>> have a matching resource deletion model to support this...
>>
>> Best regards, Julian
> Yes, I would actually want to have this feature (in addition to e.g. a
> user settable default acl == ~ unix umask). But how this would work
> within an extension, i don't know. The spec already requires/implies to
> quite many negotiations, so client implementations aren't that trivial
> mostly because servers may be so flexible. Secondly, there could be some
> clarifications on rfc3744: application/xml mime type on examples,

RFC3744 allows both text/xml and application/xml, and RFC2518bis is 
going to deprecate text/xml (and use application/xml in examples). If we 
ever get to revising RFC3744, we'll make that change as well.

> collations on <principal-property-search> ?, text clarifications, are

I'm not sure that collation support is really important (servers today 
have lots of freedom how to do the property matching, and this IMHO is 
sufficient).

Also, do you have any specific text clarifications in mind?

> users allowed to create groups on-the-fly ? etc. So bis may not be

RF3744 doesn't talk about principal creation at all, I think...

> necessary, but if you (and/or others) have interest to stab on this
> someway, i'm willing to help.

Well, the "current" version is at 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html>,.

But right now, the most important thing the WebDAV WG needs to finish is 
RFC2518bis. Any contributions to that would be even more welcome :-)

Best regards, Julian

Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
From: Jari Urpalainen <[email-masked]>
To: ext Julian Reschke <[email-masked]>
Date: Mon, 25 Sep 2006 15:05:03 +0300
Cc: [email-masked], CalDAV DevList <[email-masked]>

On Fri, 2006-09-22 at 20:00 +0200, ext Julian Reschke wrote:
> Jari Urpalainen schrieb:
> > Julian, sorry for being stubborn ;-) 
> 
> You aren't.
> 
> > ok, I did some homework about the background:
> > <http://mailman.webdav.org/pipermail/acl/2003-September/001654.html>
> > 
> > I think the ambiguity you are referring to is about: when does acls
> > disappear (when there are e.g. several references to single object) ? If
> > they will be unlinked (or really destroyed) during phase 1) I'll agree
> > that there's probably a chance of some weird implications but it depends
> > on the implementation. However, if you do this unlinking on stage 2) I
> > still cannot see what exactly goes wrong. Or you are actually saying
> > that while you implement acls you don't know or don't have control to
> > basic DELETE behavior. Whatever, the issue may have pragmatic
> > implications but it certainly prohibits a useful use-case, imo. 
> > 
> > anyway, thanks for your enlightenment.
> > br,
> > Jari
> 
> Hm, I'm not sure I follow.
> 
> The ambiguity *I* was mentioning was that RFC2616/RFC2518 do not clearly 
> define the semantics of DELETE, thus having a delete privilege makes 
> little sense if we can't say what it means.
> 
as an implementer, while I receive a delete request, I am only
interested whether the request is allowed or not, so in principle
request method behavior is of secondary interest. So DELETE may be
ambiguous by rfc2616 terms, but why does <delete> (or similar, i don't
care about the name...) privilege have to be ambiguous, if it just
allows delete request to be performed ? As i tried to explain
previously, you may encounter some unwanted behavior when a resource
(attached with an acl) is being destroyed  which at least in my
implementation means also destroying acls (well, i'll store acls within
extended attributes btw.). And if these removals (acl & resource) are
out of sync, definitely there's a chance of getting something wrong, but
it doesn't need to be that way cause implementers should know ;-) what's
happening. 

> What we did agree upon is that you can't DELETE something unless you 
> have a unbind permission on the parent collection. That's a well-defined 
> privilege.
> 
Well defined, right and yes, a useful privilege. The problem is, that it
can be too powerful for shared collections, so if e.g. two users (or
groups), a) & b) are allowed to create resources onto the same shared
collection (so a) & b) have <bind> privilege there) and if i want them
to also remove the resources they have created I must allow <unbind> to
this shared collection. But then assume that a) & b) set strict acls for
these new resources ("private"). Well, an a) user may not even read b)'s
resources but it can unbind b)'s resources (which means usually unlink
in unix terms) ! When I started the module implementation, I took it for
granted that rfc3744 had this basic unix sticky bit (t) like feature so
that different users can't step onto the toes of others. So you can
overcome this by only allowing collections by a group/user basis but I
find this too limiting, given the fact that there's a relatively easy
solution for this, imo (although we seem to be disagreeing here).  

> Now whether you need *more* than that privilege depends entirely on what 
> the server does after removing the binding (nothing/move to 
> trashcan/destroy object/whatever). The base spec just doesn't tell us. 
> Thus, the ACL spec is silent on that.
> 
> *If* a server requires additional privileges, it can add a custom 
> privilege that a client can discover. However, that privilege wouldn't 
> have shown up in the method table in 
> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>, because 
> by definition it wouldn't have been a *required* privilege.
> 
> That being said, if you feel that the absence of something like 
> DAV:destroy-resource is a problem, there's always the possibility to 
> describe it in a separate document, and try to get implementors that 
> have a matching resource deletion model to support this...
> 
> Best regards, Julian
Yes, I would actually want to have this feature (in addition to e.g. a
user settable default acl == ~ unix umask). But how this would work
within an extension, i don't know. The spec already requires/implies to
quite many negotiations, so client implementations aren't that trivial
mostly because servers may be so flexible. Secondly, there could be some
clarifications on rfc3744: application/xml mime type on examples,
collations on <principal-property-search> ?, text clarifications, are
users allowed to create groups on-the-fly ? etc. So bis may not be
necessary, but if you (and/or others) have interest to stab on this
someway, i'm willing to help.

br,
Jari

Date: Fri, 22 Sep 2006 20:00:31 +0200
From: Julian Reschke <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
Cc: [email-masked], CalDAV DevList <[email-masked]>

Jari Urpalainen schrieb:
> Julian, sorry for being stubborn ;-) 

You aren't.

> ok, I did some homework about the background:
> <http://mailman.webdav.org/pipermail/acl/2003-September/001654.html>
> 
> I think the ambiguity you are referring to is about: when does acls
> disappear (when there are e.g. several references to single object) ? If
> they will be unlinked (or really destroyed) during phase 1) I'll agree
> that there's probably a chance of some weird implications but it depends
> on the implementation. However, if you do this unlinking on stage 2) I
> still cannot see what exactly goes wrong. Or you are actually saying
> that while you implement acls you don't know or don't have control to
> basic DELETE behavior. Whatever, the issue may have pragmatic
> implications but it certainly prohibits a useful use-case, imo. 
> 
> anyway, thanks for your enlightenment.
> br,
> Jari

Hm, I'm not sure I follow.

The ambiguity *I* was mentioning was that RFC2616/RFC2518 do not clearly 
define the semantics of DELETE, thus having a delete privilege makes 
little sense if we can't say what it means.

What we did agree upon is that you can't DELETE something unless you 
have a unbind permission on the parent collection. That's a well-defined 
privilege.

Now whether you need *more* than that privilege depends entirely on what 
the server does after removing the binding (nothing/move to 
trashcan/destroy object/whatever). The base spec just doesn't tell us. 
Thus, the ACL spec is silent on that.

*If* a server requires additional privileges, it can add a custom 
privilege that a client can discover. However, that privilege wouldn't 
have shown up in the method table in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>, because 
by definition it wouldn't have been a *required* privilege.

That being said, if you feel that the absence of something like 
DAV:destroy-resource is a problem, there's always the possibility to 
describe it in a separate document, and try to get implementors that 
have a matching resource deletion model to support this...

Best regards, Julian

Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
From: Jari Urpalainen <[email-masked]>
To: ext Julian Reschke <[email-masked]>
Date: Fri, 22 Sep 2006 17:52:02 +0300
Cc: [email-masked], CalDAV DevList <[email-masked]>

Julian, sorry for being stubborn ;-) 

On Fri, 2006-09-22 at 13:09 +0200, ext Julian Reschke wrote:
> Jari Urpalainen schrieb:
>  >...
> > The problem is that there is no strong definition for DELETE in the 
> >> first place. Some servers just remove the binding (thus affect the state 
> >> of the parent collection) and then garbage collect resources with no 
> >> URIs left, other move them into a trashcan, other destroy them immediately.
> >>
> >> That's why the definition of the DAV:delete privilege was ambiguous and 
> >> was removed.
> >>
> > hmm. Are we speaking about the spec or actual, maybe somewhat weird
> > implementations ? Sorry, I'm still confused why e.g. the actual type of
> > implemented removal will influence delete privilege ? So if you allow
> > (ambiguous ?) delete you would allow only binding removal, move to
> > trashcan or complete removal (the latter of which is my preference,
> > btw.).
> 
> The WebDAV ACL spec tries to define privileges based on the nature of a 
> method invocation (it's semantics), not the syntax alone. For instance, 
> you don't have a privilege for REPORT, as what a REPORT actually does 
> depends on the request body.
> 
> This way, new methods can be introduced without the need to define new 
> privileges (in general). For instance, MKCOL is similar to PUT, in that 
> it adds a new member to it's parent collection.
> 
> The trouble with DELETE was that when we discussed it, there was 
> absolutely no agreement about it's semantics are (funny enough, a 
> similar issue ist just being discussed over at the atom-protocol mailing 
> list).
> 
no wonder ;)

> In general, DELETE will
> 
> 1) unmap the URL and
> 2) optionall garbage collect the object if it doesn't have any 
> references anymore.
> 
agreed, this is the "rather well-known" rfc2616 model 

> For simple servers that have a single URL per object, this may be a 
> single well-defined operation. In general it isn't.
> 
> The only semantics we all agreed on is that removing a member from a 
> WebDAV collection affects the state of that collection, thus the 
> DAV:unbind privilege has been defined to cover exactly that.
> 
ok, I did some homework about the background:
<http://mailman.webdav.org/pipermail/acl/2003-September/001654.html>

I think the ambiguity you are referring to is about: when does acls
disappear (when there are e.g. several references to single object) ? If
they will be unlinked (or really destroyed) during phase 1) I'll agree
that there's probably a chance of some weird implications but it depends
on the implementation. However, if you do this unlinking on stage 2) I
still cannot see what exactly goes wrong. Or you are actually saying
that while you implement acls you don't know or don't have control to
basic DELETE behavior. Whatever, the issue may have pragmatic
implications but it certainly prohibits a useful use-case, imo. 

anyway, thanks for your enlightenment.
br,
Jari

Date: Fri, 22 Sep 2006 13:09:33 +0200
From: Julian Reschke <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
Cc: [email-masked], CalDAV DevList <[email-masked]>

Jari Urpalainen schrieb:
 >...
> The problem is that there is no strong definition for DELETE in the 
>> first place. Some servers just remove the binding (thus affect the state 
>> of the parent collection) and then garbage collect resources with no 
>> URIs left, other move them into a trashcan, other destroy them immediately.
>>
>> That's why the definition of the DAV:delete privilege was ambiguous and 
>> was removed.
>>
> hmm. Are we speaking about the spec or actual, maybe somewhat weird
> implementations ? Sorry, I'm still confused why e.g. the actual type of
> implemented removal will influence delete privilege ? So if you allow
> (ambiguous ?) delete you would allow only binding removal, move to
> trashcan or complete removal (the latter of which is my preference,
> btw.).

The WebDAV ACL spec tries to define privileges based on the nature of a 
method invocation (it's semantics), not the syntax alone. For instance, 
you don't have a privilege for REPORT, as what a REPORT actually does 
depends on the request body.

This way, new methods can be introduced without the need to define new 
privileges (in general). For instance, MKCOL is similar to PUT, in that 
it adds a new member to it's parent collection.

The trouble with DELETE was that when we discussed it, there was 
absolutely no agreement about it's semantics are (funny enough, a 
similar issue ist just being discussed over at the atom-protocol mailing 
list).

In general, DELETE will

1) unmap the URL and
2) optionall garbage collect the object if it doesn't have any 
references anymore.

For simple servers that have a single URL per object, this may be a 
single well-defined operation. In general it isn't.

The only semantics we all agreed on is that removing a member from a 
WebDAV collection affects the state of that collection, thus the 
DAV:unbind privilege has been defined to cover exactly that.

>>>> Secondly, while distributed acl rules (on different servers) or
>>>> referencing distributed group principals may be cool they are quite
>>>> challenging to implement, that's why I was hoping to see a postcondition
>>>> like "DAV:no-distributed-acls" (and something similar to distributed
>>>> groups). Also this should be listed on <acl-restrictions>.  What I mean,
>>>> there are other things that are optional to implement which are imo much
>>>> easier to implement than these. So probably the "generic"
>>>> "no-ace-conflict" could be used here, but it isn't that descriptive for
>>>> the client (the implementation of which in general, must be quite
>>>> flexible imo btw.).
>> When you say "distributed", what exactly are you referring to? The 
>> inheritance mechanism defined in 
>> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4>?
>>
>>> ...
> 
> Most likely I've understood (and even implemented) inheritance in this
> context (which is imo an "advanced" feature of the spec). What I'm
> trying to refer to: if you list e.g. a "remote" principal group uri
> (remote.com) within a "local" principal group uri (example.com), i.e.
> the acl evaluator should retrieve this remote group content and also
> keep sync with this uri content in order to do proper evaluations (and
> similarly, when inherited acls exist on another server). So this is imo
> hard to implement (DoS, trust=credentials, retrieve, sync, loops etc.),
> so I was thinking about simple server implementations which only support
> locally accessed rules or groups (and sure you can have multiple virtual
> hosts). So having uri references makes things really flexible but also
> easily broken. So maybe <recognized-principal> etc. will do the trick,
> but I'd prefer to see a clearer alternative (i may have misunderstood
> this totally, however...)

Hm. The ACL spec gives the responsibility where to place principals 
(principal URIs) to the server. I personally haven't seen an 
implementation that puts principals "somewhere else" yet. Why do you do 
that in the first place, if it hurts...?

Best regards, Julian

Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
From: Jari Urpalainen <[email-masked]>
To: ext Julian Reschke <[email-masked]>
Date: Fri, 22 Sep 2006 13:50:36 +0300
Cc: [email-masked], CalDAV DevList <[email-masked]>

On Fri, 2006-09-22 at 11:24 +0200, ext Julian Reschke wrote:
> Bernard Desruisseaux schrieb:
> > Hi Jari,
> > 
> > I've CCed the WebDAV ACL mailing list ([email-masked]).
> > 
> > See comments below.
> > 
> > Cheers,
> > Bernard
> > 
> > Jari Urpalainen wrote:
> >> Hi all!
> >>
> >> Sorry that my questions/comments are on the wrong list... but caldav
> >> requires dav acls. Anyway, I've been implementing dav acls as an apache
> >> module for a while and there are some issues which are imo worth
> >> discussing (sorry again if these have been discussed before...)
> >>
> >> First, it seems to me that it is impossible to implement a unix sticky
> >> bit  (t) like feature for a collection (like in unix /tmp), i.e. users
> >> could safely create files into a shared collection without the fear that
> >> others can delete them. As it stands now in the spec you'll need to have
> >> <unbind> privilege of the parent collection to remove a file.
> > 
> > This is correct.
> 
> The ACL spec says you need the unbind privilege, but it doesn't say a 
> server can't implement additional (custom) privileges on the member that 
> you would need to have as well.
> 
> >  > So you'll
> >> have to give that privilege to a user for him/her to delete his/her
> >> files. And similarly all other users needs this privilege as well for
> >> their files. So no matter how strict rules you'll have on your files
> >> other users could still remove your files, right ? If I have understood
> >> this correctly, imo it could e.g. be solved by changing the delete rule
> >> so that write privilege for a resource would allow the removal of a
> >> resource (this is actually what i've implemented). I.e. with write
> >> privilege you can "empty" body and dead properties which is almost like
> >> a removal of a resource.
> 
> Yes, you could do that.

right, but doesn't help interop. 

> 
> > You should look at the WebDAV ACL mailing list archive
> > (http://mailman.webdav.org/pipermail/acl/) as well as
> > old versions of the WebDAV ACL draft
> > (http://ietfreport.isoc.org/idref/draft-ietf-webdav-acl/).
> > 
> > You'll notice that up to draft -10 there was a DAV:delete
> > privilege but the WG "couldn't agree for the need of that
> > privilege." Check:
> > 
> > http://mailman.webdav.org/pipermail/acl/2003-November/001782.html
> 
> The problem is that there is no strong definition for DELETE in the 
> first place. Some servers just remove the binding (thus affect the state 
> of the parent collection) and then garbage collect resources with no 
> URIs left, other move them into a trashcan, other destroy them immediately.
> 
> That's why the definition of the DAV:delete privilege was ambiguous and 
> was removed.
> 
hmm. Are we speaking about the spec or actual, maybe somewhat weird
implementations ? Sorry, I'm still confused why e.g. the actual type of
implemented removal will influence delete privilege ? So if you allow
(ambiguous ?) delete you would allow only binding removal, move to
trashcan or complete removal (the latter of which is my preference,
btw.).

> >> Secondly, while distributed acl rules (on different servers) or
> >> referencing distributed group principals may be cool they are quite
> >> challenging to implement, that's why I was hoping to see a postcondition
> >> like "DAV:no-distributed-acls" (and something similar to distributed
> >> groups). Also this should be listed on <acl-restrictions>.  What I mean,
> >> there are other things that are optional to implement which are imo much
> >> easier to implement than these. So probably the "generic"
> >> "no-ace-conflict" could be used here, but it isn't that descriptive for
> >> the client (the implementation of which in general, must be quite
> >> flexible imo btw.).
> 
> When you say "distributed", what exactly are you referring to? The 
> inheritance mechanism defined in 
> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4>?
> 
> > ...

Most likely I've understood (and even implemented) inheritance in this
context (which is imo an "advanced" feature of the spec). What I'm
trying to refer to: if you list e.g. a "remote" principal group uri
(remote.com) within a "local" principal group uri (example.com), i.e.
the acl evaluator should retrieve this remote group content and also
keep sync with this uri content in order to do proper evaluations (and
similarly, when inherited acls exist on another server). So this is imo
hard to implement (DoS, trust=credentials, retrieve, sync, loops etc.),
so I was thinking about simple server implementations which only support
locally accessed rules or groups (and sure you can have multiple virtual
hosts). So having uri references makes things really flexible but also
easily broken. So maybe <recognized-principal> etc. will do the trick,
but I'd prefer to see a clearer alternative (i may have misunderstood
this totally, however...)

> Best regards, Julian

thanks,
Jari

Date: Fri, 22 Sep 2006 11:24:02 +0200
From: Julian Reschke <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
Cc: CalDAV DevList <[email-masked]>, [email-masked]

Bernard Desruisseaux schrieb:
> Hi Jari,
> 
> I've CCed the WebDAV ACL mailing list ([email-masked]).
> 
> See comments below.
> 
> Cheers,
> Bernard
> 
> Jari Urpalainen wrote:
>> Hi all!
>>
>> Sorry that my questions/comments are on the wrong list... but caldav
>> requires dav acls. Anyway, I've been implementing dav acls as an apache
>> module for a while and there are some issues which are imo worth
>> discussing (sorry again if these have been discussed before...)
>>
>> First, it seems to me that it is impossible to implement a unix sticky
>> bit  (t) like feature for a collection (like in unix /tmp), i.e. users
>> could safely create files into a shared collection without the fear that
>> others can delete them. As it stands now in the spec you'll need to have
>> <unbind> privilege of the parent collection to remove a file.
> 
> This is correct.

The ACL spec says you need the unbind privilege, but it doesn't say a 
server can't implement additional (custom) privileges on the member that 
you would need to have as well.

>  > So you'll
>> have to give that privilege to a user for him/her to delete his/her
>> files. And similarly all other users needs this privilege as well for
>> their files. So no matter how strict rules you'll have on your files
>> other users could still remove your files, right ? If I have understood
>> this correctly, imo it could e.g. be solved by changing the delete rule
>> so that write privilege for a resource would allow the removal of a
>> resource (this is actually what i've implemented). I.e. with write
>> privilege you can "empty" body and dead properties which is almost like
>> a removal of a resource.

Yes, you could do that.

> You should look at the WebDAV ACL mailing list archive
> (http://mailman.webdav.org/pipermail/acl/) as well as
> old versions of the WebDAV ACL draft
> (http://ietfreport.isoc.org/idref/draft-ietf-webdav-acl/).
> 
> You'll notice that up to draft -10 there was a DAV:delete
> privilege but the WG "couldn't agree for the need of that
> privilege." Check:
> 
> http://mailman.webdav.org/pipermail/acl/2003-November/001782.html

The problem is that there is no strong definition for DELETE in the 
first place. Some servers just remove the binding (thus affect the state 
of the parent collection) and then garbage collect resources with no 
URIs left, other move them into a trashcan, other destroy them immediately.

That's why the definition of the DAV:delete privilege was ambiguous and 
was removed.

>> Secondly, while distributed acl rules (on different servers) or
>> referencing distributed group principals may be cool they are quite
>> challenging to implement, that's why I was hoping to see a postcondition
>> like "DAV:no-distributed-acls" (and something similar to distributed
>> groups). Also this should be listed on <acl-restrictions>.  What I mean,
>> there are other things that are optional to implement which are imo much
>> easier to implement than these. So probably the "generic"
>> "no-ace-conflict" could be used here, but it isn't that descriptive for
>> the client (the implementation of which in general, must be quite
>> flexible imo btw.).

When you say "distributed", what exactly are you referring to? The 
inheritance mechanism defined in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4>?

> ...

Best regards, Julian

Subject: Re: [Ietf-caldav] DAV acls
From: Jari Urpalainen <[email-masked]>
To: ext Bernard Desruisseaux <[email-masked]>
Date: Fri, 22 Sep 2006 12:03:47 +0300
Cc: [email-masked], CalDAV DevList <[email-masked]>

Thanks Bernard for your response,

On Thu, 2006-09-21 at 10:34 -0400, ext Bernard Desruisseaux wrote:
> Hi Jari,
> 
> I've CCed the WebDAV ACL mailing list ([email-masked]).
> 
> See comments below.
> 
> Cheers,
> Bernard
> 
> Jari Urpalainen wrote:
> > Hi all!
> > 
> > Sorry that my questions/comments are on the wrong list... but caldav
> > requires dav acls. Anyway, I've been implementing dav acls as an apache
> > module for a while and there are some issues which are imo worth
> > discussing (sorry again if these have been discussed before...)
> > 
> > First, it seems to me that it is impossible to implement a unix sticky
> > bit  (t) like feature for a collection (like in unix /tmp), i.e. users
> > could safely create files into a shared collection without the fear that
> > others can delete them. As it stands now in the spec you'll need to have
> > <unbind> privilege of the parent collection to remove a file.
> 
> This is correct.
> 
>  > So you'll
> > have to give that privilege to a user for him/her to delete his/her
> > files. And similarly all other users needs this privilege as well for
> > their files. So no matter how strict rules you'll have on your files
> > other users could still remove your files, right ? If I have understood
> > this correctly, imo it could e.g. be solved by changing the delete rule
> > so that write privilege for a resource would allow the removal of a
> > resource (this is actually what i've implemented). I.e. with write
> > privilege you can "empty" body and dead properties which is almost like
> > a removal of a resource.
> 
> You should look at the WebDAV ACL mailing list archive
> (http://mailman.webdav.org/pipermail/acl/) as well as
> old versions of the WebDAV ACL draft
> (http://ietfreport.isoc.org/idref/draft-ietf-webdav-acl/).
> 
> You'll notice that up to draft -10 there was a DAV:delete
> privilege but the WG "couldn't agree for the need of that
> privilege." Check:
> 
> http://mailman.webdav.org/pipermail/acl/2003-November/001782.html
> 

Well, I would definitely want to have a safe access to resources within
a shared collection. I think that if you really implement this kind of
framework this is one of the basic things (so these acls can't cope even
with "standard" unix filesystem permissions :(). So I'm not happy with
this "safe collection model" only.

> > 
> > Secondly, while distributed acl rules (on different servers) or
> > referencing distributed group principals may be cool they are quite
> > challenging to implement, that's why I was hoping to see a postcondition
> > like "DAV:no-distributed-acls" (and something similar to distributed
> > groups). Also this should be listed on <acl-restrictions>.  What I mean,
> > there are other things that are optional to implement which are imo much
> > easier to implement than these. So probably the "generic"
> > "no-ace-conflict" could be used here, but it isn't that descriptive for
> > the client (the implementation of which in general, must be quite
> > flexible imo btw.).
> > 
> > Still a question about acl usage with caldav: a client puts a new ics
> > file into a calendar collection and server does not (auto)generate any
> > acl for it (this is very implementation specific if/as we follow
> > rfc3744).
> 
> Actually, a server most likely will set a default ACL on the new
> resource.
> 
right, from implementers point of view I'll happen to dislike this "most
likely" thing, i.e. I'll prefer explicit behavior especially on security
related matters.  

> > The client does not support acls (uses only "private"
> > calendars). So another client queries freebusy info, is it allowed or
> > not ? (probably latter).
> 
> All depends on the default ACL set by the server. Currently, I would
> expect servers to allow users to configure the default ACL value in
> a proprietary way.
> 

right, makes implementers life easy... Agreed, some umask kind of
feature is definitely on the wish list.
 
>  > But agreed, this ambiguity results from rfc3744
> > being "liberal". So imo, it would be clearer if servers must generate
> > e.g. an acl where the owner has full rights (and others none) for a new
> > created resource. In addition, acls would then be needed for truly
> > shared resources only (or allowing freebusy reports for others).
> 
> Correct. Servers have no standard way to allow client to manage or
> discover the default/initial ACL value for new resources.
> 
> Cyrus, Lisa and I had lots of discussions on whether a calendar
> collection should have a property (protected or not) that would
> allow client to discover and manage (if the property is not
> protected) the default ACL for new calendar object resources.
> We also had discussions on ACL inheritance as well. As you may
> have guessed, we have decided to address those issues in a
> separate draft...
> 
ok, FWIW I think this means either bis (my preference) or possibly you
could write a generic acl extension (even a BCP would help). But anyhow,
imo this concerns all acl usages, not only caldav, at least if you want
to have broader acceptance or deployment of this technology (which is in
general imo pretty reasonable).
thanks,
jari

Date: Thu, 21 Sep 2006 19:22:03 +0200
From: Julian Reschke <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-caldav] New draft
Cc: CalDAV DevList <[email-masked]>

Bernard Desruisseaux schrieb:
> Hi Julian,
> 
> The Collation Registry draft encourage protocol specification to do so.
> 
> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt
> 
>  > 5.6.  Error Codes
>  >
>  >    The protocol specification should consider assigning protocol error
>  >    codes for the following circumstances:
>  >    o  The client requests the use of a collation by identifier or
>  >       pattern, but no implemented collation matches that pattern.
> 
> I believe other WebDAV specs also have MUST level requirements to
> return preconditions.
 > ...

Sure, that part is OK. I just don't grok why you would want to forbid  a 
client to *try* to use an unsupported collation ("Clients MUST only use 
collations from the list advertised by the server.").

Best regards, Julian

Date: Thu, 21 Sep 2006 13:06:43 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] New draft
Cc: CalDAV DevList <[email-masked]>

Hi Julian,

The Collation Registry draft encourage protocol specification to do so.

http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt

 > 5.6.  Error Codes
 >
 >    The protocol specification should consider assigning protocol error
 >    codes for the following circumstances:
 >    o  The client requests the use of a collation by identifier or
 >       pattern, but no implemented collation matches that pattern.

I believe other WebDAV specs also have MUST level requirements to
return preconditions.

Cheers,
Bernard

Julian Reschke wrote:
> Cyrus Daboo schrieb:
>> Hi folks,
>> Following the last IESG review there was push-back on i18n issues wrt 
>> text comparisons done in the calendar-query report. As a result we 
>> have now added support for collations as defined in 
>> <http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt>. 
>> This involved a whole new section (7.5) and modification to the 
>> text-match element.
>>
>> The basic change was to eliminate the caseless attribute in text-match 
>> and instead add a collation attribute that takes the name of one of 
>> the supported collations on the server. With this, the text comparison 
>> operation will follow the well defined rules of the collation.
>>
>> The link to the draft is here:
>>
>> <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-15.txt>
>>
>> An HTML diff from the previous version is here:
>>
>> <http://ietf.osafoundation.org/caldav/draft-dusseault-caldav-15-from-14.diff.html> 
> 
> 
> Thanks.
> 
> I just read 7.5 (not the subsections), and it's a bit weird that the 
> spec mandates normative behaviour for edge cases where a client violates 
> MUST level requirements... Please be more conservative in throwing in 
> RFC2119 keywords...
> 
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 21 Sep 2006 10:34:45 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [Ietf-caldav] DAV acls
Cc: [email-masked], CalDAV DevList <[email-masked]>

Hi Jari,

I've CCed the WebDAV ACL mailing list ([email-masked]).

See comments below.

Cheers,
Bernard

Jari Urpalainen wrote:
> Hi all!
> 
> Sorry that my questions/comments are on the wrong list... but caldav
> requires dav acls. Anyway, I've been implementing dav acls as an apache
> module for a while and there are some issues which are imo worth
> discussing (sorry again if these have been discussed before...)
> 
> First, it seems to me that it is impossible to implement a unix sticky
> bit  (t) like feature for a collection (like in unix /tmp), i.e. users
> could safely create files into a shared collection without the fear that
> others can delete them. As it stands now in the spec you'll need to have
> <unbind> privilege of the parent collection to remove a file.

This is correct.

 > So you'll
> have to give that privilege to a user for him/her to delete his/her
> files. And similarly all other users needs this privilege as well for
> their files. So no matter how strict rules you'll have on your files
> other users could still remove your files, right ? If I have understood
> this correctly, imo it could e.g. be solved by changing the delete rule
> so that write privilege for a resource would allow the removal of a
> resource (this is actually what i've implemented). I.e. with write
> privilege you can "empty" body and dead properties which is almost like
> a removal of a resource.

You should look at the WebDAV ACL mailing list archive
(http://mailman.webdav.org/pipermail/acl/) as well as
old versions of the WebDAV ACL draft
(http://ietfreport.isoc.org/idref/draft-ietf-webdav-acl/).

You'll notice that up to draft -10 there was a DAV:delete
privilege but the WG "couldn't agree for the need of that
privilege." Check:

http://mailman.webdav.org/pipermail/acl/2003-November/001782.html

> 
> Secondly, while distributed acl rules (on different servers) or
> referencing distributed group principals may be cool they are quite
> challenging to implement, that's why I was hoping to see a postcondition
> like "DAV:no-distributed-acls" (and something similar to distributed
> groups). Also this should be listed on <acl-restrictions>.  What I mean,
> there are other things that are optional to implement which are imo much
> easier to implement than these. So probably the "generic"
> "no-ace-conflict" could be used here, but it isn't that descriptive for
> the client (the implementation of which in general, must be quite
> flexible imo btw.).
> 
> Still a question about acl usage with caldav: a client puts a new ics
> file into a calendar collection and server does not (auto)generate any
> acl for it (this is very implementation specific if/as we follow
> rfc3744).

Actually, a server most likely will set a default ACL on the new
resource.

> The client does not support acls (uses only "private"
> calendars). So another client queries freebusy info, is it allowed or
> not ? (probably latter).

All depends on the default ACL set by the server. Currently, I would
expect servers to allow users to configure the default ACL value in
a proprietary way.

 > But agreed, this ambiguity results from rfc3744
> being "liberal". So imo, it would be clearer if servers must generate
> e.g. an acl where the owner has full rights (and others none) for a new
> created resource. In addition, acls would then be needed for truly
> shared resources only (or allowing freebusy reports for others).

Correct. Servers have no standard way to allow client to manage or
discover the default/initial ACL value for new resources.

Cyrus, Lisa and I had lots of discussions on whether a calendar
collection should have a property (protected or not) that would
allow client to discover and manage (if the property is not
protected) the default ACL for new calendar object resources.
We also had discussions on ACL inheritance as well. As you may
have guessed, we have decided to address those issues in a
separate draft...

> 
> There are quite many other minor issues as well (or difficulties to
> understand the meaning of the spec) but in general I like the basic
> simplicity of the spec. But I'll hope someone can enlighten me first
> with answers to these basic questions...
> 
> thanks,
> Jari
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Jari Urpalainen <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Thu, 21 Sep 2006 15:26:35 +0300
Subject: [Ietf-caldav] DAV acls

Hi all!

Sorry that my questions/comments are on the wrong list... but caldav
requires dav acls. Anyway, I've been implementing dav acls as an apache
module for a while and there are some issues which are imo worth
discussing (sorry again if these have been discussed before...)

First, it seems to me that it is impossible to implement a unix sticky
bit  (t) like feature for a collection (like in unix /tmp), i.e. users
could safely create files into a shared collection without the fear that
others can delete them. As it stands now in the spec you'll need to have
<unbind> privilege of the parent collection to remove a file. So you'll
have to give that privilege to a user for him/her to delete his/her
files. And similarly all other users needs this privilege as well for
their files. So no matter how strict rules you'll have on your files
other users could still remove your files, right ? If I have understood
this correctly, imo it could e.g. be solved by changing the delete rule
so that write privilege for a resource would allow the removal of a
resource (this is actually what i've implemented). I.e. with write
privilege you can "empty" body and dead properties which is almost like
a removal of a resource.

Secondly, while distributed acl rules (on different servers) or
referencing distributed group principals may be cool they are quite
challenging to implement, that's why I was hoping to see a postcondition
like "DAV:no-distributed-acls" (and something similar to distributed
groups). Also this should be listed on <acl-restrictions>.  What I mean,
there are other things that are optional to implement which are imo much
easier to implement than these. So probably the "generic"
"no-ace-conflict" could be used here, but it isn't that descriptive for
the client (the implementation of which in general, must be quite
flexible imo btw.).

Still a question about acl usage with caldav: a client puts a new ics
file into a calendar collection and server does not (auto)generate any
acl for it (this is very implementation specific if/as we follow
rfc3744). The client does not support acls (uses only "private"
calendars). So another client queries freebusy info, is it allowed or
not ? (probably latter). But agreed, this ambiguity results from rfc3744
being "liberal". So imo, it would be clearer if servers must generate
e.g. an acl where the owner has full rights (and others none) for a new
created resource. In addition, acls would then be needed for truly
shared resources only (or allowing freebusy reports for others).

There are quite many other minor issues as well (or difficulties to
understand the meaning of the spec) but in general I like the basic
simplicity of the spec. But I'll hope someone can enlighten me first
with answers to these basic questions...

thanks,
Jari

Date: Mon, 18 Sep 2006 23:01:16 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] New draft
Cc: CalDAV DevList <[email-masked]>

Cyrus Daboo schrieb:
> Hi folks,
> Following the last IESG review there was push-back on i18n issues wrt 
> text comparisons done in the calendar-query report. As a result we have 
> now added support for collations as defined in 
> <http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt>. 
> This involved a whole new section (7.5) and modification to the 
> text-match element.
> 
> The basic change was to eliminate the caseless attribute in text-match 
> and instead add a collation attribute that takes the name of one of the 
> supported collations on the server. With this, the text comparison 
> operation will follow the well defined rules of the collation.
> 
> The link to the draft is here:
> 
> <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-15.txt>
> 
> An HTML diff from the previous version is here:
> 
> <http://ietf.osafoundation.org/caldav/draft-dusseault-caldav-15-from-14.diff.html> 

Thanks.

I just read 7.5 (not the subsections), and it's a bit weird that the 
spec mandates normative behaviour for edge cases where a client violates 
MUST level requirements... Please be more conservative in throwing in 
RFC2119 keywords...

Best regards, Julian

Date: Mon, 18 Sep 2006 10:03:51 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] New draft

Hi folks,
Following the last IESG review there was push-back on i18n issues wrt text 
comparisons done in the calendar-query report. As a result we have now 
added support for collations as defined in 
<http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt>. 
This involved a whole new section (7.5) and modification to the text-match 
element.

The basic change was to eliminate the caseless attribute in text-match and 
instead add a collation attribute that takes the name of one of the 
supported collations on the server. With this, the text comparison 
operation will follow the well defined rules of the collation.

The link to the draft is here:

<http://www.ietf.org/internet-drafts/draft-dusseault-caldav-15.txt>

An HTML diff from the previous version is here:

<http://ietf.osafoundation.org/caldav/draft-dusseault-caldav-15-from-14.diff.html>

-- 
Cyrus Daboo