Subject: WGLC draft-ietf-webdav-redirectref-protocol-12

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Jun 2005 18:01:13 -0700

I would like to start working group last call

http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-1
2.txt

This WGCL will end on July 4th so please have your comments emailed to this
list before then.

Thank you, Cullen

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 13 Jun 2005 19:07:18 -0700

The main flaw in the REDIRECT proposal is that there is not enough in 
the way of plans to implement it.  Without a set of independent 
implementors around to review it, I fear it's too complex or has missed 
key interoperability issues. 

To be clear, I do understand that the Web needs and uses redirects, and 
I see that administrators do create them and that browsers follow 
redirect status codes.  I'm arguing that there isn't a clear need for 
interoperable authoring of redirect resources, or if there is, it's not 
met by this specification.  Implementors might tell us, for example, 
that they don't need the ability to modify a redirect (why not just 
recreate) or that they'd prefer something which could handle redirecting 
URLs via pattern matching to another set of calculated URLs.

There seems to be one organization that implements REDIRECT authoring in 
a potentially-interoperable way -- I believe that's Julian's 
organization. I think that's great, and even better that they're 
interested in publishing the way they do it so that others can do the 
same.  I just don't believe that meets the bar for a standards-track 
RFC, because we've learned in the IETF that actual implementor review is 
very important to writing good, clear, simple standards that people need.

OSAF-specific stuff: We do not have plans to implement redirect in Cosmo 
or Chandler (server or client), neither to create redirects, allow them 
to be created, or add logic to allow for redirects existing on other 
WebDAV servers.  We're more interested, potentially, in using bindings.

Lisa

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 13 Jun 2005 20:59:25 -0600

Agree.  Plus, there does exist a way, that, while being a hack, does work,
and is interoperable:

<META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.example.com/">

-- 
Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jun 2005 10:39:00 +0200

> <META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.example.com/">

So how do you do that for a Word document, a PDF or a WebDAV collection?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jun 2005 10:46:39 +0200

Lisa Dusseault wrote:
> ...

Forgot to mention: actually it *adresses* interoperability issues, 
because redirect-type resources already exist on the Web, but RFC2518 
fails to describe how to handle them (at least) in PROPFIND responses.

Authorability may not be as important, but discovery certainly is. 
Today, Apache/moddav just hides redirects from WebDAV clients. I think 
this is a problem that needs to be solved.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jun 2005 10:38:11 +0200

> key interoperability issues.

I do agree that there seems to be more interest in BIND than REDIRECT. 
On the other hand, I disagree that because of this it can't start at 
"Proposed" (as Jim W. pointed out some time ago in a similar dicussion 
for BIND).

If the working group feels that it's too early to go to "Proposed", I 
think "Experimental" would make sense. It would preserve the work that 
has been done; and if at a later point of time more implementations 
appear, it can be rev'd up.

> URLs via pattern matching to another set of calculated URLs.

The ability to modify was added based on a Last-Call comment in 2000, 
and the WG decided to accept it. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html#lc-58-update>.

> organization. I think that's great, and even better that they're 

It's SAP (first time I've heard it called "Julian's org", but that 
sounds nice :-). As a matter of fact, the Xythos client implements some 
aspects of the protocol as well (discovery but not authorability).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 14 Jun 2005 10:48:32 -0700

I think that hiding redirects from authoring clients may be a perfectly 
good and reasonably interoperable thing to do.  It depends on two 
things: the model and the need.

The model that REDIRECT has is very pure -- that a URL that produces a 
redirect is a resource.  That's not the only model, however.  An 
implementor (client or server) could have a model where a URL that 
produces a redirect does *not* point to a resource, just like a URL that 
produces a 404 does not have an associated resource.  That model is 
already reflected in software like mod_rewrite, a module which is quite 
incompatible with REDIRECT.  The "redirect is not a resource" model 
could still support authorability, for example by adding properties to 
collections, and the properties could contain redirect rules. 

The "need" is the practical concern which we've already discussed, but 
I'd add that if we have a way to author redirects that is incompatible 
with mod_rewrite and the way administrators actually need to create 
redirect rules, then we may not have even solved the theoretical need.

