directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Updated: (DIRSNICKERS-40) Write BindResponse rules
Date Sun, 18 Apr 2004 20:45:53 GMT
The following issue has been updated:

    Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
       Date: Sun, 18 Apr 2004 1:43 PM
    Changes:
             description changed from Need to start writing the bind response rules.  Here's
the anatomy of the bind response in raw tags with the primitive bit turned off:

 to Need to start writing the bind response rules.  Here's the anatomy of the bind response
in raw tags with the primitive/constructed bit turned off:

-o- the ASN.1 -o-

 BindResponse ::= [APPLICATION 1] SEQUENCE {

             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

-o- pattern -o-


.|..0x10000000 <-------- SEQUENCE 
.|......0x02000000 <-------- INTEGER (messageId) 
.|......0x41000000 <-------- BindResponse (APPLICATION 1) 
.|..........0x0a000000 <-------- ENUMERATION (resultCode) 
.|..........0x04000000 <-------- OCTET STRING (matchedDN) 
.|..........0x04000000 <-------- OCTET STRING (errorMessage) 
.|..........0x83000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 3) Referral (OPTIONAL)

.|..............0x04000000 <---- OCTET STRING for LDAPURL
                ( can have several of these in the seq) ;

.|..........0x87000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 7) serverSaslCreds (OPTIONAL)

.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL) 
 v 
time 

The response actually is more complex than the request.  We should create a generic ResultRule
for the LDAPResult.  Note that the tricky part about this is in the fact that there are two
octet strings where order matters: matchedDN and errorMessage.  This is best handled by pushing
all parameters in the order they occur onto their respective stacks.  Then have the ResultRule
pop the appropriate stacks.  I need to make a separate issue for the ResultRule. 


    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/DIRSNICKERS-40?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIRSNICKERS-40

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIRSNICKERS-40
    Summary: Write BindResponse rules
       Type: Task

     Status: In Progress
   Priority: Major

    Project: Directory Snickers
 Components: 
             LDAP Provider

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Sun, 18 Apr 2004 1:17 PM
    Updated: Sun, 18 Apr 2004 1:43 PM

Description:
Need to start writing the bind response rules.  Here's the anatomy of the bind response in
raw tags with the primitive/constructed bit turned off:

-o- the ASN.1 -o-

 BindResponse ::= [APPLICATION 1] SEQUENCE {

             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

-o- pattern -o-


.|..0x10000000 <-------- SEQUENCE 
.|......0x02000000 <-------- INTEGER (messageId) 
.|......0x41000000 <-------- BindResponse (APPLICATION 1) 
.|..........0x0a000000 <-------- ENUMERATION (resultCode) 
.|..........0x04000000 <-------- OCTET STRING (matchedDN) 
.|..........0x04000000 <-------- OCTET STRING (errorMessage) 
.|..........0x83000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 3) Referral (OPTIONAL)

.|..............0x04000000 <---- OCTET STRING for LDAPURL
                ( can have several of these in the seq) ;

.|..........0x87000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 7) serverSaslCreds (OPTIONAL)

.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL) 
 v 
time 

The response actually is more complex than the request.  We should create a generic ResultRule
for the LDAPResult.  Note that the tricky part about this is in the fact that there are two
octet strings where order matters: matchedDN and errorMessage.  This is best handled by pushing
all parameters in the order they occur onto their respective stacks.  Then have the ResultRule
pop the appropriate stacks.  I need to make a separate issue for the ResultRule. 




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message