Re: Fielding on MOVE & COPY

>The reason why it can't do that is because we currently have no way for
>the client to "lend" its authentication credentials to the server such
>that the server could perform that action on behalf of the client.
>Again, this is only an issue in cross-server MOVE methods.

I wish this was a problem :-(

Unfortunately at present we simply don't have anything remotely like an 
authorisation scheme for the web. Neither BASIC nor DIGEST will really cut it 
for this application. That is hardly suprising since neither was designed with 
cross realm authorisation in mind. BASIC was an ad hoc hack and DIGEST was a 
cleanup job on BASIC which was compromised by the existing commitments made by 
BASIC.

I think that as a matter of principle the distributed authoring people should 
ignore the current Web authorisation mechanisms. They are simply inadequate for 
collaboration. Assume that the security framework will be extended to meet the 
needs of collaboration. If you don't you will find that what you can do will be 
so limited that it will scarcely be worth worrying about.


>Yes, it does have an advantage in terms of atomicity.  However, it might
>be better to just introduce a form of transaction support, since we
>already need that anyway.

Yes we need it, but a MOVE instruction is equivalent to "read-test-modify" in 
terms of atomic transactions. Its a building block from which much else can be 
built. 

I think that even if we put support for transaction management into the Web 
there will be a need for MOVE since Transactions are likely to be something 
supported only on high end servers built on top of file or object systems which 
provide native transaction support. I see MOVE as something that the UNIX 
servers can support without difficulty and without huge expense. 


>If people do choose to use a new header field for the list of source
>or destination URIs, then it is important to use a robust syntax.
>In other words, the URIs should be <bracketed> or "quoted" so that
>they are easily distinguished from adjoining commas or folding.

Agreed.


	Phill

Received on Friday, 6 September 1996 21:40:13 UTC