FYI, there will be a WebDAV Working Group meeting at the Vienna IETF meeting (IETF-57). Currently the meeting is scheduled for Tuesday, July 15, 2003, in the afternoon (this day/time is subject to change). For more information on the IETF-57 meeting, including how to register, and it's exact location: http://www.ietf.org/meetings/IETF-57.html - Jim
The cutoff date for submitting new drafts of existing documents before the Vienna meeting is June 30 (and the cutoff for new drafts is a week earlier). Let's use this as a deadline to try to get our various documents updated so we can discuss them and/or progress them: - ACL - RFC2518 bis - Bindings - Search - Quota In addition, our charter is sadly out of date. If somebody is interested in taking a stab at bringing that up-to-date it would be greatly appreciated. Lisa > -----Original Message----- > From: w3c-dist-auth-request <at> w3.org > [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of Jim Whitehead > Sent: Thursday, June 05, 2003 11:48 AM > To: WebDAV > Subject: Meeting at IETF-57 in Vienna > > > > FYI, there will be a WebDAV Working Group meeting at the > Vienna IETF meeting (IETF-57). Currently the meeting is > scheduled for Tuesday, July 15, 2003, in the afternoon (this > day/time is subject to change). >(Continue reading)
The IESG has received a request from the WWW Distributed Authoring and Versioning Working Group to consider WebDAV Ordered Collections Protocol <draft-ietf-webdav-ordering-protocol-08.txt> as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2003-6-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-08.txt
Chris, You are right -- the last call draft doesn't try to specify server maintained orderings. Looking at your draft, it seems to apply to server-side sorting, which may have it's place in WebDAV SEARCH [1]. Note that the plan for WebDAV SEARCH is to make use of collations as defined in XSLT 2.0 and XQuery, once they become ready. So you may want to check how your work fits into that framework as well. As far as I understand, there's currently nobody working actively on WebDAV ordered collections with server-maintained orderings. So I don't think it's a good idea to delay publication of this work to cover something nobody currently is interested in. Regards, Julian [1] <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman <at> Sun.COM] > Sent: Saturday, June 07, 2003 4:13 AM > To: iesg <at> ietf.org > Cc: w3c-dist-auth <at> w3.org; julian.reschke <at> greenbytes.de; ejw <at> cse.ucsc.edu > Subject: Re: Last Call: WebDAV Ordered Collections Protocol to Proposed > Standard(Continue reading)
Hi. Ted Hardie has raised the following issue with the current draft of the ordering protocol... In section 6.1 we say: "Note to implementors: this specification does not mandate a specific implementation of MOVE operations within the same parent collection. Therefore, servers may either implement this as a simple rename operation (preserving the collection member's position), or as a sequence of "remove" and "add" (causing the semantics of "adding a new member" to apply). Future revisions of this specification may specify this behaviour more precisely based on future implementation experience." The issue here is that *if* we don't want to mandate a specific server behaviour, we should at least give client developers some guidance about how to achieve what they want (in this case a simple "rename" within the same parent collection where the ordering -- if present -- is preserved). The pseudo-code for this would be: 1) PROPFIND/Depth 1 on parent collection, getting DAV:ordering-type 2) if DAV:ordering-type not present or == "dav:unordered", just proceed as before 3) determine position of member to be renamed (such as "first" or "after x")(Continue reading)
Accidentally caught by the spam filter. I have added "geoffrey.clemm <at> us.ibm.com" to the accept2 list. - Jim -----Original Message----- From: Geoffrey M Clemm [mailto:geoffrey.clemm <at> us.ibm.com] Sent: Thursday, June 12, 2003 6:15 AM To: WebDAV Subject: [Moderator Action] RE: Consideration of WebDAV Ordered Collections Protocol as Proposed Standard Adding that is fine with me. Cheers, Geoff w3c-dist-auth-request <at> w3.org wrote on 06/12/2003 06:59:38 AM: > > Hi. > > Ted Hardie has raised the following issue with the current draft of the > ordering protocol... > > In section 6.1 we say: > > "Note to implementors: this specification does not mandate a specific > implementation of MOVE operations within the same parent collection.(Continue reading)
Hi all, I am wondering if somebody can reference me a practical statistic of comparing the HTTP functionality to the WebDAV functionality with regard to remote Web authoring. I'm especially interested about the rate of speed, security, and flexibility. Any thing more is most welcome. Thanks in advance for your help. Regards, Bita.
Bita, What do you mean by comparing the HTTP functionality to the WebDAV functionality? WebDAV extends HTTP in order to do proper authoring, so there is no real functionality comparison based on authoring. HTTP doesn't do the authoring functions that WebDAV adds, that's why WebDAV had to add these fucntions. Since WebDAV extends HTTP: - they both have exactly the same theoretical speed/flexibility capabilities for downloading documents and uploading documents (these are the most common HTTP actions that are also common WebDAV actions) - they have exactly the same security features One could imagine doing performance comparisons between WebDAV functionality and, for example, the Microsoft FrontPage extensions which do many of the same functions. Or one could compare a WebDAV authoring site to a site using HTML forms for authoring (like Yahoo PageWizards). Perhaps I've misunderstood your question. Lisa > -----Original Message----- > From: w3c-dist-auth-request <at> w3.org > [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of B. Shadgar > Sent: Tuesday, June 17, 2003 12:18 PM > To: WebDAV > Subject: WebDAV effeciancy(Continue reading)
Lisa Dusseault wrote: > Bita, > > What do you mean by comparing the HTTP functionality to the WebDAV > functionality? WebDAV extends HTTP in order to do proper authoring, so > there is no real functionality comparison based on authoring. HTTP doesn't > do the authoring functions that WebDAV adds, that's why WebDAV had to add > these fucntions. > > Since WebDAV extends HTTP: > - they both have exactly the same theoretical speed/flexibility > capabilities for downloading documents and uploading documents (these are > the most common HTTP actions that are also common WebDAV actions) > - they have exactly the same security features > > One could imagine doing performance comparisons between WebDAV functionality > and, for example, the Microsoft FrontPage extensions which do many of the > same functions. Or one could compare a WebDAV authoring site to a site > using HTML forms for authoring (like Yahoo PageWizards). > > Perhaps I've misunderstood your question. > > Lisa Lisa, I haven't expressed my question correctly - sorry. By WebDAV and HTTP, in fact I meant comparing the process of communication between the WebDAV servers and(Continue reading)
B. Shadgar wrote: >[...] many functionality of the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you >mentioned like Microsoft FrontPage). So if the security is the same and if the speed may be low (not sure), why would the user choose WebDAV rather HTTP? > I'm actually implementing a SOAP-WebDAV proxy service that provides WebDAV functionality to clients that do not speak WebDAV, yet have a HTTP stack and can do XML processing (and, hence, SOAP as well). I'll be running some performance tests and can send them to you when they're available if you're still interested. Ignoring the performance issue momentarily, however, there are several reasons one should use WebDAV over HTTP POST, SOAP, and cetera. Without digressing into a full discussion of architectural styles and ideals not appropriate for this forum, I'll summarize what I feel is the main consideration. One of the reasons that the web has been so successful is that, at the protocol level, there is a standardized interface for interacting with web resources. WebDAV has extended the HTTP protocol to provide functionality necessary for distributed and collaborative authoring. SOAP breaks this genericity of interface by allowing arbitrary methods with arbitrary functionality to be exposed as a web service. So, while it is possible to provide WebDAV-like functionality using SOAP, there is no guarantee of interoperability between clients and servers taking this approach. Another, somewhat lesser, concern has to do with the opacity of URLs. A SOAP based web service that provides WebDAV functionality is essentially manipulating web resources indirectly; behind the scenes, as it were, so the resource you would address a PROPPATCH to isn't the same resource that you would address a GET to, even though you are intending(Continue reading)
RSS Feed2 | |
|---|---|
3 | |
3 | |
1 | |
2 | |
1 | |
3 | |
2 | |
14 | |
14 | |
2 | |
11 | |
1 | |
9 | |
21 | |
9 | |
16 | |
2 | |
3 | |
3 | |
17 | |
29 | |
39 | |
3 | |
5 | |
6 | |
14 | |
9 | |
21 | |
31 | |
6 | |
4 | |
17 | |
16 | |
19 | |
16 | |
40 | |
14 | |
116 | |
5 | |
11 | |
2 | |
4 | |
30 | |
20 | |
1 | |
8 | |
44 | |
40 | |
27 | |
24 | |
45 | |
20 | |
58 | |
27 | |
24 | |
27 | |
4 | |
54 | |
22 | |
28 | |
31 | |
18 | |
122 | |
234 | |
462 | |
695 | |
465 | |
453 | |
38 | |
33 | |
77 | |
52 | |
66 | |
28 | |
42 | |
162 | |
154 | |
190 | |
104 | |
40 | |
124 | |
28 | |
80 | |
128 | |
44 | |
82 | |
93 | |
34 | |
43 | |
60 | |
104 | |
153 | |
82 | |
71 | |
61 | |
77 | |
24 | |
53 | |
263 | |
106 | |
92 | |
19 | |
67 | |
243 | |
230 | |
42 | |
129 | |
87 | |
86 | |
75 | |
1 |
