RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Saturday, May 11, 2002 4:17 AM
> To: Jason Crawford
> Cc: Lisa Dusseault; Webdav WG (E-mail)
> Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> > I'd like to mark it resolved that we will remove the source property.  I
> > would leave it up to our memories to bring the topic up again
> in the next
> > version of WebDAV if we value it.
> >
> > The thinking is...
> >
> > The source property is good.
> > But it's under specified and needs work, no interoperability has been
> > determined, and no one has been yelling for it.  If we remove
> it from the
> > spec now, the few implementations that support it can remove
> that support
> > and thus provide us a clean slate to work from when we take
> another stab
> > at
> > the source property.
>
> If the source property is removed, then how will the server respond to a
> client that attempts to use DAV on a resource that is not DAV authorable
> but is derived from other sources?  What is the interoperability
> mechanism?

I would assume that all authoring-type requests (PUT, PROPPATCH) will fail
(403?).

The issue that we have to resolve is that RFC2518 *does* specify a property
that signals source resources, however the mechanism is underspecified, and
because of that (and other reasons) we don't have interoperable
implementations of it.

For RFC2518 to move forward, it will either prove interoperability, or drop
the feature.

My suggestion is to drop {DAV:}source in RFC2518, then to define a new live
property in a separate RFC (this wouldn't block RFC2518's progress).

> I would prefer a source Link solution, myself, since that can be supplied
> in a normal HTTP error response.

So you'd prefer it to my an HTTP response header? We'd still need a PROPFIND
compatible live property that a user agent can use to discover the source
directly (without having to try to modify the resource).

> In my opinion, WebDAV needs to solve this issue before progressing on
> the standards track.  It cannot simply remove it without abandoning the
> pretense that it handles Web authoring.

I don't think I can agree here. RFC2518 has proven useful without anybody
supporting this property, so it's current state shouldn't block any progress
on RFC2518.

Received on Saturday, 11 May 2002 11:49:05 UTC