NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 16-Oct-00
Chair(s):
Roland Hedberg <roland@catalogix.se>
M. Wahl <Mark.Wahl@innosoft.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion:ietf-ldapext@netscape.com
To Subscribe: ietf-ldapext-request@netscape.com
Archive: ftp://ftp.innosoft.com/ietf-ldapext/
Description of Working Group:
LDAPv3 defines an information model and an authentication model, allowing information to be protected via access control. But LDAPv3 defines no standard representation or semantic for this access control information. This work item will be to define such a standard access control model.
- Server-side sorting of search results - Paged retrieval of search results
In order to more efficiently support the assumptions of users viewing search results as a sorted, scrollable list, servers sort and provide a paged view onto search results. This work item will define the LDAPv3 message controls to allow a client to request a particular sort order, and to allow a client to retrieve search results one page at a time. The group will base its work on the following drafts:
draft-ietf-asid-ldapv3-sorting-nn.txt draft-ietf-asid-ldapv3-simple-paged-nn.txt
- Language tags
LDAPv3 carries character data in UTF-8 format, allowing the full range of international characters to be represented. This work item will be to define attribute descriptions allowing the data returned from or input to an LDAPv3 directory to be tagged identifying the language of the data, and to define an LDAP message control allowing a client to specify a preferred language. The group will base its work on the following draft:
draft-ietf-asid-ldapv3-lang-nn.txt
- Dynamic directories
LDAPv3 supports static directory information that persists in its value over a relatively long period of time until it is removed. Some applications (e.g., Internet conferencing) require dynamic information that changes often and persists only as long as it is being refreshed. The deliverable from this work item will be LDAPv3 message controls and extended operations allowing the specification and refresh of dynamic directory information. The group will base its work on the following drafts:
draft-ietf-asid-ldapv3ext-04.txt draft-ietf-asid-ldap-dynatt-nn.txt
- Referral and knowledge reference maintenance
LDAPv3 is defined as an access protocol in which referrals may be returned directing a client from one directory server to others. It does not specify how this referral information is represented in the directory. The deliverable from this work item is a document defining the mechanisms by which referrals (sometimes known as knowledge references) may be maintained in a server. The group will base its work on the following draft:
draft-ietf-asid-ldapv3-referral-nn.txt
- LDAP server discovery
Like most other Internet protocols, LDAPv3 is silent on the bootstrapping issue of how a client locates an LDAP server to talk to. Yet this step is necessary for any client to successfully use the directory without a priori knowledge of the directory server address it should use. The group will work in conjunction with the SVRLOC group on defining the method by which LDAP clients discover LDAP servers, based on the following document:
draft-ietf-svrloc-discovery-nn.txt
- LDAP APIs
LDAP has an associated de facto standard C API, defined in RFC 1823. The existence of this API has proved to be of great value in spurring LDAP client development. As new features are added in LDAPv3 and the extensions discussed elsewhere in this charter, the API will need to be updated to make these new protocol features available to clients. As application development in other languages, Java in particular, occurs, the need for a standard API increases. The deliverable from this work item will be documents updating RFC 1823 for LDAPv3, documents defining API extensions to support protocol extensions, and a document defining a similar API for Java. The group will base its work on the following documents:
draft-ietf-asid-ldap-c-api-nn.txt draft-ietf-asid-ldap-java-api-nn.txt draft-ietf-asid-ldapv3-api-ext-nn.txt
- CLDAP
LDAPv3 defines transport over TCP. In some situations, the overhead involved in setting up and tearing down TCP connections is prohibitive, requiring a lighter-weight transport. The deliverable from this work item will be a document defining transport of the LDAPv3 protocol over connectionless UDP transport. The group will expand on the work developed for LDAPv2 in RFC 1798.
- Signed directory information
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. The deliverable will be a document describing an LDAP message control which allows for the retrieval of digitally signed information.
Other areas such as deployment and schema definition and review will be handled by other groups. Other areas may be added after approval by the area directors if and when they turn out to be necessary for the deployment of LDAP and feasible for the group to tackle. In particular, replication may be considered for addition to the group's charter if and when a viable approach to the problem is demonstrated.
Goals and Milestones:
Done |
|
Submit ID on paged retrieval of search results |
Done |
|
Submit ID on dynamic directories |
Done |
|
Submit ID on C LDAP API |
Done |
|
Submit ID on sorting of search results |
Done |
|
Submit ID on language tags |
Done |
|
Submit ID on Java LDAP API |
Done |
|
Meet at 40th IETF (DC) |
Done |
|
Submit ID on paged retrieval of search results to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on sorting of search results to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on referrals and knowledge references to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on signed directory information |
Done |
|
Submit ID on recommended authentication methods |
Done |
|
Submit ID on dynamic directories to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on access control requirements |
Done |
|
Submit ID on signed directory information to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on recommended authentication methods to IESG for consideration as a Proposed Standard |
Done |
|
Submit ID on access control |
Jul 99 |
|
Submit ID on referrals and knowledge references |
Jul 99 |
|
Submit ID on C LDAP API to IESG for publication as a RFC |
Jul 99 |
|
Submit ID on Java LDAP API to IESG for publication as a RFC |
Dec 99 |
|
Submit ID on CLDAP |
Dec 99 |
|
Submit ID on access control to IESG for consideration as a Proposed Standard |
Mar 00 |
|
Submit ID on CLDAP to IESG for consideration as a Proposed Standard |
Mar 00 |
|
Conclude group or update WG Charter |
Internet-Drafts:
· The Java LDAP Application Program Interface
· LDAP Extensions for Scrolling View Browsing of Search Results
· Persistent Search: A Simple LDAP Change Notification Mechanism
· The C LDAP Application Program Interface
· Access Control Model for LDAP
· X.509 Authentication SASL Mechanism
· LDAP Control for a Duplicate Entry Representation of Search Results
· Returning Matched Values with LDAPv3
· A Taxonomoy of Methods for LDAP Clients Finding Servers
Request For Comments:
RFC |
Status |
Title |
RFC2589 |
PS |
Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services |
RFC2596 |
PS |
Use of Language Codes in LDAP |
RFC2649 |
E |
An LDAP Control and Schema for Holding Operation Signatures |
RFC2696 |
LDAP Control Extension for Simple Paged Results Manipulation | |
RFC2820 |
Access Control Requirements for LDAP | |
RFC2829 |
PS |
Authentication Methods for LDAP |
RFC2830 |
PS |
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
RFC2891 |
PS |
LDAP Control Extension for Server Side Sorting of Search Results |
Minutes for LDAPEXT @ IETF-49 (2000-12-11)
Reported by Leif Johansson <leifj@it.su.se>
Chairs: Mark Wahl, Roland Hedberg
1. Introduction and Agenda Bashing
MarkW: lots of work items. We expect that ldapext2 would be created to handle at least some of these item unless we add them to ldapext charter.
- Question about C-api for extensions. Status of this? C-api not on agenda since Mark Smith not at the meeting. Defered to charter review point.
2. Working Group Status (Mark Wahl and Roland Hedberg)
- LDAPBIS Monday 19:30
- LDUP Tuesday 09:00
- Next Meeting in MN (IETF-50)
Completed:
- server side sorting, language tags, dyn entries signed info
Nearly
- server discovery, taxonomy, java api
In progress
- ACL , referrals, C API, CLDAP
Strong signals from IESG to update charter! Document target dates have past, some documents are moving (eg to LDAPBIS) and there are additional work items of interest. Webpage soon up on www.ldap.com or something like that.
Comment: Taxonomy document done but is in limbo due to dependency on other documents.
3. Scrolling List View (Michael Armijo)
draft-ietf-ldapext-ldapv3-vlv-04.txt
- some problems with which error to return in certain circumstances.
4. Server Discovery through DNS (RL 'Bob' Morgan)
draft-ietf-ldapext-locate-04.txt
- Bobs screen resolution out of range!
BobM: Stable document with some nits. Question of weather server discovery of CLDAP servers should be supported in this document. Probably exclude CLDAP from document.
LeifJ: CLDAP might have different semantics from LDAP which may be a reason for excluding it.
BobM: does dc components have to be the most significant part? the algorithm for getting domain name from X.500 name could simply take _any_ dc-components in the DN in order regardless of where they are found in the DN.
KurtZ: this has already been discussed on the list in the context of multivalued rdns etc. Review that! Is this an X.509 issue or a server location issue?
MarkW: Don't change the document since it would require changes in core documents! Someone may use dc-components with completely different semantics further down in the DN. (References were made to 2247).
Ed Reed: Larger issue of foreign name resolution in relation with DNs.
BobM: Lets not defer this document until such a large problem has been solved.
- some discussion followed about mappings and not precluding further work down the road.
John: The scope of locate can be defined to be trees rooted in DNS...
MarkW: Is the current document the right approach? (rough consensus)
Comment: Scoping the document and going forward is a good plan! Don't go down the slope of handling all possible namespaces.
5. Java API (Rob Weltman)
draft-ietf-ldapext-ldap-java-api-12.txt (*UPDATED*)
JimS: Summary of changes. Rob believes the current changes can be made during a last call period and is requesting last call.
MarkW: Do api changes before last call!
6. Referrals and knowledge maintenance (Roland Hedberg and Kurt Zeilenga)
draft-ietf-ldapext-refer-00.txt
draft-zeilenga-ldap-namedref-01.txt (*UPDATED*)
RolandH: Several types of references in two drafts. Subordinate refs go into a small draft and goes quickly to last call. All other types go into another draft to be issued some time early next year.
7. Duplicate Entries (Jim Sermersheim)
draft-ietf-ldapext-ldapv3-dupent-06.txt (*UPDATED*)
JimS: gone through a last call (version 5) which resulted in a few minor edits. Ready for last call again.
Comment: Can entries get returned that do not match filters?
JimS: Yes and other cool effects too!
8. Access Control Model (Ellen Stokes)
draft-ietf-ldapext-acl-model-06.txt
EllenS: Long list of resolved comments which are scheduled for addition to the draft. Some comments still need to be resolved. Target for new draft for end of January with last call by early March.
Comment: Auditing as a special permission?
EllenS: Add to list of comments....
9. CLDAP (Leif Johansson)
draft-ietf-ldapext-cldap-00.txt
LeifJ: CLDAPv3 has very little to do with CLDAPv2. The draft will probably only deal with read-only operations but we will try to do it in such a way that it wan't preclude someone else from doing modify and the likes later on. A new version will appear before the end of the year.
KurtZ: move to experimental?
MarkW: No, if there is sufficient interest in the group of doing CLDAP then we should aim for Proposed Standard if not then the work item should be dropped from the charter.
10. Subentries (Ed Reed)
draft-ietf-ldup-subentry-05.txt (*UPDATED*)
EdR: significant revisions. X509 subtree specification could be added by inheritance.
Inheritance: eg ACLs and various other policies want policy to inherit down the tree. New subclass of subentry for inheritance. Possible to define other inheritance mechanisms by subclassing.
DavidC: Question about scoping. (discussion ensues).
KurtZ: blockInheritance should be defaulted to TRUE??
EdR: Arguments can be made for many positions...
Comment: Why is blockInheritance MAY and default FALSE instead of MUST and default TRUE. (nits nits).
EllenS: Can you handle policies different per subentry?
EdR: No. Inheritance does not care which policy is inhereted. You either inherent all or not at all. However you could subclass specifically (say) for ACLs.
MarkW: Are there examples?
EdR: High-level examples only.
EdR: The mix-in rule is "replace" as opposed to any other method of combining policy. Policies all have different requirements and I don't know how to write a combination- rule for a general situation.
Comment: Few situations where subentries are used but the discussion used examples from ACLs. Where are subentries actually used and used with inheritance?
EdR: Replication does not use inheritance but ACLs would need to replicate inheritance!
Comment: If all you need is replace then blockInheritance can be implemented as an empty policy!
MarkW: Authors who use subentries should work with Ed!
EdR: Administrative area discussion. LDUP has certain expectations (see slide 10). What then is an administative area:
- Anything with a subentry below
- Anything marked with an administrative point in some way.
- Up to the application
MarkW: The second is the X500-way. LDAPBIS may reintroduce the DSE-type.
KurtZ: Careful! This may cause recycle of the standard!
EdR: More and more X.500-isms hacked into LDAP implementations.
KurtZ: Important to have a consistent approach to this.
EdR: Visibility Mechanisms. Define a control which makes subentries visible. baseEntry scope is handled differently (i.e an X.500 read).
DavidC: In this case the control has no meaning!
EdR: Searchfilters can be used to pick out subentries in some implementations (Netscape) but it is deprecated.
MarkW: Suggest delete this.
KurtZ: Suggestion: If the base of the search is a subentry pretend the control is present and TRUE.
DavidC: X.500 does not have subentries below subentries. Would you then not miss the entry itself if you do a subtree search withouth the control?
KurtZ: No the suggested semantics is that the control is treated as present and true whenever the base of the search is a subentry (regardless of scope).
EdR: Summary.
MarkZ: Summarize comments to the mailinglist.
11. Charter Review (Mark Wahl and Roland Hedberg)
Proposed new timelines:
- Server discovery: 3/2001
- Java API: 3/2001
- C API: 6/2001
- Referral
* 3/2001 (for named subordinates)
* 6/2001 (for other referral types)
- Access Control model: 6/2001
- CLDAP: 9/2001
MarkW: Result of armtwisting and threats. Goal is to clear the current agenda by fall next year.
Moving Documents:
* Subentry: needed by LDUP
* draft-just-ldapv3-rescodes-02.txt and draft-armijo-ldap-control-error-00.txt: LDAPBIS
Other topics:
* 2247/2255 update for i18n URL/domains
Comment: How can you update 2255 while LDAPBIS is working on it?
KurtZ: IDN will not affect 2255 since this document inherits from URI documents.
PatrikF: The reference goes to old version of document so you should/must revise in the face of IDN.
KurtZ: (various nits about schema)
Comment: Should not LDIF go to proposed standard??
MarkW: Not in LDAPBIS since this has a very tight focus. This may not need to be a charter item!
KurtZ: Rescodes will (probably) go to LDAPBIS. The control error doc needs discussion before moving it.
MarkW: Additional work items (see slide) presented. Grouped into
Subentry
Value Control
Chaining and proxying
Request/Response Grouping
Multiple Entry Updates
Password Policy Management
MarkW: Present sample charter text for some of these groups.
Comment: The texts should mention possible impact on other groups by these items.
MarkW: This is not complete charter texts but rather one-sentence descriptions. Also all these documents are intended standards-track. Other documents in the ldap sphere (see slides) are either informational or have expired.
MarkW: This should go into charter:
Subentries
Value Control
Request/Response Grouping
Chaning and Proxying
KurtZ: Wait until things fall/get axed off the charter until adding new stuff ?!
MarkW: Charter review is very tedious and don't like to do it very often so let's have this discussion now and not at the next meeting.
Comment: Why not password?
MarkW: Few organizations/individuals work on it. The other groups affect large parts of LDAP. This is not true for password mgmt which is mostly of interest if you have user information in LDAP.
KurtZ: Prioritize?
MarkW: Yes.
DavidC: Why not do multiple entry modification as part of grouping?
MarkW: You could but the intended usages are different...
KurtZ: Suggest that this group make one application as part of the grouping work.
MarkW: Agree.
Comment: Why lump chaining and proxying together?
MarkW: (argument that these are sufficiently similar)
Question to Kurt about authPassword, why he just wanted the ID to timeout. Kurt argured that they had found that they would have to store several hashversion of the password in order to support different application. This made it easier to just store the password in the clear and then contruct the hashes when needed. He will write down the experiences they had with implementing the draft and send it to the list.
12. ITU-T alignment with LDAP (Peter Yee)
Presentation: See slides.
13. Evolving LDAP Schema Entries (Ellen Stokes)
Presentation: See slides.
EllenS: How to work on this. (A small group of people volounteer to do work by raising their hands -- a bar-bof ensues later in the week).
14. Storing Whois in LDAP (Andrew Newton)
Presentation: See slides. (idea is to place domain registration data in LDAP and use referrals to address the distribution of data between the registry and registrars).
http://www.ldap.research.netsol.com
15. Non Work Items (those discussed to be determined at meeting)
draft-armijo-ldap-control-error-00.txt (Michael Armijo)
draft-behera-ldap-password-policy-03.txt (Prasanta Behera)
draft-ietf-ldapext-matchedval-04.txt (David Chadwick)
draft-elliott-ldapext-spdna-recrecs-00.txt (Dave Elliott)
draft-greenblatt-ldapext* (Bruce Greenblatt)
draft-haripriya-ldapext-entryselect-01.txt (Haripriya S.)
draft-rharrison-ldap-extpartresp-02.txt (R. Harrison)
draft-knvijay-ldapext-clientcachingproxy-00.txt (K. N. Vijay)
draft-salzr-ldap-repsig-00.txt (Rick Salz)
draft-legg-ldapext-component-matching-00.txt (Stephen Legg)
draft-sermersheim-ldap-chaining-00.txt (Jim Sermersheim)
draft-weltman-ldapv3-proxy-06.txt (Rob Weltman)
draft-zeilenga-ldap* (Kurt Zeilenga)
Operation Grouping
The time was used up when the meeting came to this point so it was dropped.
Verisign Referral LDAP Service
LDAP Subentries
Changes and Comments
Agenda
Maximizing Alignment with LDAP