Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 13 Aug 2004 13:50:13 -0600

It's a valid concern.

I assume different client SDKs will need to be updated to varying
degrees to support a new search scope. Some may just allow an int to
pass through, while others will require a new enumerated type (and thus
require that the SDK be revised). Something similar may have happened
(though likely to a much less degree) when the '+' all operational
attributes selection string was introduced.

I personally feel that allowing there to be a ripple effect on client
SDKs is actually healthy. Client SDKs should be flexible enough to adapt
to future extensions regardless of the form of extension. Meaning, I
would prefer a world where the protocol may be extended without having
to worry about the impact to current client SDK implementations.

But if it turns out that there is significant concern about this, I can
revise to extending by control rather than extending the search scope.
Another alternative is to define the control in addition to the new
scope.

Jim

>>> John McMeeking <[email-masked]> 8/13/04 12:15:20 PM >>>

Before I go on vacation and forget this completely...

I have a practical concern with defining a new search scope, as opposed
to,
say, a "subordinate subtree scope" control:  Do existing clients
validate
the search scope?  Or provide a search interface designed in such a
way
that supporting a new scope would require a new programming interface
or
similar changes?  For example, System.out.println shows the JNDI
SearchControls.xxx_SCOPE constants happen to map to the LDAP search
scope
enumeration, but they could just as easily been different values.

>From a server/protocol perspective, I think it is cleaner to define a
new
scope.  But if making use of this feature requires LDAP client changes
(possibly from a different vendor than the server), it might be more
practical to provide this feature as a control.

John  McMeeking

[email-masked] wrote on 08/12/2004 12:31:12 PM:

> All,
>
> I found a need for this as I was fleshing out work on the
distributed
> op procedures I-D, but I've also had such a search scope requested a
> number of times in the past (and I believe other vendors have as
well).
>
> Please review if you have some time (it's very short).
>
> Thanks,
>
> Jim
>
> >>> <[email-masked]> 8/11/04 1:21:56 PM >>>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>    Title      : Subordinate Subtree Search Scope for LDAP
>    Author(s)   : J. Sermersheim
>    Filename   :
> draft-sermersheim-ldap-subordinate-scope-00.txt
>    Pages      : 6
>    Date      : 2004-8-11
>
> The Lightweight Directory Application Protocol (LDAP) specification
>    supports three scope values for the search operation -- namely:
>    baseObject, singleLevel, and wholeSubtree.  This document
> introduces
>    a subordinateSubtree scope which constrains the search scope to
all
>    subordinates of the named base object.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sermersheim-ldap- 
> subordinate-scope-00.txt
>
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body
of
> the message.
> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce 
>
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>    "get draft-sermersheim-ldap-subordinate-scope-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>    [email-masked].
> In the body type:
>    "FILE
> /internet-drafts/draft-sermersheim-ldap-subordinate-scope-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>    MIME-encoded form by using the "mpack" utility.  To use this
>    feature, insert the command "ENCODING mime" before the "FILE"
>    command.  To decode the response(s), you will need "munpack" or
>    a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>    exhibit different behavior, especially when dealing with
>    "multipart" MIME messages (i.e. documents which have been split
>    up into multiple messages), so check your local documentation
> on
>    how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> [attachment "Part.001" deleted by John McMeeking/Rochester/IBM]
> [attachment "draft-sermersheim-ldap-subordinate-scope-00.txt"
> deleted by John McMeeking/Rochester/IBM] [attachment "Part.003"
> deleted by John McMeeking/Rochester/IBM]
> _______________________________________________
> Ldapext mailing list
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Aug 2004 16:58:53 -0400

> attributes selection string was introduced.

I suspect many SDKs will need to be updated to support the new search 
scope.  For example, the Netscape/Mozilla SDKs validate the scope 
parameter and therefore won't pass a new value through.

> to worry about the impact to current client SDK implementations.

I agree, within reasonable limitations.  A bigger question is:  do we 
need a new protocol feature to be available to people who are using 
existing/older SDK implementations?  To me, this is more of a "how quick 
will people adopt the feature and be able to use it" concern than a "we 
are going to break something" concern.  But I may be overlooking something.

-- 
Mark Smith
LDAP Book Information: http://www.ldapbook.com/
What's Next:           http://www.pearlcrescent.com/

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Aug 2004 07:31:53 +0200

At 10:58 PM 8/13/2004, Mark Smith wrote:
>A bigger question is:  do we need a new protocol feature to be available to people who are using existing/older SDK implementations? 

As long as only those wanting to make use of the new feature
need a newer SDK, I have absolutely no problem with protocol
extensions which require changes to existing SDKs.

Certainly an old client should choke if they were provided
an LDAP URL with a subordinate scope (through user input
or from the server)... but an old client should also choke
in face of an LDAP URL with a critical subordinate control.

And, I note, both likely might require SDK enhancements
(most SDKs handle LDAP URLs returned by the server directly).

To me, the implication is that servers should only return
such URLs when the clients specifically request that they
be returned.

Kurt

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Aug 2004 09:17:09 -0400

> such URLs when the clients specifically request that they

I agree of course.  In my mind the last sentence above goes without 
saying.  But it does not hurt to say it ;-)

---

From: Michael Ströder <[email-masked]>
Date: Tue, 24 Aug 2004 09:33:12 +0200

> such URLs when the clients specifically request that they

And how should the client specifically request that they are returned? 
Doesn't this make things more complicated at the client side?

IMO it should be subject to server configuration whether to return a new 
search scope or not. While planning a LDAP service deployment you already 
have to consider whether all the LDAP clients used behave nicely with this 
server (configuration).

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 24 Aug 2004 12:23:53 +0200

> parameter and therefore won't pass a new value through.

That's not an issue since the LDAP client application is more relevant here.

If the application does not support the new search scope value it's not an 
issue that the SDK does not accept the new search scope value. If the 
application does support it the application programmer simply has to program 
on top of the updated SDK.

> A bigger question is:  do we 
> existing/older SDK implementations?

IMO no.

> To me, this is more of a "how quick 
> are going to break something" concern.

Looking at my logs many LDAP clients are solely using 'wholeSubtree' as 
search scope value. Therefore I don't understand this issue.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Aug 2004 13:04:49 +0200

>And how should the client specifically request that they are returned? 

I'd use a control... or bind using version=4.

>Doesn't this make things more complicated at the client side?

I rather 'complicate' new clients than break old clients.

>IMO it should be subject to server configuration whether to return a new search scope or not. While planning a LDAP service deployment you already have to consider whether all the LDAP clients used behave nicely with this server (configuration).

Remember that we (the IETF) design protocols for the Internet,
not some local deployment where a single administrator has
control of all clients and servers.

Kurt