The fact that SAP (aka Julian's org) implements them as resources is in 
fact very suggestive.  If that's the model you thought of, perhaps it's 
a better model for interoperability, a more WebDAV-suited model.  So now 
we're back to wanting other implementations to validate that model.

Lisa

Julian Reschke wrote:

>> implementors around to review it, I fear it's too complex or has 
>> missed key interoperability issues.
>> ...
>
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jun 2005 19:56:17 +0200

> things: the model and the need.

So what do you expect to happen when a client attempts a PUT on one of 
these URIs?

A redirect? A new resource being created? If the resource is indeed 
being created, will it actually be visible, or will the rewrite logic 
eclipse it?

This is the sort of interop problems we have today.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 16 Jun 2005 08:17:27 -0400

This is a very simple subject area, but there are some
choices to be made, and without a standard to define a common way,
we'll get folks just rolling their own with incompatible semantic
details (as is being done now).

So unless there are some actual technical problems with the REDIRECT
draft, I believe the current REDIRECT draft should go to "Proposed",
to address the interoperability in this area that already has arisen
due to the lack of a standard for how to author redirect references.

In this case, since there aren't any subtle technical issues/obstacles
to be addressed, and we just need a common convention, I think it is
appropriate for the draft standard to drive the implementations, rather
than the other way round.  In particular, the issue of authoring redirect
references isn't critical enough for folks to modify their current 
mechanisms to make them interoperable, until there is a draft standard
that defines how to do so.

Cheers,
Geoff

> > implementors around to review it, I fear it's too complex or has 
missed

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Jun 2005 08:07:46 -0700

Are there any other Web or WebDAV servers that allow redirects to be 
authored over any kind of protocol or service?  The only things I'm 
aware of already:
  - Joe's hack which is a client-to-client communication that is ignored 
by the server, so unlikely to be replaced by server logic
  - Web server configuration done by administrators, which isn't really 
itself a protocol or service although there might be something like SSH 
or FTP involved, also unlikely to be replaced because it's what 
administrators do for many other chores as well (and because REDIRECT 
may not solve the entire need)

If there are other approaches, I'm unaware of them, and it would help 
to know.  But if these are the only cases than I have a different 
evaluation of whether implementors will change current mechanisms.

Lisa

On Jun 16, 2005, at 5:17 AM, Geoffrey M Clemm wrote:

>  >  > ...

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Jun 2005 09:37:49 -0700

At 8:17 AM -0400 6/16/05, Geoffrey M Clemm wrote:
>than the other way round.

Just as a quick clarification, am I right that you mean you want
the current draft, as a Proposed Standard, to guide implementations?
Because of the usual draft-vs.-Draft Standard, I could read your
message to mean "wait until the Draft Standard conditions are met",
and it seems safer to confirm your intent.
			regards,
				Ted Hardie

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 16 Jun 2005 12:41:54 -0400

You are correct that I intended to suggest that the current draft be
adopted as a Draft Standard, to guide implementations.

Sorry about the ambiguous wording, and thanks for the clarification!

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jun 2005 21:52:56 +0200

Lisa Dusseault wrote:
> authored over any kind of protocol or service? The only things I'm aware 
> of already:
> If there are other approaches, I'm unaware of them, and it would help to 
> know. But if these are the only cases than I have a different evaluation 
> of whether implementors will change current mechanisms.

Lisa,

I don't think it's relevant whether implementors will *change* current 
mechanisms. Why would they? The question is whether there's a use case 
for a HTTP-client driven mechanism, which could be implemented *in 
addition* to what the server already does.

Looking at Apache/moddav, it seems that MKREDIRECT and UPDATEREDIRECT 
could be implemented in mod_alias (adding and updating entries in 
.htaccess, for example).

It's a bit unclear to me what exactly your point is. Yes, server admins 
can already author redirects, so there are other ways to create these 
redirects than HTTP. The same could be said about WebDAV, so why did we 
bother defining that?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Jun 2005 13:13:50 -0700

> It's a bit unclear to me what exactly your point is. Yes, server 
> admins can already author redirects, so there are other ways to create 
> these redirects than HTTP. The same could be said about WebDAV, so why 
> did we bother defining that?
>

Because there was a clear need for client interoperability in the 
general case of authoring Web content: several volunteer editors each 
from different possible implementors, several other participants who 
were also implementors.  It wasn't a large community of implementors 
(not compared to other WGs I've participated in, like SIP) but it was 
large enough to make the work not only clearly useful but also 
validated by more than one implementation model and by a set of use 
cases that mattered to more than one implementation.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jun 2005 22:52:16 +0200

Lisa Dusseault wrote:
> large enough to make the work not only clearly useful but also validated 
> by more than one implementation model and by a set of use cases that 
> mattered to more than one implementation.

I think there is clearly a need for discovery of redirects, that is 
clarifications about the relation between redirects and WebDAV's 
extensions. Today, the behaviour of servers that have redirects inside 
WebDAV collections is unspecified, and clients *do* expose strange 
behaviour because of that.

Of course we can argue about whether we need a standard protocol to 
*author* redirects. At the end of the day, the question should be "is 
this harmful?" or "is it useful?". IMHO it's not harmful at all, because 
nobody is forced to implement it. But it is certainly useful, because it 
  gives implementors a well-defined protocol that they *can* implement 
instead of coming up with proprietary extensions.

So is the lack of server support for HTTP-authorable redirects caused by 
the fact nobody needs it, or is it simply because implementors actually 
wait for this WG to actually finish and publish the spec?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Jun 2005 14:00:02 -0700

I don't really know what's causing the lack of implementor 
participation in redirects -- it could be total lack of interest or 
simply "wait and see".  But as far as I can tell there is a difference 
between the level of interest in redirect and the level of interest in 
bind and quota, which both do seem to have the minimum amount of 
implementor interest.

Lisa

On Jun 16, 2005, at 1:52 PM, Julian Reschke wrote:

>>> admins can already author redirects, so there are other ways to 
>>> create these redirects than HTTP. The same could be said about 
>>> WebDAV, so why did we bother defining that?
>>>
> this harmful?" or "is it useful?". IMHO it's not harmful at all, 
> because nobody is forced to implement it. But it is certainly useful, 
> because it  gives implementors a well-defined protocol that they *can* 
> implement instead of coming up with proprietary extensions.
>
> So is the lack of server support for HTTP-authorable redirects caused 
> by the fact nobody needs it, or is it simply because implementors 
> actually wait for this WG to actually finish and publish the spec?
>
>
> Best regards, Julian
>

---

From: John Baumgarten <[email-masked]>
Date: Mon, 27 Jun 2005 09:09:10 -0700

All-

After reviewing this draft, I have decided that the protocol is too  
complex for our needs with .Mac.  In particular, the failure of  
locking methods that contain redirected resources would confuse our  
clients.  Instead, we have decided to implement a simpler redirect  
capability via a custom property (not a WebDAV resource type) that is  
only activated when indicated by the client request.

Given this decision, I will not be able to provide specific feedback  
on the draft.

-Jake

JS "Jake" Baumgarten
.Mac Backend Server Engineering
408-974-0043
De Anza 6 #202
[email-masked]