Changes to {C}LDAP ASN.1
Simon E Spero <ses@tipper.oit.unc.edu> Thu, 18 November 1993 22:37 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13974;
18 Nov 93 17:37 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13970;
18 Nov 93 17:37 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa24484;
18 Nov 93 17:37 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.04593-0@haig.cs.ucl.ac.uk>; Thu, 18 Nov 1993 20:25:30 +0000
Received: from tipper.oit.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP
id <g.27453-0@bells.cs.ucl.ac.uk>; Thu, 18 Nov 1993 20:24:35 +0000
Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA01407; Thu, 18 Nov 93 15:24:02 EST
Message-Id: <9311182024.AA01407@tipper.oit.unc.edu>
To: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Changes to {C}LDAP ASN.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Nov 93 15:23:57 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses@tipper.oit.unc.edu>
As promised, here are my changes to the LDAP asn for "cldap++".
The changes are:
1) Remove "IMPLICIT TAGS" directive, and mark all implicit tags
er, explicitly. There's been some confusion about which tags
must be sent in explicit form, and this helps make things clearer.
2) Rename compareDNRequest and Response to compareRequest and Response;
These were the only two protocol ops which didn't fit the pattern.
3) Add new protocolOp grouped Request and grouped Response;
There are several situations, mostly to do with multicast, when
it's useful to be able to ship binding information with another
request whilst using CLDAP. a grouped request just wraps a
sequence of ldapMessages into one message.
4) Add optional bindingTarget to the BindRequest. This value is of
type URL; the URL specifies a server to execute the requests against.
This makes it easier to handle referrals in a hetrogeneous directory
mesh, as gatewaying becomes simpler.
5) Add new value to scope enumeration: namedHierarchy (3).
Add new element to searchRequest - hierarchyName.
Add new enumerated type "sendReferrals" indicating relative
preferences for referrals vs chaining.
Add new choice to search response- referrals, which is a
defined to be a sequence of URLs, indicating servers to try.
These changes allow centroid and spreading-activation based searching
strategies to be used.
I would like to change the definition of search response to allow
multiple values to be returned; is there a reason why this is
restricted to a single object?
Simon
---------------------CLIP AND SAVE--------
Lightweight-Directory-Access-Protocol---Deep-Space-Nine DEFINITIONS ::=
BEGIN
LDAPMessage ::=
SEQUENCE {
messageID MessageID,
-- unique id in request,
-- to be echoed in response(s)
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SearchResponse,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modifyDNRequest ModifyDNRequest,
modifyDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
bindRequest BindRequest,
bindResponse BindResponse,
abandonRequest AbandonRequest,
unbindRequest UnbindRequest,
groupedRequest GroupedRequest,
groupedResponse GroupedResponse
}
}
GroupedRequest ::=
[APPLICATION 17] IMPLICIT SEQUENCE OF LDAPMessage
GroupedRespnse ::=
[APPLICATION 18] IMPLICIT SEQUENCE OF LDAPMessage
BindRequest ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
version INTEGER (1 .. 127),
-- current version is 2
name LDAPDN,
-- null name implies an anonymous bind
authentication CHOICE {
simple [0] IMPLICIT OCTET STRING,
-- a zero length octet string
-- implies an unauthenticated
-- bind.
krbv42LDAP [1] IMPLICIT OCTET STRING,
krbv42DSA [2] IMPLICIT OCTET STRING
-- values as returned by
-- krb_mk_req()
-- Other values in later
-- versions of this protocol.
},
bindingTarget URL OPTIONAL
}
BindResponse ::= [APPLICATION 1] IMPLICIT LDAPResult
UnbindRequest ::= [APPLICATION 2] IMPLICIT NULL
SearchRequest ::=
[APPLICATION 3] IMPLICIT SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
namedHierarchy (3)
},
hierarchyName AttributeType OPTIONAL,
sendReferrals [0] IMPLICIT ENUMERATED {
mustChain (0),
preferChain (1),
preferRefer (2),
mustRefer (3)
} OPTIONAL -- Default == mustChain
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
alwaysDerefAliases (3)
},
sizeLimit INTEGER (0 .. MaxInt),
-- value of 0 implies no sizelimit
timeLimit INTEGER (0 .. MaxInt),
-- value of 0 implies no timelimit
attrsOnly BOOLEAN,
-- TRUE, if only attributes (without values)
-- to be returned.
filter Filter,
attributes SEQUENCE OF AttributeType
}
SearchResponse ::=
CHOICE {
entry [APPLICATION 4] IMPLICIT SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE {
AttributeType,
SET OF
AttributeValue
}
},
resultCode [APPLICATION 5] IMPLICIT LDAPResult,
referrals [APPLICATION 19] IMPLICIT SEQUENCE OF URL
}
ModifyRequest ::=
[APPLICATION 6] IMPLICIT SEQUENCE {
object LDAPDN,
modifications SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2)
},
modification SEQUENCE {
type AttributeType,
values SET OF
AttributeValue
}
}
}
ModifyResponse ::= [APPLICATION 7] IMPLICIT LDAPResult
AddRequest ::=
[APPLICATION 8] IMPLICIT SEQUENCE {
entry LDAPDN,
attrs SEQUENCE OF SEQUENCE {
type AttributeType,
values SET OF AttributeValue
}
}
AddResponse ::= [APPLICATION 9] IMPLICIT LDAPResult
DelRequest ::= [APPLICATION 10] IMPLICIT LDAPDN
DelResponse ::= [APPLICATION 11] IMPLICIT LDAPResult
ModifyRDNRequest ::=
[APPLICATION 12] IMPLICIT SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN -- old RDN always deleted
}
ModifyRDNResponse ::= [APPLICATION 13] IMPLICIT LDAPResult
CompareRequest ::=
[APPLICATION 14] IMPLICIT SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion
}
CompareResponse ::= [APPLICATION 15] IMPLICIT LDAPResult
AbandonRequest ::= [APPLICATION 16] IMPLICIT MessageID
MessageID ::= INTEGER (0 .. MaxInt)
LDAPDN ::= IA5String
RelativeLDAPDN ::= IA5String
Filter ::=
CHOICE {
and [0] IMPLICIT SET OF Filter,
or [1] IMPLICIT SET OF Filter,
not [2] Filter,
equalityMatch [3] IMPLICIT AttributeValueAssertion,
substrings [4] IMPLICIT SubstringFilter,
greaterOrEqual [5] IMPLICIT AttributeValueAssertion,
lessOrEqual [6] IMPLICIT AttributeValueAssertion,
present [7] IMPLICIT AttributeType,
approxMatch [8] IMPLICIT AttributeValueAssertion
}
LDAPResult ::=
SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
aliasDereferencingProblem (36),
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
referralProhibited (70),
invalidHierachy (71),
other (80)
},
matchedDN LDAPDN,
errorMessage IA5String
}
AttributeType ::= IA5String
-- text name of the attribute, or dotted
-- OID representation
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::=
SEQUENCE {
attributeType AttributeType,
attributeValue AttributeValue
}
SubstringFilter
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] IMPLICIT IA5String,
any [1] IMPLICIT IA5String,
final [2] IMPLICIT IA5String
}
}
IA5String ::= OCTET STRING
URL ::= IA5String -- A Uniform Resource Locator pointing to a directory server
MaxInt ::= 65535
END
- Changes to {C}LDAP ASN.1 Simon E Spero
- Re: Changes to {C}LDAP ASN.1 Tim Howes
- Re: Changes to {C}LDAP ASN.1 Simon E Spero
- Re: Changes to {C}LDAP ASN.1 Steve Kille