RE: Dereferencing Match draft for the repository...

[Ryan Moats <jayhawk@att.com>]

| 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).

Well, I disagree about the lack of
necessity (of course, why else was the
draft written :-).  Look at some
of the schemata being developed in other parts
of the IETF (ipsec, policy).

| 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.

Ok, so you want not only "how does a server
react if it doesn't support this control"
but "how does a client determine a server
supports this control".  I think this would
be done through the supportedExtension
attribute of the root DSE, a la RFC 2251
and RFC 2252.

I think both statements should be added to
the draft (they are good things to have,
thanks for the comments)

Ryan