Re: Optional Backpointers (for the last time)

At 07:15 AM 12/18/98 PST, Slein, Judith A wrote:
>In Orlando we discussed optional backpointers again.  My impression was that
>very few people really care about this issue, and those who do care were
>unable to reach consensus.  Consequently, I am proposing to remove
>backpointers from the specification unless I hear strong and numerous voices
>of protest.

Well, here's a strong, though solitary, voice of protest.  Since I
appreciate brevity, so I'll try to be brief and clear myself.

Summary:  Backpointers are very useful to those who need them, and cost
nothing to those who don't care to implement them.  Judy's email summarized
arguments Pro and Con.  Of the Pro arguments, while I concede that one of
them was silly, most remain unrefuted.  By contrast, all the Con arguments
already are refuted or can be refuted (see below).  Since there are many
unrefuted Pro arguments, and no unrefuted Con arguments, there can be no
reasonable objection to adding DAV:references as an optional part of DAV.
Remember, this is in the context of an optional extension (ACR) anyway.

Anyone who feels that they have additional refutations for Pro positions,
new Con arguments, or counters to the refutations of the Con positions
should speak up in this forum.

The remainder of this message attacks one of the counter arguments to the
Pro position, and refutes the Con arguments that did not already have
refutations.

One Pro argument is that if WebDAV does not specify the semantics, vendors
who implement may have inconsistent semantics, and will almost certainly
use differing names for the property.  This will destroy interoperability.

The counter-claim (quoted by Judy)
>	Discussion: This is server value-add and should be standardized (if
>at all) by a vendor community, not by WebDAV.

is mistaken, for two reasons.

"server value-add".  This claim would make sense for features that are
purely local to one class of server.  Server 'vendors' (I mean by this
anyone who creates a server, not just those who *sell* the server) should
be able to freely define new features when they affect only that server.
Thus e.g. if MS wants to define DAV properties that reflect underlying NT
semantics, they can do so.  But this is a property that makes sense for any
server that implements  references (especially direct references) and it
makes sense to try to get the semantics identical on *all* servers that
support MKREF.

"vendor community".  There is no forum to do this work other than the
WebDAV WG.  I thought this WG *was* the vendor community.  The vendors I
know about are MS, Greg Stein, and Xerox.

Consider the infamous "Halloween memo", and the reaction to it.  Private
extensions to open standards are a fine was to decommodify standards.  Why
would you force WebDAV to do this?

Con arguments

>Security concerns: A hostile client could cause large lists of backpointers
>to be created by creating lots of references.

Such a hostile client could also do large PUTs, or large PROPPATCHes.  This
is no new risk.

>Servers that are built on file system capabilities may find backpointers
>difficult to implement.

1. PyDAV is built on a file system, and backpointers are cheap
2. In any case, if it's expensive to implement then just don't do it.
Etags can be expensive too, you know.

>Clients may assume that it is more efficient to access a DAV:references
>property than to perform a search on DAV:reftarget.  ... DAV:references
may be
>computed on the fly.  This could be especially bad if a client tries to do
>PROPFIND with allprop, as there may be other computed properties as well.

Yes, it would be bad if a server implemented dav:references this way.  It
would in fact be stupid.  Should we leave something out of DAV because it's
possible to implement it poorly and expensively?  it's not as if the
definition is such that it's impossible to implement it cheaply.  The same
arguments would rule out other extensions proposed for DAV, including DASL.

Received on Friday, 18 December 1998 15:03:37 UTC