Subject: RE: ANNOUNCE: ACL draft to WebDAV working group last call

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 6 Oct 2003 11:09:09 -0700

This last call period ends tomorrow.  There have been a few questions:

what are the permissions on a bound resource
	--> This question appears to be answered - inherited permissions are
	not transitive
whether a principal resource is a HTTP resource 
	--> answered: yes
how the server maps from login to principal resource 
	--> answered: implementation dependent
suggestion to add write-collection
	--> no support voiced in response

I don't think any of these prevent the document from going forward after
last call finishes so if there is disagreement please raise it on the
acl list.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 23, 2003 1:17 PM
> To: [email-masked]; Webdav WG
> Cc: Ted Hardie; 'Jim Whitehead'
> Subject: ANNOUNCE: ACL draft to WebDAV working group last call
> 
> 
> 
> 
> It's time to last-call ACL again.  If you recall, ACL was 
> brought to last call a year ago.  IESG review brought up a 
> couple issues with how carefully delete privilege was defined 
> and suggested simplification among the server options 
> (particularly in the order-of-evaluation of ACEs).  These 
> changes have been made and we've now spent quite a long time 
> discussing those changes and other ideas.  I'm not aware of 
> any outstanding issues besides one nit in acl-restrictions 
> which Geoff probably already dealt with.
> 
> So, this begins a two-week period in which anybody can make 
> comments on the ACL draft.  After this period if we've only 
> found minor issues/nits, we'll resubmit it to the IESG.  I 
> don't know yet if that will involve another IETF last call so 
> I recommend you review ACL now.
> 
> Various formats available here: http://www.webdav.org/acl/ 
> Official draft location: 
> http://www.ietf.org/internet-drafts/draft-> ietf-webdav-acl-11.txt
> 
> Lisa
> 
> 
>

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 6 Oct 2003 20:16:32 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, October 06, 2003 8:09 PM
> To: 'Lisa Dusseault'; [email-masked]; 'Webdav WG'
> Cc: 'Ted Hardie'; 'Jim Whitehead'
> Subject: RE: ANNOUNCE: ACL draft to WebDAV working group last call
> 
> 
> 

(it has at least one HTTP URI, but can have other URIs as well)

> 	--> no support voiced in response

I may have missed this one: isn't this simply DAV:bind?

> last call finishes so if there is disagreement please raise it on the

Agreed.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 6 Oct 2003 18:23:50 -0400

Julian wrote on 10/06/2003 02:16:32 PM:

> > From: Lisa Dusseault
...
> I may have missed this one: isn't this simply DAV:bind?

The proposed "write-collection" was DAV:bind + DAV:unbind.
This is easily achieved by having the client just specify
DAV:bind and DAV:unbind, and so does not warrant its own
privilege.

> > last call finishes so if there is disagreement please raise it on the

+1

Cheers,
Geoff

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 6 Oct 2003 16:51:04 -0700

+1
  ----- Original Message ----- 
  From: Geoffrey M Clemm 
  To: Julian Reschke 
  Cc: 'Ted Hardie' ; [email-masked] ; [email-masked] ; Lisa Dusseault ; 'Webdav WG' ; 'Jim Whitehead' 
  Sent: Monday, October 06, 2003 3:23 PM
  Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call

  ...

  +1 

  Cheers, 
  Geoff 

------------------------------------------------------------------------------

  _______________________________________________
  acl mailing list
  [email-masked]
  http://mailman.webdav.org/mailman/listinfo/acl

---

From: Frank Lowney <[email-masked]>
Date: Mon, 6 Oct 2003 21:15:58 -0400

We use a Courseware Management System (CMS) called WebCT Vista which 
relies on the BEA WebLogic webserver and an Oracle DB.  One 
platform-specific problem that we've seen with WebDAV in this 
environment is that files uploaded via WebDAV from MacOS X machines 
using the OS-level WebDAV support is that the file arrives in two 
parts as per this report:

>  when I use the OS X built in WebDAV feature to upload files, a
>  "ghost" is created of the files I upload. For example, I uploaded a
>  file called rcurry.greece.doc.
>
>  This file is a 28 KB file on my computer. In the File Manager of
>  Vista it says the file I uploaded is 0Bytes and a second file,
>  ._rcurry.greece.doc was also created and is listed as being 82Bytes.

