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

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:

>
> 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
>
>
> Julian wrote on 06/14/2005 04:38:11 AM:
>
>  >
>  > Lisa Dusseault wrote:
>  > >
>  > >
>  > > 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.
>  >
>  > 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.
>  >
>  > > 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.
>  >
>  > 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>.
>  >
>  > > 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
>  >
>  > 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
>  >