docs: document NetWare 4.11 LDAPv2 baseline

AI.md

@@ -521,6 +521,27 @@ TinyLDAP / directory follow-up test ideas before replacing flat-file storage:
   object classes, mandatory/optional attributes, attribute syntax,
   single/multi-value rules, naming attributes, inheritance, and default indexes.
 
+
+NetWare 4.11 LDAP compatibility baseline:
+
+- Treat stock NetWare 4.11 LDAP as the primary compatibility target for the
+  directory service.  The stock LDAP.NLM generation is LDAPv2-only, not LDAPv3.
+- LDAPv2 simple bind, search, and unbind must be first-class, intentional, and
+  covered by tests.  LDAPv3 support may remain or be added, but it is additive
+  and must not become the default assumption for the NetWare 4.11 baseline.
+- Baseline references for the stock target are RFC 1777 (LDAPv2 core protocol)
+  and RFC 1778 (LDAPv2 string representation of standard attribute syntaxes).
+- Do not require LDAPv3-only features for the stock 4.11 target: no referrals,
+  no SASL, no controls, no extended operations, and no mandatory LDAPv3 UTF-8 DN
+  behavior.
+- NetWare 4.11 with NDS 8 / eDirectory and newer LDAP.NLM versions is a later
+  optional compatibility profile.  That profile may cover LDAPv3-era RFCs such
+  as 2251, 2252, 2253, 2255, and SASL RFC 2222, but it should not drive the
+  initial directory design.
+- The user has started importing real NetWare schema files under `opt/schema/`
+  after lower-casing filenames and converting CRLF line endings.  Treat these
+  as input for the directory/schema enum/type-layer work.
+
 `nwsetup` direction:
 
 - ncurses is already needed for FLAIM tools and should also support a future

REDESIGN.md

@@ -1300,6 +1300,44 @@ Examples of setup-owned work:
 the local bootstrap path should avoid requiring a running LDAP server and should
 not make LDAP the canonical internal representation.
 
+
+### NetWare 4.11 LDAP compatibility baseline
+
+The primary mars-nwe directory compatibility target is the stock NetWare 4.11
+LDAP server behavior.  That baseline is LDAPv2.  LDAPv3 support belongs to the
+later NDS 8 / eDirectory upgrade path and must be treated as an optional profile,
+not as the default assumption.
+
+Stock NetWare 4.11 LDAP requirements:
+
+- support LDAPv2 simple bind, search, and unbind;
+- use LDAPv2 as the compatibility baseline for tests and protocol decisions;
+- keep read/write access to NDS-like objects possible through the LDAPv2 view;
+- avoid assuming referrals, SASL, controls, extended operations, or LDAPv3-only
+  UTF-8 DN behavior.
+
+The stock baseline is anchored in the LDAPv2-era specifications such as RFC 1777
+for the core protocol and RFC 1778 for standard attribute syntax string
+representations.  This matters because many real NetWare 4.11 installations did
+not receive the NDS 8 / eDirectory LDAPv3 upgrade.
+
+The optional later NDS 8 / eDirectory profile may add LDAPv3 behavior, including
+RFC 2251 core protocol behavior, RFC 2252 schema exposure, RFC 2253 UTF-8 DN
+string representation, RFC 2255 LDAP URLs, and SASL via RFC 2222.  Those features
+must be additive.  They should not force the internal directory store, schema
+model, or `nwsetup` bootstrap flow to require LDAPv3.
+
+Design consequences:
+
+- TinyLDAP/nwdirectory must keep LDAPv2 paths first-class and tested.
+- LDAPv3 can stay enabled where it already works, but feature gates or explicit
+  compatibility profiles should keep it separate from the NetWare 4.11 default.
+- The internal directory API and FLAIM-backed store must not depend on LDAPv3
+  schema-publishing semantics.  Native `.sch` import and internal schema enums
+  are the first target.
+- `nwnds` and `nwsetup` use the directory core directly; they do not bootstrap by
+  acting as LDAPv3 clients.
+
 ### NetWare 4.11 schema acquisition and import
 
 The future NetWare 4.x directory schema should not be invented from memory or

TODO.md

@@ -2069,6 +2069,33 @@ Follow-up:
   normal `libnwssl` TLS facade used by mars-nwe apps/services.
 
 
+
+#### NetWare 4.11 LDAPv2 compatibility tests
+
+Current status:
+
+- Stock NetWare 4.11 LDAP compatibility means LDAPv2 first.  LDAPv3 belongs to
+  the optional NDS 8 / eDirectory upgrade path and should not become the default
+  directory-protocol assumption.
+- TinyLDAP already parses the BindRequest protocol version and its bundled test
+  clients currently send version 3.  The compatibility requirement is to make
+  version 2 acceptance deliberate and tested, not merely accidental.
+- Real NetWare 4.11 schema files are being imported under `opt/schema/` for later
+  schema/type-layer work.
+
+Follow-up:
+
+- Add parser/unit tests for LDAPv2 BindRequest decode and encode paths.
+- Add server-level CTests that perform LDAPv2 simple bind, search, and unbind
+  against the tinyldap/nwdirectory test fixture.
+- Add negative tests for unsupported protocol versions such as version 1 and
+  versions greater than 3.
+- Keep LDAPv3 tests where useful, but treat them as additive regression coverage
+  rather than the primary NetWare 4.11 compatibility baseline.
+- When the FLAIM-backed directory store lands, repeat the LDAPv2 tests against
+  the FLAIM store and verify that password/secret material is not written as
+  plaintext.
+
 #### Third-party renamed library/import hygiene
 
 Current status: