RE: Last call: range locking

Larry, it would appear that you only read the first part of the post
where I propose URL mangling. However that was a straw man proposal. The
second part of the post then proposes the use of a method which takes as
input a particular range type and provides a server generated URL in the
content-location header of the response. Thus the client does not
perform any kind of URL mangling. I have provided a fully copy of my
original post below, it can also be retrieved at
http://lists.w3.org/Archives/Public/w3c-dist-auth/msg00645.html.
				Yaron

Goal: To provide locking for defined subsections of a document

Problem: DAV only supports locking on URLs, as URLs are given to a
resource as a whole, DAV can not currently handle a partial lock

Solution: Give subsections URLs.

Example: Byte Ranges - A client searches for the attribute
"xssdfsyhw30rwfwofjslfihleihfsfe" which is a token meaning "I give you
permission to mangle the URL for this resource to point to a byte range
in a defined way, specifically, you may add a "#" followed by a number,
followed by a dash, followed by another number". The client then sends
http://foo/bar#12-23 in a lock request. The result is that bytes 12 to
23 are locked. Obviously the example doesn't provide all the semantic
requirements but it is just a taste of the underlying mechanism.

Problem: Mangling Overload. It is very nice and good to mangle a URL
w/permission from the server, but at some point the various mangling
mechanisms are going to run into each other.

Potential Solution: A byte range method called ByteHead =). A range
header is included to specify the byte range, although it can be used to
specify any arbitrary range such as chapter or page. The request-URI is
the request-URI of the resource. The response contains a
content-location header which is the URL pointing to the relevant range.
The rest of the response contains the same thing as a HEAD request done
on the URL contained in content-location.

Problem: Two round trips for every single lock request.

Solution: A convenience method which combines ByteHead with Lock, we can
call it LocksByte.

			Yaron

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Tuesday, March 04, 1997 8:42 PM
> To:	Yaron Goland
> Cc:	'dgd@cs.bu.edu'; w3c-dist-auth@w3.org
> Subject:	Re: Last call: range locking
> 
> (in reply to 26 Feb 1997 message re: range locking not used in
> Groupwise)
> 
> Having the server give the client permission to mangle URLs
> is a pretty ugly way to get your URLs mangled. Besides, what
> we've learned is that the very same server may have different
> requirements for different parts of its address space, and the
> permission-to-mangle scope is not easily characterized by
> URL patterns. (The realm of cookies isn't a good design to
> follow).
> 
> Because of this, rather than having the server give the client
> permission to do a particular kind of mangling, you're better
> off having the server return the mangled URL directly as the
> result of a request.
> 
> So, while your "Goal/ Solution" are OK ("give subsections URLs"),
> the example you gave (using a particular attribute to denote
> that a particular kind of URL-manging is OK) is not, or at least,
> is not in service of the WEBDAV goal of fostering interoperability
> between authoring clients and versioning servers.
> 
> Regards,
> 
> Larry
> 
> 
> -- 
> http://www.parc.xerox.com/masinter

Received on Wednesday, 5 March 1997 01:02:23 UTC