RE: Dereferencing Match draft for the repository...

[Ryan Moats <jayhawk@att.com>]

Harald wrote:

| At 16:01 18.06.99 -0500, Ryan Moats wrote:
| >I-D editor:
| >
| >Please insert the following draft as
| >draft-moats-ldap-dereference-match-00.txt  Thanks-
| 
| This is part of a trend I've seen for a while, where
| one extends the LDAP server in multiple directions,
| in order to make particular clients for particular
| functions more efficient.
| 
| The endgame of this particular trend is a situation
| where we have multiple completely independent
| LDAP-based services serving differing purposes, but
| with little real interoperability between them.
| 
| I'm not particularly happy with a model where my
| organization has to run 5 different LDAP *services*
| (probably using servers from 4 different vendors), so
| that the 5 different functions-using-extensions-to-LDAP
| can continue to work.
| 
| This started worrying me about 10 minutes after I saw
| the first drafts on Dynamic LDAP, so it's not exactly
| a new thing......

While I understand Harald's concern, my current opinion
(and this can change) is that there are already enough
cases when dereferencing pointers is a useful thing.
However, I do agree that the draft needs more interoperability
discussion (see below).

David Boreham wrote:

| I'd like to propose that it be a rule of the ldapext working
| group that all such documents must state clearly what
| are the implications for a server not implementing the
| wizbang new feature proposed. Also a statement on
| how interoperability can be maintained should be
| required.
|
| I've tried to include this sort of information in
| the feature-creep drafts I've written, but looking
| back I wish I'd put it in distinct sections.

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

Ryan Moats