[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt
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 <jmcmeek@us.ibm.com> 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
ldapext-bounces@ietf.org 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
>
> >>> <Internet-Drafts@ietf.org> 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
> i-d-announce-request@ietf.org 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:
> mailserv@ietf.org.
> 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
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext