Re: DAV:read privilege and browsing

   Right.  This is how, for example, a typical UNIX file system works.

	-wsv

On Nov 30, 2006, at 8:57 AM, Julian Reschke wrote:

> Basically, if the server exposes the names of children that the user  
> doesn't have access to, security works in a different way. For  
> instance, users will have to move resources they don't want to be  
> visible into a specific folder, and deny read access to that folder  
> as well.

Re: DAV:read privilege and browsing

On Nov 30, 2006, at 12:32 AM, Julian Reschke wrote:

>>   I obviously shouldn't be able to read (all of?) the child's  
>> properties, but there is some merit to wanting to be able to see  
>> that the child's URI is present, even if I can't read the child's  
>> properties
>
> Right.
>
>> or content.  I might even want to expose the DAV:resource-type  
>> property so you can tell if it's a collection, etc.
>
> I don't think RFC3744 would allow the latter, even though I would  
> consider it harmless...

   My read leads to the same conclusion.

>>   This also nominally affects GET, when I'm rendering a directory  
>> listing of the parent.  I'd like to show all children, but if you  
>> aren't allowed to see them in PROPFIND, it makes sense that they  
>> should be hidden from the rendered listing as well.
>
> Correct. I personally think they should appear in both, potentially  
> marked up as non-accessible (greyed out...).

   OK, that's where I was heading.  Cyrus had the same concern as  
Kevin; that the file name may itself contain sensitive information,  
and basically cited the same "FIRE-KEVIN.doc" example.    I'm  
willing to live with that, though; there is plenty of precedent there  

Re: draft 16 vs issue bz238

Yeah, the section reference is wrong, I can fix that.  I'll continue  
to use my own wording for the rest as it's not quite true that  
there's two different formats (I can think of three: empty body,  
'error' body or 'multistatus').

Lisa

On Nov 28, 2006, at 5:36 AM, Julian Reschke wrote:

>
> From <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi? 
> id=238#c2>:
>
> Draft 16 added:
>
> "If a server attempts to make any of the property changes in a  
> PROPPATCH request (i.e. the request is not rejected for high-level  
> errors before processing the body), the response MUST be a Multi- 
> Status response (Section 13)."
>
> That's incorrect. The whole point is that in this case, the Multi- 
> Status reponse format is *not* the one defined in Section 13. So  
> please replace with the previously suggested text:
>
> "The response to a PROPPATCH request can be in two different  
> formats: should the server reject the request altogether (because  
> of missing access rights, failed conditional headers, malformed  
> request syntax, etc.), the status SHOULD be non-2xx HTTP status. On  
> the other hand, if the server did attempt the property  

Re: draft 16 vs issue bz238

Lisa Dusseault schrieb:
> 
> Yeah, the section reference is wrong, I can fix that.  I'll continue to 
> use my own wording for the rest as it's not quite true that there's two 
> different formats (I can think of three: empty body, 'error' body or 
> 'multistatus').

So then why does Section 13 say 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-16.html#rfc.section.13>):

---
A Multi-Status response uses one out of two distinct formats for 
representing the status:

    1. A 'status' element as child of the 'response' element indicates 
the status of the message excecution for the identified resource as a 
whole (for instance, see Section 9.6.2). Some method definitions provide 
information about specific status codes clients should be prepared to 
see in a response. However, clients MUST be able to handle other status 
codes, using the generic rules defined in Section 10 of [RFC2616].
    2. For PROPFIND and PROPPATCH, the format has been extended using 
the 'propstat' element instead of 'status', providing information about 
individual properties of a resource. This format is specific to PROPFIND 
and PROPPATCH, and is described in detail in Section 9.1 and Section 9.2.
---

??

Best regards, Julian

Re: draft 16 vs issue bz238

These two statements are not inconsistent.  There are two formats for  
Multi-status responses; there are at least three legal formats for  
PROPFIND responses.  A PROPFIND response is not always a Multi-Status  
response (in the case of errors).

Lisa

On Dec 1, 2006, at 11:22 AM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> Yeah, the section reference is wrong, I can fix that.  I'll  
>> continue to use my own wording for the rest as it's not quite true  
>> that there's two different formats (I can think of three: empty  
>> body, 'error' body or 'multistatus').
>
> So then why does Section 13 say (<http://greenbytes.de/tech/webdav/ 
> draft-ietf-webdav-rfc2518bis-16.html#rfc.section.13>):
>
> ---
> A Multi-Status response uses one out of two distinct formats for  
> representing the status:
>
>    1. A 'status' element as child of the 'response' element  
> indicates the status of the message excecution for the identified  
> resource as a whole (for instance, see Section 9.6.2). Some method  
> definitions provide information about specific status codes clients  
> should be prepared to see in a response. However, clients MUST be  
> able to handle other status codes, using the generic rules defined  
> in Section 10 of [RFC2616].

Re: Draft -16 out now

On Nov 29, 2006, at 5:00 AM, Julian Reschke wrote:

>
>
> Issue 244: <http://ietf.osafoundation.org:8080/bugzilla/ 
> show_bug.cgi?id=244> (lock creator vs owner)
>

Thought I might like to see this fixed, when I looked at this with my  
chair hat on, it did not seem like failing to fix this was going to  
have a significant chance of causing non interoperable implementations

> Issue 251:
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>  
> (lock root being a URI, not a resource)

On this one, it seems that the issue occurs in many places in the  
text and is one of the main areas of unresolved consensus around  
locking. If you think we should fix it in this one place using your  
proposed text, I see no objections to that and glad to do it. If you  
want it fixed everywhere, I think that will require reopening the  
unresolved issues on locking and I view that as a 6 month to 2 year  
project.

I also agree the use of section 13 instead of 9 in bug 238 is a bug.

I'm trying to get my head around the "dav: error response" thread.

>

Draft -17 with three changes

I've submitted a new draft based on comments on -16.  XML and text  
versions at http://ietf.osafoundation.org/xythoswfs/webui/webdav/ 
rfc2518bis until the version submitted to the Internet-Drafts  
repository goes up.

Changes section for this version:

G.12.  Changes in -17

    Change reference for PROPFIND MultiStatus response format from
    section 15 to section 9.2.1

    Add another "except" clause to statement requiring pre/postcondition
    codes to appear in 'error'

    Remove requirement to use TLS -- back to requiring channel to be
    secure.

Lisa

Re: Draft -16 out now

Cullen Jennings schrieb:
>> Issue 244: 
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=244> 
>> (lock creator vs owner)
>>
> 
> Thought I might like to see this fixed, when I looked at this with my 
> chair hat on, it did not seem like failing to fix this was going to have 
> a significant chance of causing non interoperable implementations

Yes, it would. That's why it's one of the significant changes from RFC2518.

Existing clients rely on the fact that DAV:owner is whatever they passed 
in in the LOCK request, not what "creator" (which is the authenticated 
principal who did the LOCK).

That's something completely different. If we even don't get simple 
things like this right, we really should stop.

>> Issue 251:
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251> 
>> (lock root being a URI, not a resource)
> 
> On this one, it seems that the issue occurs in many places in the text 
> and is one of the main areas of unresolved consensus around locking. If 
> you think we should fix it in this one place using your proposed text, I 
> see no objections to that and glad to do it. If you want it fixed 
> everywhere, I think that will require reopening the unresolved issues on 
> locking and I view that as a 6 month to 2 year project.

Re: Draft -16 out now

Re: Draft -16 out now