[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: draft-ietf-ldapext-ldapv3-vlv-02.txt last call

To: Jim Sermersheim <JIMSE@novell.com>, ietf-ldapext@netscape.com
Subject: Re: draft-ietf-ldapext-ldapv3-vlv-02.txt last call
From: dboreham@netscape.com (David Boreham)
Date: Thu, 17 Dec 1998 21:08:05 -0800
Resent-date: Thu, 17 Dec 1998 21:11:29 -0800 (PST)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"VYEpI3.0.1-3._FUUs"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com
>about something similar today.  How does a client discover which attribute
>types are supported by the SSS control?  An attribute at the root DSE
>(call it supportedSortIndex) could hold the information (list of attribute
types) .

Here's an example of what we currently have:

First, in the rootDSE:

D:\users>ldapsearch -h beefcake.mcom.com -p 5555 -b "" -s base
"objectclass=*"
dn:
objectclass: top
namingcontexts: o=ace industry,c=us
namingcontexts: o=NetscapeRoot
subschemasubentry: cn=schema
supportedcontrol: 2.16.840.1.113730.3.4.2
supportedcontrol: 2.16.840.1.113730.3.4.3
supportedcontrol: 2.16.840.1.113730.3.4.4
supportedcontrol: 2.16.840.1.113730.3.4.5
supportedcontrol: 1.2.840.113556.1.4.473
supportedcontrol: 2.16.840.1.113730.3.4.9
supportedsaslmechanisms: EXTERNAL
supportedldapversion: 2
supportedldapversion: 3
dataversion: beefcake.mcom.com:5555 019980908232402
netscapemdsuffix: cn=ldap://:5555,dc=beefcake,dc=mcom,dc=com
vlvsearch: cn=Tels,cn=config,cn=ldbm
vlvsearch: cn=Surnames,cn=config,cn=ldbm
vlvsearch: cn=Names,cn=config,cn=ldbm
vlvsearch: cn=MCC ou=Product Testing,cn=config,cn=ldbm
vlvsearch: cn=MCC ou=Product Development,cn=config,cn=ldbm
vlvsearch: cn=MCC ou=Payroll,cn=config,cn=ldbm
vlvsearch: cn=MCC ou=Human Resources,cn=config,cn=ldbm
vlvsearch: cn=MCC ou=Accounting,cn=config,cn=ldbm
vlvsearch: cn=Ls,cn=config,cn=ldbm
vlvsearch: cn=Emails,cn=config,cn=ldbm

Then, in the entries under cn=config, cn=ldbm:

D:\users>ldapsearch -h beefcake.mcom.com -D "cn=Directory Manager" -w
password -p 5555
-b "cn=config,cn=ldbm"  "(|(objectclass=vlvIndex)(objectClass=vlvSearch))"
"*"
dn: cn=byCN,cn=Names,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byCN
vlvsort: cn
vlvenabled: 1
vlvuses: 31
numsubordinates: 0

dn: cn=byCNd,cn=Names,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byCNd
vlvsort: -cn
vlvenabled: 1
vlvuses: 7
numsubordinates: 0

dn: cn=byL,cn=Ls,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byL
vlvsort: l
vlvenabled: 1
vlvuses: 2
numsubordinates: 0

dn: cn=byLd,cn=Ls,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byLd
vlvsort: -l
vlvenabled: 1
vlvuses: 4
numsubordinates: 0

dn: cn=byMail,cn=Emails,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byMail
vlvsort: mail
vlvenabled: 1
vlvuses: 3
numsubordinates: 0

dn: cn=byMaild,cn=Emails,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byMaild
vlvsort: -mail
vlvenabled: 1
vlvuses: 11
numsubordinates: 0

dn: cn=bySN,cn=Surnames,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: bySN
vlvsort: sn
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=bySNd,cn=Surnames,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: bySNd
vlvsort: -sn
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=byTel,cn=Tels,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byTel
vlvsort: telephonenumber
vlvenabled: 1
vlvuses: 2
numsubordinates: 0

dn: cn=byTeld,cn=Tels,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: byTeld
vlvsort: -telephonenumber
vlvenabled: 1
vlvuses: 5
numsubordinates: 0

dn: cn=Emails,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: Emails
vlvbase: o=ace industry,c=US
vlvscope: 2
vlvfilter: (sn=*)
aci: (target="ldap:///cn=Emails, cn=config, cn=ldbm") (targetattr = "*")
(vers
 ion 3.0; acl "Config"; allow( read, search, compare ) userdn =
"ldap:///anyo
 ne";)
numsubordinates: 2

dn: cn=Ls,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: Ls
vlvbase: o=ace industry,c=US
vlvscope: 2
vlvfilter: (l=*)
aci: (target="ldap:///cn=Ls, cn=config, cn=ldbm") (targetattr = "*")
(version
 3.0; acl "Config"; allow( read, search, compare ) userdn =
"ldap:///anyone";;
 )
numsubordinates: 2

dn: cn=MCC ou=Accounting,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: MCC ou=Accounting
vlvbase: ou=Accounting, o=Ace Industry, c=us
vlvfilter: (objectclass=*)
vlvscope: 1
multilinedescription: Browse all direct children of ou=Accounting, o=Ace
Indus
 try, c=us
numsubordinates: 1

dn: cn=MCC ou=Human Resources,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: MCC ou=Human Resources
vlvbase: ou=Human Resources, o=Ace Industry, c=us
vlvfilter: (objectclass=*)
vlvscope: 1
multilinedescription: Browse all direct children of ou=Human Resources,
o=Ace
 Industry, c=us
numsubordinates: 1

dn: cn=MCC ou=Payroll,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: MCC ou=Payroll
vlvbase: ou=Payroll, o=Ace Industry, c=us
vlvfilter: (objectclass=*)
vlvscope: 1
multilinedescription: Browse all direct children of ou=Payroll, o=Ace
Industry
 , c=us
numsubordinates: 1

dn: cn=MCC ou=Product Development,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: MCC ou=Product Development
vlvbase: ou=Product Development, o=Ace Industry, c=us
vlvfilter: (objectclass=*)
vlvscope: 1
multilinedescription: Browse all direct children of ou=Product Development,
o=
 Ace Industry, c=us
numsubordinates: 1

dn: cn=MCC ou=Product Testing,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: MCC ou=Product Testing
vlvbase: ou=Product Testing, o=Ace Industry, c=us
vlvfilter: (objectclass=*)
vlvscope: 1
multilinedescription: Browse all direct children of ou=Product Testing,
o=Ace
 Industry, c=us
numsubordinates: 1

dn: cn=Names,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: Names
vlvbase: o=ace industry,c=US
vlvscope: 2
vlvfilter: (cn=*)
aci: (target="ldap:///cn=Names, cn=config, cn=ldbm") (targetattr = "*")
(versi
 on 3.0; acl "Config"; allow( read, search, compare ) userdn =
"ldap:///anyon
 e";)
numsubordinates: 2

dn: cn=SN MCC ou=Accounting,cn=MCC ou=Accounting,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: SN MCC ou=Accounting
vlvsort: sn givenname cn ou o
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=SN MCC ou=Human Resources,cn=MCC ou=Human Resources,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: SN MCC ou=Human Resources
vlvsort: sn givenname cn ou o
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=SN MCC ou=Payroll,cn=MCC ou=Payroll,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: SN MCC ou=Payroll
vlvsort: sn givenname cn ou o
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=SN MCC ou=Product Development,cn=MCC ou=Product
Development,cn=config,c
 n=ldbm
objectclass: top
objectclass: vlvIndex
cn: SN MCC ou=Product Development
vlvsort: sn givenname cn ou o
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=SN MCC ou=Product Testing,cn=MCC ou=Product Testing,cn=config,cn=ldbm
objectclass: top
objectclass: vlvIndex
cn: SN MCC ou=Product Testing
vlvsort: sn givenname cn ou o
vlvenabled: 1
vlvuses: 0
numsubordinates: 0

dn: cn=Surnames,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: Surnames
vlvbase: o=ace industry,c=US
vlvscope: 2
vlvfilter: (sn=*)
aci: (target="ldap:///cn=SurNames, cn=config, cn=ldbm") (targetattr = "*")
(ve
 rsion 3.0; acl "Config"; allow( read, search, compare ) userdn =
"ldap:///an
 yone";)
numsubordinates: 2

dn: cn=Tels,cn=config,cn=ldbm
objectclass: top
objectclass: vlvSearch
cn: Tels
vlvbase: o=ace industry,c=US
vlvscope: 2
vlvfilter: (telephonenumber=*)
aci: (target="ldap:///cn=Tels, cn=config, cn=ldbm") (targetattr = "*")
(versio
 n 3.0; acl "Config"; allow( read, search, compare ) userdn =
"ldap:///anyone
 ";)
numsubordinates: 2

The Netscape address book client knows how to grok all this
stuff and figures out which columns in its listbox to allow sorting
on, and whether to even try to send VLV searches for address
books.

Some of the indices above are for an admin UI,
the rest are for address books. Since this is a test
server, it is somewhat over-configured with indices.

Originally we had in mind that the client would wade through
the information above and (the first time they fire it up) present
the user with a picklist of "address books" from which they
could select. This idea was similar to what MAPI has---there's
an address book container concept there. Anyway, the client
developers never quite got their heads round that concept,
or didn't like it.

Note that VLV indices are also _configured_ by means of
an administration client creating entries of the form above.
LDAP for everything :)

For sure it would be good to standardize things like this.
Same goes for other server indices, which we expose in
a similar but slightly different way to the VLV indices.
Prev by Date: Re: draft-ietf-ldapext-ldapv3-vlv-02.txt last call
Next by Date: Re: LDAPEXT status and last calls
Index(es):
- Chronological
- Thread