RE: DAV-Enabled field (was RE: A case for GETSRC)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Wednesday, March 06, 2002 8:25 PM
> To: DAV
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> ...
> >>    * the generated "resources" won't have the correct values
> for many live
> >>  properties (other than dav:source!!!), and will probably
> (your words) not
> >>  support dead properties
> >
> >Not having values is something different from not having
> "correct" ones. I
> >simply don't see a problem here.
>
> I think Eric mentioned that some of these values are required, so you
> can't not return them.

I have to not return them if they don't exist. I can't return the headers
upon HEAD or GET either. If you understand RFC2518 as saying that
DAV:getcontentlength MUST be returned any may not be an empty string, this
indicates that we need to fix RFC2518.

> >I think it is *also* common practice to replicate the source URL
> spaces (and
> >not to touch the output URL spaces at all). In which case there's no
> >problem.
>
> It is common because it is the only way to deploy DAV under the
> current spec.  It causes no end of confusion amongst people who are
> deploying/using DAV for the first time.  It is counter-intuitive, and
> is not really useful in most situations.

These are completely subjective arguments. Some people like the one
approach, some like the other.

> >  > Julian's other argument is that you might want to have
> existing clients be
> >  > able to edit the source just by pointing to some URL.  Well, without
> >  > understanding dav:source they won't know what the URL is to use
> >  > for the next
> >  > GET method.  So, clearly clients will need to be upgraded
> either to handle
> >  > Translate:/GETSRC or to handle the dav:source header.
> Existing clients
> >  > won't cut it, so I don't by this reasoning, anyway.
> >
> >Yes, clients and servers will need to be upgraded. Did I say otherwise?
>
> Someone claimed that Translate/GETSRC would require implementation
> changes.  Eric was just pointing out that implementations have to
> change anyway because of these very issues, therefore the argument is
> irrelevant.

Agreed, unless somebody claims that "adopting" the Translate header can be
done without breaking existing code.

Received on Wednesday, 6 March 2002 14:39:41 UTC