Why it's bad to rely on other information to determine type

I just ran across an explanation for a RFC 2616 feature which leads me to
believe that the feature should be implemented for all methods -- the Expect
header (See separate post to w3c-dist-auth for details).

Do all your DAV servers support the Expect header properly on all methods?
I suspect not.  CLients don't actually send it.  And yet, it's required by
HTTP/1.1

This is an example of theoretical "non-compliance".  A required feature is
missing.  Oh horrors!  Note that it doesn't seriously impede
interoperability.  Perhaps nobody was sure how to use the feature.  Shrug.

The implication of a situation like this is that designers of a
specification cannot foresee how everything is going to fall out.  Not all
"required" features may be implemented, and this might be OK.  If there was
some kind of "allowed-headers-set" that could be queried, a compliant client
should see "Expect" in there for all resources and all methods -- yet it
won't.

Relying on a set of methods and properties supported in order to determine
type is brittle because of these kinds of failures of perfect foreknowledge.
For all Geoff's wisdom, it's conceivable that some REQUIRED live property
will end up not being supported by some, most, or all servers.  And that
would ruin a client's ability to use the supported-*-set values to see what
type things are.

We're human, and we could be wrong.  Please design a system that takes that
into account, and does not entirely break down if we do not predict the
future completely accurately.

Lisa

Received on Thursday, 21 June 2001 17:37:53 UTC