RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

> Just so that you know you're not alone... what Julian suggests sounds
> reasonable.

OK, this is really starting to sound like consensus, but I want to make
sure we explore the options.  I don't want to accept a consensus based
on arguments that I don't think are valid, even if the consensus might
be right I'd like to know why by seeing valid arguments.

I've attempted to rebut the two arguments I believe to be invalid.
Please explain why I'm wrong if you think the arguments are in fact
valid (perhaps I haven't understood the arguments).  Or, please explain
what other arguments remain for making Etags optional.

1.  The argument that "Etags are too difficult to support".  Is the
problem with strong etags that they're hard to implement for all
resources? Or only for PUTtable resources? The requirement could be that
servers supporting "bis" MUST support strong Etags in response to
successful PUT requests.   Given this, I think it's easy.
 
RFC2616 only says:
   A "strong entity tag" MAY be shared by two entities of a resource
   only if they are equivalent by octet equality...

   An entity tag MUST be unique across all versions of all entities
   associated with a particular resource. A given entity tag value MAY
   be used for entities obtained by requests on different URIs. The use
   of the same entity tag value in conjunction with entities obtained by
   requests on different URIs does not imply the equivalence of those
   entities.

That means that Etags could be almost as simple as a sequence number
plus possibly some file/url string.  A digest of the contents would also
work. Supporting strong etags is actually easier than supporting weak
etags.  It may be slightly time-consuming to generate etags depending on
what algorithm you choose, but the time is insignificant compared to the
time it takes to receive a PUT request, check access controls and store
the body. 

Next, no WebDAV server should have any problem storing the ETag. Any
server capable of storing dead properties is capable of storing an etag
generated on PUT.  A server that cannot store ETags is already likely to
be massively non-compliant.

I might consider a cost-benefit argument to be a valid argument --
although I believe the benefits are high and thus the cost would have to
be even higher to outweight.  However, I don't consider "too difficult
to support regardless of the benefits" to be a valid argument.

2. If 2518bis requires support for Etags, this doesn't retroactively
make servers like IIS5.0 non-compliant with 2518.  That's a historical
standard and we can't change that even if we wanted to. 

On the other hand, there will be several requirements 2518bis which will
make servers compliant with 2518 have to do some work to be compliant
with 2518bis:
 - Making LOCK on an unmapped resource create a regular empty locked
resource (not a lock-null resource)
 - Supporting commas in if header syntax
 - Evaluating all clauses in an if header even if they are tagged with a
URL to which the request does not "apply"
 - etc...

Given that we are already making more requirements on servers in 2518bis
than we did in 2518,  I do not see the "making servers non-compliant"
argument as a valid argument.

Lisa

Received on Wednesday, 26 February 2003 14:36:30 UTC