The explanation offered by WebCT support uses a reference to 
webdav.org as follows:

>In the MacOS every file has two components, a data fork and a 
>resource fork.  This extra file that you are seeing is not a bug 
>within Vista (in fact you would have this extra file in almost any 
>WebDAV connection when you are using the MacOS (X or otherwise). The 
>specifics of what is occurring here is very well explained in this 
>web page:
>
>http://www.webdav.org/goliath/help0.9/chaps/rezforks.htm
>
>I say that you would have this is "almost any" WebDAV connection 
>because Goliath, a WebDAV client for the MacOS does have a 
>preference which allows you to turn off the copying of the resource 
>fork over to a WebDAV server which will prevent this file from 
>showing up.

However, I am curious about whether this reasoning applies equally to 
MacOS X as it does to the preceeding operating system called MacOS 
Classic.

Can anyone here comment on the aptness of this "reason" for this 
phenomena.  After all, the built-in MacOS X facility for WebDAV does 
not exhibit these symptoms under Apache or WebSTAR webservers.  I was 
of the impression that MacOS X did not use forked files as Classic 
did.

-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
     Director, Electronic Instructional Services, a unit of the
     Office of Information and Instructional Technology,
     Professional Pages: http://www.gcsu.edu/oiit/eis/
     Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction 
more accessible.

Please note that my new e-mail address is: [email-masked]

---

From: Albert Lunde <[email-masked]>
Date: Tue, 7 Oct 2003 00:41:43 -0400

> of the impression that MacOS X did not use forked files as Classic 

MacOSX still supports the use of resource forks and Finder meta-data
(Type/Creator codes and a number of bits), it's just somewhat 
depreciated going forward. Applications ported to OSX using the 
Carbon Framework are more likely to use them for backwards-compatability,
though that's not a hard-and-fast rule. "Bundles" out of the NeXT
heritage, are the flat-file construct that is trying to superceed
resource forks, etc.

HFS+ has native support for Unix permissions, Finder-like attributes,
and resource forks. I think the hack you cite is invoked to support them
on some other file systems.  However, examination of the mkisofs
man page reveals the existence of a dozen or so incompatible schemes
for supporting resource forks and Finder meta-data on non-Apple filesystems.
so a lack of consistency is hardly surprising, I'm afraid...

---

From: Albert Lunde <[email-masked]>
Date: Tue, 7 Oct 2003 17:45:31 -0400

On Tue, Oct 07, 2003 at 11:30:21AM -0400, Frank Lowney wrote:
> Albert,
> 
> I appreciate your reply and your point about carbon apps such as 
> Goliath having to support legacy file systems is well taken but our 
> issue was with the use of the MacOS X built-in WebDAV client, a 
> native (coco) app I believe.  This client does well with Apache and 
> WebSTAR V but not with BEA Weblogic.  We haven't yet tested other 
> native coco apps such as Adobe GoLive and Macromedia Dreamweaver but 
> I would imagine that they are also quite independent of and do not 
> use forked files.
> 
> Are you saying that the "hack" is in BEA Weblogic or elsewhere?  If 
> it's in BEA WebLogic, then their hack is breaking a 
> standards-compliant client.

1) I am saying OS X still supports resource forks at the file system level,
independent of statements about specific applications.

2) Cocoa applications can do resource folks too, they are just less likely
to need do so for their own sake. But Apple is probably continuing
to build resource fork support into GUI file manipulation tools
regardless of what development tools they are written with.

(The Carbon/Cocoa divide is getting more fuzzy over time, too.)

3) The "hack" is a matter of how well-integrated resource fork
support is in a given filesystem: it's a low-level feature
of HFS+, but it's a more visible layer on top of some other
file systems.

The problem with being "standards-compliant" in this context, is there
are so many options to choose from: a number of defacto ways to 
represent resource forks, plus the options of throwing away resource forks
and/or finder metadata entirely.

I think IETF standards like HTTP and WEBDAV are silent about
Apple-specific file system features like resource forks.

Throwing away resource forks plays nicely with the non-Apple
web world, but starts get messy if you mix general purpose
file servers with web servers, as I think Apple has done with
its .Mac service.

I think the prior usage of this particular representation of resource
forks on Mac OSX was with UFS and NFS filesystems.

I don't claim to be an expert on this subject so take this with
some reservations.