[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Chained Operation (control, extended op, or op?)
- To: <ldapext@ietf.org>
- Subject: [ldapext] Chained Operation (control, extended op, or op?)
- From: "Jim Sermersheim" <jimse@novell.com>
- Date: Mon, 21 Jun 2004 11:51:31 -0600
All,
I'm attaching a not-ready-for-prime-time I-D which describes an LDAP
chained operation. Following X.518, I described it as an operation
(well, an extended operation) which contains the original message and
some chaining arguments. Some of my peers here have repeatedly argued
that there is no reason to define it as an extended operation, and that
a control makes more sense.
What do others think? I can go either way.
If it's a control, I'd want to reconsider the targetObject and
entryOnly fields. If the control holds these, and is sent as
non-critical, and the receiving server doesn't support the control, the
outcome will be erroneous.
As an extended operation, we have two sets of resultCode, matchedDN,
errorMessage, and referral. This can be resolved by chosing yet another
solution: Create a whole new operation (don't use an extended
operation). The new operation would not include the elements of
LDAPResult (well, the resultCode might be nice, but referral and
matchedDN is confusing).
I'll publish once I get some feedback on this, and fix up some
editorial issues.
Jim
Personal Submission J. Sermersheim
Internet Draft
Document: draft-sermersheim-ldap-chained-op-00.txt Novell, Inc
Intended Category: Standard Track June 2004
LDAP Chained Operation
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ldapext@ietf.org>. Editorial comments may be sent to
the author <jimse@novell.com>.
Abstract
This document describes an Lightweight Directory Access Protocol
(LDAP)[RFC3377] operation in the form of an extended request and
response which allows a directory operation to be chained between
Directory Server Agents (DSAs). This is similar to the chained form
of operations described in Section 12.1 of [X.518].
1. Introduction
Many directory servers have the ability through the use of various
mechanisms to participate in a distributed directory model. A
distributed directory is one where the DIT is distributed over
multiple DSAs. One operation completion mechanism used by DSAs in a
distributed directory is chaining. Chaining is defined in [X.518],
and is the act of one DSA communicating a directory operation that
originated from a DUA to another DSA in a distributed directory.
Contrast this with the act of passing referrals (4.1.11 of
[RFC2251]) and SearchResultReferences (4.5.2 of [RFC2251]) back to
the client. Chaining may happen during the name resolution part of
Sermersheim Internet-Draft - Exp. Dec 2004 Page 1
LDAP Chained Operation
an operation, or during other operations like search that apply to a
number of entries in a subtree.
This document does not attempt to define the distributed directory
model, rather it defines the manner in which LDAP DSAs chain
requests. As such, the term chaining may apply to uni-chaining as
well as multi-chaining (see [X.518]) depending on the capabilities
and configuration of the DSAs.
2. Conventions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
used in this document carry the meanings described in [RFC2119].
All Basic Encoding Rules (BER)[BER] encodings follow the conventions
found in Section 5.1 of [RFC2251].
3 Chained Request
The Chained Request is sent as an LDAP extended operation. The
requestName is <OID-TBD>. The requestValue is the BER [BER] encoding
of the following ChainedRequestValue ASN.1 definition.
ChainedRequestValue ::= SEQUENCE {
chainingArguments ChainingArguments,
operationRequest OperationRequest }
ChainingArguments ::= SEQUENCE {
targetObject [0] LDAPDN OPTIONAL,
traceInformation [1] ChainingTraceInformation,
entryOnly [2] BOOLEAN DEFAULT FALSE,
exclusions [3] Exclusions OPTIONAL }
ChainingTraceInformation ::= SET OF LDAPURL
Exclusions ::= SET OF RelativeLDAPDN
OperationRequest ::= SEQUENCE {
Request ::= CHOICE {
bindRequest BindRequest,
searchRequest SearchRequest,
modifyRequest ModifyRequest,
addRequest AddRequest,
delRequest DelRequest,
modDNRequest ModifyDNRequest,
compareRequest CompareRequest,
extendedReq ExtendedRequest,
... },
controls [0] Controls COPTIONAL }
Sermersheim Internet-Draft - Exp. Dec 2004 Page 2
LDAP Chained Operation
LDAPDN, RelativeLDAPDN, LDAPURL, BindRequest, SearchRequest,
ModifyRequest, AddRequest, DelRequest, ModifyDNRequest,
CompareRequest, ExtendedRequest and Controls are defined in
[RFC2251].
3.1 ChainedRequestValue.chainingArguments
In general, these fields assist in refining the original operation
as it is to be executed on the receiving DSA.
3.1.1 ChainedRequestValue.chainingArguments.targetObject
This field contains the new target (or base) DN for the operation.
The sending DSA populates this under different scenarios including
the case where an alias has been dereferenced while resolving the
DN, and also the case where a referral carries a target name
different from the reference object that caused the referral.
This field can be omitted only if it would be the the same value as
the object or base object parameter in the chained operation, in
which case its implied value is that value.
The receiving DSA examines this field and (if present) uses it
rather than the base DN held in the operationRequest.
3.1.2 ChainedRequestValue.chainingArguments.traceInformation
This contains a set of URIs. Each value represents the address of a
DSA and DN that has already been contacted while trying to service
the operation.
The sending DSA populates this with its own URI, and also the URIs
of any DSAs that have already been chained to.
The receiving DSA examines this list of URIs and returns a
loopDetect (54) error if it finds that any of the addresses and DNs
in the listed URI?s represent it?s own.
3.1.3 ChainedRequestValue.chainingArguments.entryOnly
This is set to true when the operationRequest is a search, the scope
is singleLevel, and the ChainedRequest is being sent due to a search
result reference.
When this is true, the receiving DSA treats the search operation (in
operationRequset) as having a scope of baseObject.
3.1.4 ChainedRequestValue.chainingArguments.exclusions
Each RelativeLDAPDN in this field identifies a subtree rooted at the
context prefix of a naming context subordinate to the targetObject
which should not be explored by the receiving DSA. See Section 10.9
Sermersheim Internet-Draft - Exp. Dec 2004 Page 3
LDAP Chained Operation
(Exclusions) of [X.518] for more details. <TODO: remove reference
and add language here>.
Exclusions are used to minimize the number of duplicate entries
returned to the DSA initiating a chained operation.
The RDNSequence is relative to the target object, and is not the
distinguished name of the context prefix.
3.2 ChainedRequestValue.operationRequest
This holds the original LDAP operation request. This is restricted
to a subset of all LDAP operation. Namely, the following LDAP
operation types are not allowed:
- Abandon/Cancel operations. When an abandon or cancel operation
needs to be chained, it is sent to the remote DSA as-is. This is
because there is no need to track it for loop detection or pass on
any other information normally found in ChainingArguments.
- Unbind. Again, there is no need to send chaining-related
information to a DSA to perform an unbind. If an unbind request is
unbinding a previously chained bind, the server servicing the
unbind request ensures that the unbind is properly chained.
- Chained Operation. When a DSA receives a chained operation, and
must again chain that operation to a remote DSA, it sends a
ChainedRequest where the operationRequest is that of the incoming
operationRequest.
4 Chained Response
The Chained Response is sent as an LDAP extended operation. The
requestName is omitted. The requestValue is the BER [BER] encoding
of the following ChainedResponse ASN.1 definition.
ChainedResponse ::= SEQUENCE {
chainedResults ChainingResults,
operationResponse OperationResponse }
ChainingResults ::= SEQUENCE {
exclusions [0] Exclusions OPTIONAL }
OperationResponse ::= SEQUENCE {
Response ::= CHOICE {
bindResponse BindResponse,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyResponse ModifyResponse,
addResponse AddResponse,
delResponse DelResponse,
modDNResponse ModifyDNResponse,
Sermersheim Internet-Draft - Exp. Dec 2004 Page 4
LDAP Chained Operation
compareResponse CompareResponse,
extendedResp ExtendedResponse,
... },
controls [0] Controls COPTIONAL }
BindResponse, SearchResultEntry, SearchResultDone,
SearchResultReference, ModifyResponse, AddResponse, DelResponse,
ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls
are defined in [RFC2251].
4.1 ChainedResponse.chainedResults
In general, this is used to convey additional information that may
needed in the even that the operation needs to be progressed
further.
Editor?s Note: I have created this as it?s own type so that new
fields may be added later if needed. It may turn out that exclusions
is not needed at all, and thus this entire field can go away.
4.1.1 ChainedResponse.chainedResults.exclusions
If present, these name RDNs immediately subordinate to the
ChainedRequest.chainingArguments.targetObject which have been
processed as part of a chained search operation and therefore may be
excluded in subsequent subrequests.
4.2 ChainedResponse.operationResponse
This holds the response message tied to the
ChainedRequest.operationRequest.
<TODO: Discuss the relationship between the components of LDAPResult
in the operationResponse and the components of LDAPResult in the
extended response.
5. Security Considerations
<TODO: add section details>
6. Normative References
[X.518]
ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
1993.
[RFC2119]
Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
Levels", Internet Draft, March 1997.
Available as RFC2119.
[RFC2251]
Sermersheim Internet-Draft - Exp. Dec 2004 Page 5
LDAP Chained Operation
Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
Protocol (v3)", Internet Standard, December, 1997.
Available as RFC2251.
7. Author's Address
Jim Sermersheim
Novell, Inc.
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
+1 801 861-3088
Sermersheim Internet-Draft - Exp. Dec 2004 Page 6 _______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext