Proposal for response URLs in Multi-Status: always based on Request-URI

We've discussed the allowability of relative URLs in the 'href' element 
in the 'response' elements of Multi-Status responses.  I'll call each 
of these a "response URL" for now.  I believe our conclusion was that 
in response to PROPFIND, response URLs which are relative URLs MUST be 
relative to the Request-URI, and those which are absolute MUST begin 
with the Request-URI (exactly the same scheme, host, port and path).

For MOVE and COPY, one could consider relative URLs as being resolved 
against the Destination header instead of the Request-URI, but I don't 
believe that anybody does this.  One could also imagine seeing absolute 
URLs that were part of the Destination namespace rather than the 
Request-URI namespace, but again, I don't believe that anybody does 
this.

Thus, are there any objections if we treat all Multi-Status responses 
the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH?  
That the response URLs MUST always be in the Request-URI namespace, and 
if relative, be resolved against the Request-URI?

Would making this requirement a MUST for all Multi-Status responses 
break any extensions using Multi-Status -- or do we limit the 
requirement to Multi-Status responses to methods defined in RFC2518bis 
only?

Lisa

Received on Sunday, 4 December 2005 17:01:23 UTC