Protocols should constrain servers, not clients

The SEARCH method request body (2.3.3) says "client MUST include a text/xml
request body ...".  I think it should instead say "server MUST support
text/xml request body, and MAY support other request bodies".

Why?   I claim that, in general, a protocol specification (at least for
HTTP extensions) is both extensible and yet interoperable if it constrains
servers and not clients [*].   A specification should tell servers what
forms (headers, request body formats, XML elements) they MUST be able to
process (understand), but it should not prevent them from accepting
additional forms.  A spec should defines the minimal behavior that every
server MUST provide, so that authors of  clients can reliably code against
it.   The spec should also indicate what servers do with forms they don't
understand.  In some cases the right thing is to silently ignore them (as
HTTP mandates for headers), in other cases the right thing is to reject
them.  There is no need to impose any restrictions on clients.  In some
cases, a client will be expoit undocumented or experimental features of a
particular server.  This may not be interoperable with other servers but
that's the client's problem, it is not a problem for either the server or
the protocol in general.

Applying this general principle to the specific case of the DASL search method
This leaves room for future expansion to use other kinds of request bodies,
at no cost in complexity to the protocol or implementors.  Suppose a future
working group wants to extend DASL to support use of image data as a query.
 This is not in our charter, but it might be in theirs.  They might want to
define the behavior of SEARCH with an image/* request body.  The language
in the current spec makes that illegal.  The language I propose would allow
them to extend the definition in a fully compatible manner.  No old client
would break on a new server, and new clients would fail gracefully on old
servers.

Is there any objection to this change?

[*] this observation is due to Yaron.

Received on Friday, 19 June 1998 17:31:34 UTC