Re: Dereferencing Match draft for the repository...

[dboreham@netscape.com (David Boreham)]

Ryan Moats wrote:

> I like the idea of adding a "how to respond if you don't
> support this extension" section to the draft.  As far as
> interoperability beyond this, I'm not sure I understand:
> why isn't this a binary situation (the server supports
> the extension or not).

I believe that a draft can typically be more
forthcoming. Specifically I'd like to see
discussion of what happens when a client which
supports the new feature encounters a server
which does not. If the answer is "nothing
works", then that's bad. (As an aside, I'm
_particularly_ interested in hearing the 
answer for your latest draft, because 
it seems that the proposed extensions are
not fundamentally necessary, therefore
new client to old server interoperability
should be easily achievable).

Here's an example: VLV allows browsing
of a search result set, but it's always
an additional qualifier on a regular sorted
search. So, a client can observe that the
server its talking to does not support
VLV, send the search without the VLV
control, and extract the useful subset
of the result set itself. Similarly, an
address book client which supports VLV
can degrade to a non-browsing, search-only
UI if it connects to a server which 
does not support VLV.
So you can build a client which
works with standard servers, but works
better with enhanced servers, rather
than a client which only works with
the enhanced servers. The spec should
IMHO give some indication or guidance
as to whether and how this can be done.