Re: [RFC2518 Issue] PROPFIND 'allprop' usage

...

These seem to be our options for modifying RFC2518 (remember, it has to be
a
simple mod):
 - deprecate 'allprop' and tell clients not to use it, but to use
'propname' instead

<tim>
This won't fix the problem, servers still have to deal with clients that
fail to follow the deprecation warning.  There would be no way to deprecate
the call anyway (other than on paper).
</tim>

 - define 'allprop' to be the set of properties required for DAV level 1
support (although servers could freely return more properties if desired)

<tim>
This is a breaking change to the spec.  I think it is unfair on clients to
change the spec. to this extent and at this stage.  To a 'legacy' client,
the request would appear to have succeeded but only returned partial
results, and there would be no indication that this had occurred.  The
would need to be some means for a client to determine of a server is
written to this new definition, which means it is a 'convenient'
deprecation.

I would support this if the server returned the subset of properties with a
new 200-series response code to indicate that the results were incomplete.
One could hope that some clients could continue to work in this environment
without modification.
</tim>

 - explicitly allow servers to return an error code (507?) for properties
that were too expensive to calculate for a 'allprop' request, but still
allowing the client to do property discovery through 'allprop'

<tim>
IMHO This would be a cleaner solution since clients are presumably already
dealing with server errors.  Clients would still learn the existance of
properties and their names, and smart clients could return to get their
values.

I suggest that the same error code be available for use with collections
that refuse to go deep.  It is astounding that a PROPFIND with no depth
header and no body is to be interpreted as all prop depth infinity -- the
server needs some mechanism to say 'be reasonable client'.
</tim>

Received on Monday, 13 November 2000 10:26:10 UTC