From 60b4e07cee8ffa5d2988a7c18a13e3c48dde2d9d Mon Sep 17 00:00:00 2001 From: AI Patch Builder Date: Sat, 6 Jun 2026 19:11:09 +0000 Subject: [PATCH] docs: document NetWare 4.11 LDAPv2 baseline --- AI.md | 21 +++++++++++++++++++++ REDESIGN.md | 38 ++++++++++++++++++++++++++++++++++++++ TODO.md | 27 +++++++++++++++++++++++++++ 3 files changed, 86 insertions(+) diff --git a/AI.md b/AI.md index da62f36..3553cce 100644 --- a/AI.md +++ b/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 diff --git a/REDESIGN.md b/REDESIGN.md index beb3bb3..ef428dd 100644 --- a/REDESIGN.md +++ b/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 diff --git a/TODO.md b/TODO.md index eb8cd9a..0a49f90 100644 --- a/TODO.md +++ b/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: