Subject: Re: redirect references protocol: automatic update

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 7 Jan 2004 18:16:36 -0500

I don't see why we couldn't require this (redirects created by some other
mechanism don't have to act the same way as redirects created by 
MKREDIRECTREF.

So we could/should say that the value of a redirectref changes only when
it is explicitly updated by a PROPPATCH of the DAV:reftarget property,
and not as a side-effect of some other operation such as MOVE.

Cheers,
Geoff

Julian on 01/05/2004 07:29:23 AM:
> Regarding issue the last call (year 2000) issue:
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-
> protocol-latest.html#rfc.issue.lc-57-noautoupdate>
> 
> "Add language to forbid servers from automatically updating redirect 
> resources when their targets move."
> 
> I don't think we can forbid that. This spec consists of (a) 
> clarifications of how a server that supports redirects should behave for 

> specific WebDAV methods, and (b) extensions to explicitly create them 
> (or to apply a method to the redirect itself). As such, we shouldn't add 

> any requirements that HTTP doesn't add. What we could do is (1) note why 

> auto-update may be a bad idea, and possibly (2) define that redirects 
> created by MKREDIRECTREF should not behave that way (or alternatively 
> define more specific resource types).

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Jan 2004 13:46:41 +0100

Geoffrey M Clemm wrote:
> One possibility is to have an additional argument to MKREDIRECTREF,
> e.g. DAV:stable, that means that the client forbids the server from
> auto-updating the reference.  A client that doesn't care would leave
> off this parameter, and the server would do what it wanted, while a
> client that cared would specify this parameter, and a server that doesn't
> support stable redirectref's would fail the request.

Yep.

The thing I'm currently unsure about is how to model the different 
properties of a link (stability, response status). Several approaches 
come to mind:

1) different resource types (redirect-301, redirect-302, ...)

2) one resource type with extension elements, such as

   <redirect-ref><status301/><stable/></redirect-ref>

3) one simple resource type with the remaining information moved into 
separate properties (like it was proposed for the status).

Regards, Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 9 Jan 2004 07:30:33 -0500

Cheers,
Geoff

Julian wrote on 01/07/2004 06:43:30 PM:

> That's exactly what I *don't* want to say, because in reality there are 
> servers that have a concept of redirect reference resources, *although* 
> they auto-update their target. This is completely consistent with 
> RFC2616, and I don't see why the redirect spec can or should *forbid* 
> that. I do agree that this behaviour may be confusing, and that it makes 

> sense to discourage it, but we can't change what's already there...
> 
> Julian
> 
> 
> --

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Jan 2004 13:29:23 +0100

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html#rfc.issue.lc-57-noautoupdate>

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 9 Jan 2004 08:45:19 -0500

I prefer (3), a simple singe resource type, with the other information 
moved into a set of properties.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jan 2004 00:43:30 +0100

Julian

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 09 Jan 2004 09:12:35 -0800

I also think that the third option would be best.

Elias

Geoffrey M Clemm wrote:

>>>client that cared would specify this parameter, and a server that 
>>>      
>>>
>doesn't
>  
>